Multi-agent orchestration without hidden complexity.

More agents create more boundaries

Multi-agent systems can divide a broad task among specialized workers, route requests to the right capability, or synthesize independent investigations. They also add prompts, context transfers, credentials, retries, latency, cost, and failure states. The right objective is not the largest agent team. It is the smallest architecture that can safely complete the work.

LangGraph's own multi-agent guidance states that not every complex task needs multiple agents and that a single agent with carefully selected tools and context is often sufficient.Source 2 NIST's lifecycle framework provides the complementary governance lens: map the context, assign ownership, measure behavior, and manage risk throughout operation.Source 4

Default to one narrowly authorized agent

Use one agent when the task shares a coherent context, requires a limited tool set, and can be evaluated as one unit. A single boundary is easier to authorize, trace, test, and stop. It avoids the information loss that occurs when one component summarizes context for another and reduces the number of places where untrusted instructions can influence execution.

Complexity alone is not a reason to add agents. A long but predictable process belongs in a deterministic workflow. A broad tool catalog should be narrowed before execution, not divided among fictional job titles. Add another autonomous component only when task shape demands separate context, parallel investigation, distinct permissions, or dynamic delegation.

Six orchestration patterns

Sequential workflow

Use a sequential workflow when order is known and each result feeds the next step. Code determines the path; model calls can still perform bounded interpretation or drafting. This pattern is reviewable, straightforward to retry, and appropriate when later actions depend on validated earlier outputs.

Avoid agent-to-agent delegation when a fixed graph expresses the process more clearly. A deterministic sequence is not less intelligent; it simply keeps control flow out of the model.

Router

A router classifies an input and dispatches it to one specialist or workflow. It works well when categories are stable, destinations are mutually understandable, and only one path should own the request.

Routing can be rule-based, semantic, or model-assisted. Authorization must not depend solely on the router's model output. The destination should still validate the identity, tenant, and permitted operation. Low-confidence or novel categories need an explicit fallback.

Handoff

A handoff transfers ownership and selected state from one specialist to another. It is useful for stateful conversations or staged work in which the responsible role changes—for example, intake to investigation to human review.

The interface between agents should be typed. Send the task, evidence references, completed actions, open questions, and permission context required by the recipient. Forwarding an entire conversation can leak irrelevant data and make the next agent vulnerable to instructions that were never intended for it. LangGraph documents handoffs as state and tool-driven transfers rather than an informal chat between personas.Source 3

Supervisor

A supervisor chooses workers from intermediate results, delegates tasks, and synthesizes their outputs. Use it when decomposition cannot be fully specified in advance and central coordination adds real value.

Supervision creates a powerful decision point and a larger failure surface. The supervisor needs iteration limits, a worker allowlist, task budgets, clear stopping conditions, and traceable delegation. Workers should return structured results and evidence, not only prose. A narrow sequential workflow or router is usually preferable when the path is already known.

Parallel workers

Parallel execution is useful when subtasks are independent and can be merged safely: several approved sources can be investigated at once, or independent document sections can be evaluated against the same rubric. Define cancellation, timeout, idempotency, partial-result, disagreement, and merge behavior before fan-out.

Do not parallelize actions that mutate shared state without coordination. If two workers can update the same record, ordering and conflict policy belong in deterministic infrastructure.

Human gate

A human gate is an orchestration boundary for privileged, irreversible, legally sensitive, or difficult-to-reverse actions. The reviewer should see the proposed action, source evidence, policy result, and downstream consequence. Approval is not useful when it is merely decorative or the reviewer lacks enough information to disagree.

In Zilionix today, the approval node is terminal. The decision ends that execution, and any subsequent write requires a separate initiation. Architecture diagrams and operating procedures must represent that boundary accurately.

Select the pattern from task shape

Patterns can be composed, but each composition needs a reason. A router may select a deterministic workflow. A supervisor may fan out read-only research and send a synthesis to a terminal human review. The architecture should make permission and failure boundaries clearer, not hide them.

Treat context as an interface

Context is the contract between components. Define required fields, allowed references, sensitivity, maximum size, and validation. Prefer protected references and concise summaries over full histories. Include provenance so the receiver can distinguish user input, retrieved evidence, model-generated interpretation, and completed tool results.

Give each worker only the tools and data it needs. A research worker should not inherit a payment tool. A summarizer should not inherit the supervisor's ability to delegate. When a worker requests an operation outside its scope, the system should reject it rather than asking the model to reconsider.

Design failure behavior before delegation

Every boundary needs timeout, retry, cancellation, and fallback behavior. Retries must be safe for the operation. A duplicated search is inconvenient; a duplicated external write can be damaging. Correlation identifiers and idempotency keys help connect attempts without repeating consequences.

For parallel work, decide whether one failed branch cancels the whole run, produces a partial result, or moves to human review. For handoffs, define what happens when the destination is unavailable. For supervisors, cap iterations and prevent repeated delegation cycles. Record routing decisions and terminal status in the receipt.

Expose coordination cost

Anthropic describes an orchestrator-worker research system that explores independent directions in parallel.Source 1 In that specific internal system, Anthropic reports materially higher token use than ordinary chat and presents coordination as an economic trade-off. That finding supports caution; it is not a Zilionix benchmark and should not be generalized to every multi-agent workload.

Cost includes more than tokens. More agents can increase latency, model variance, context serialization, evaluation coverage, tracing volume, and operational support. The benefit should come from real parallelism, specialized context, or necessary delegation—not from the appearance of an organizational chart.

Evaluate the final state

Component-level answer scores are insufficient. Verify resulting records, messages, permissions, and external changes. Test route selection, handoff completeness, worker authorization, merge behavior, disagreement, timeout, partial failure, and human escalation.

A multi-agent receipt should show the initiating identity, orchestrator version, selected workers, context supplied to each, tool calls, routing and merge decisions, policy results, approvals, cost, and final state. This evidence makes hidden coordination visible to operators.

How the Zilionix patterns map

The central claim registry verifies 3 agent types: Advanced/ReAct, workflow, and supervisor agents. It also verifies 42 workflow node types across seven categories. The workflow engine supports deterministic sequencing and parallel branches; router nodes support rule-based and model-assisted dispatch; supervisor execution supports delegated worker handoffs with iteration limits.

These are repository capabilities, not evidence that additional agents improve every process. Use Advanced/ReAct for narrow bounded work, workflows for known control flow, routers for dispatch, supervisors for dynamic decomposition, and terminal approval for sensitive completion boundaries. See Platform, Developers, and Use cases for the connected surfaces.

Source caveat

Anthropic's report describes one of Anthropic's research systems and its internal measurements. LangGraph documentation explains framework patterns rather than independent performance findings. NIST provides voluntary risk-management guidance. Zilionix statements are limited to code-verified orchestration capabilities as of the review date and do not imply public customer operation, comparative performance, or that multi-agent design is inherently safer or more effective.