Choose multi-agent orchestration by how work is assigned, how results are combined and who owns failure recovery. A router selects a suitable specialist. A supervisor coordinates several specialists and decides what to do next. A hierarchical team delegates through multiple levels. None is automatically more scalable or reliable simply because it contains more agents.

Start with one agent or an explicit workflow. Add specialist boundaries only when they solve a concrete problem, such as different tools, permissions or evaluation criteria. This guide compares the three patterns and develops an illustrative enterprise support design with bounded delegation, budgets and recovery rules.

Quick selection guide

• Router: use when a request can be assigned to one well-defined destination.
• Supervisor: use when the task needs coordinated contributions and the next step depends on results.
• Hierarchy: consider when several distinct domains need their own bounded coordination, not merely because the task sounds complex.
• Fixed workflow: prefer when the sequence is known and dynamic delegation adds little value.

Router, supervisor and hierarchical teams

Router: select the right destination

A router classifies the incoming request and sends it to a defined handler. That handler may be an agent, a deterministic workflow or a human queue. The router does not need to remain in a continuous conversation with every specialist.

For a support application, known account-access questions might route to an access workflow while invoice queries route to a billing assistant. Use a fallback for ambiguous requests. A low-confidence route should not silently choose a destination with broader permissions.

Supervisor: coordinate contributions

A supervisor manages work across specialists and combines their results. It can decide to ask for missing evidence, request a particular specialist’s analysis or stop because an acceptance condition is met. The supervisor needs a clear completion rule and bounded options; otherwise coordination can become a loop of repeated delegation.

In a support investigation, one specialist may retrieve permitted system evidence while another examines an approved knowledge source. The supervisor reconciles the findings and prepares a reviewable answer. It must not assume that agreement between generated summaries proves the underlying facts.

Hierarchy: coordinate bounded subteams

A hierarchy places coordinators over separate specialist groups. It can make ownership clearer when domains have genuinely different tools and decision rules. It also adds handoff boundaries, context loss and operational complexity. Use a hierarchy only when the domain split is explicit enough to justify those costs.

For example, an enterprise request might involve a technical investigation team and a service-operations team. Each can produce a structured result for a top-level coordinator. That is different from creating several agent personas that share the same tools and repeat the same reasoning.

The LangGraph workflows and agents guide provides implementation examples for routing, parallel work and orchestrator-worker patterns. Its mechanisms are useful building blocks; the operating boundaries below are application design decisions.

Define a delegation contract before adding a specialist

A specialist should receive a bounded task, relevant permitted context and a clear output contract. “Investigate everything” is not an operationally useful instruction. A contract should state the question, allowed tools, accessible sources, deadline, output fields and conditions for reporting insufficient evidence.

Illustrative investigation task
Goal: explain the latest permitted incident status
Inputs: incident reference and trusted caller context
Sources: approved incident API and linked knowledge records
Allowed actions: read only
Output: findings, source references, uncertainty, completion status
Stop condition: sufficient evidence or declared inability to proceed
Escalation: missing access, conflicting evidence or requested write action

Enforce the tool and source boundaries outside the prompt. Delegating to a specialist must not create additional authority. If the coordinator has access to a record but the delegated service does not, the application needs an explicitly approved data-flow design rather than an assumption that every subagent can read everything.

Share the minimum useful context

Send the task and supporting evidence needed by that specialist. Avoid passing the full conversation to every participant by default. Preserve source identifiers and distinguish observed facts from generated interpretation. A specialist’s confident summary should not erase uncertainty from the original evidence.

For persistent state and scope boundaries, see AI agent memory architecture.

Worked example: an enterprise incident assistant

Consider a fictional assistant that handles incident status questions, knowledge lookups and requests for operational changes. The objective is to provide a supported answer or route a reviewable action, not to maximize the number of collaborating agents.

Stage 1: route by required work

A status lookup goes to the permitted incident lookup workflow. A documentation question goes to the knowledge retrieval workflow. A request to change an operational setting is routed to an approval path. Ambiguous requests trigger clarification. This first stage can use deterministic rules where categories are explicit.

Stage 2: introduce coordination only for combined investigations

If the question requires both incident evidence and related documentation, a supervisor can request those two bounded contributions. Each returns findings with source references and a declared completion state. The supervisor compares them and states conflicts rather than merging them into a smooth but unsupported conclusion.

Stage 3: preserve approval boundaries

If the investigation suggests a change, the supervisor prepares a proposal. It does not execute the change merely because two specialists recommend it. An authorized review and bounded executor handle the write. See human-in-the-loop approval workflows.

Stage 4: avoid premature hierarchy

A top-level supervisor over multiple domain supervisors is unnecessary if the same two read-only lookups solve the problem. Consider hierarchy later only if separate domains need independent coordination, distinct ownership and demonstrable acceptance criteria. Record the added handoff cost in that decision.

Set execution budgets at the workflow boundary

Without explicit limits, every specialist can generate more work for another specialist. Bound total model requests, tool calls, delegation depth, elapsed execution time and the maximum amount of context passed between participants. Human waiting time may follow a separate business deadline from active compute time.

For illustration, a supervisor might be allowed two specialist tasks and one clarification round before escalation. Those are design assumptions for a particular workflow, not universal recommended limits. Choose limits from the expected task and evaluate how often they prevent a legitimate completion.

Parallel execution does not automatically reduce total cost. It can shorten elapsed time when work is independent while increasing concurrent demand and aggregate model consumption. Compare the same task with a single-agent or deterministic baseline. Measure task quality, total requests, critical-path time and operator intervention together.

Failure recovery belongs in the orchestration design

Specialist timeout

Define whether the task can continue with a clearly marked partial result or must stop. If the missing specialist provides required evidence, do not let the supervisor invent its contribution. Use bounded retries only where they are safe.

Conflicting evidence

Return the conflict with source references. Ask for current authoritative information or human review. A majority vote among agents that all rely on the same stale document does not create independent verification.

Worker restart

Persist required workflow state and task identifiers so completed work can be recognized. Distinguish replayable preparation from side effects. A restart should not issue the same consequential operation again simply because the coordinator lost its in-memory state.

Routing or contract failure

If a specialist returns the wrong shape or cannot satisfy the contract, surface that state explicitly. A parser failure should not be hidden by asking another model to guess the missing fields. Keep a bounded repair path and an escalation outcome.

Permission failure

Stop at the denied boundary. Do not reassign to a more privileged specialist as an automatic workaround. Any alternative access path must be explicitly authorized and preserve the caller’s intended scope.

Evaluate the simplest baseline first

Create a representative test set covering clear routes, ambiguous requests, combined investigations, missing sources, denied access and requests that require approval. Include tasks that should finish without model-driven delegation. Compare the proposed pattern with the smallest workable baseline.

Add agents only when the test results show a useful improvement or a clearer enforceable boundary. A readable architecture with one responsible coordinator can be easier to operate than a larger network whose participants continuously delegate back to each other.

Common questions about multi-agent orchestration

Choose the smallest orchestration that meets the task

Discuss an AI agent integration assessment with Prominent AI Services LLP. Bring representative requests, allowed tools and failure cases so the pattern can be evaluated against actual operating requirements.

Technical reference reviewed 2 November 2026. The incident assistant and execution budgets are illustrative design examples.