Multi-agent orchestration patterns with Claude

1. Multi-agent is a coordination decision, not a capability one

A single Claude agent with the right tools can already plan, call tools, read results, and adjust course across a long task. Nothing in that loop needs a second agent. Splitting a task across agents changes how the context accumulated by the work is divided. One agent on a long, multi-part task carries the history of every subtask in one window, which is the context-rot problem context engineering describes: the more unrelated work piles into the window, the more the model's attention spreads away from what matters for the current step. Multi-agent orchestration contains that. The model gains no new capability.

2. The orchestrator-worker pattern

The dominant shape is one orchestrator agent that holds the overall task, decomposes it into scoped subtasks, and dispatches each to a worker (subagent). The worker receives only what it needs, does the work, and returns a result. The orchestrator keeps the judgment about how the pieces fit together; it delegates execution of a bounded piece, then integrates what comes back. It works like a manager assigning a well-scoped task, and the analogy helps spot a bad decomposition: a subtask with an ambiguous boundary, or one that depends on another worker's unfinished output, causes the same confusion a badly scoped work assignment does.

3. Context isolation is the real benefit

The payoff is that a worker's context holds only what its subtask needs, without the history of every other subtask the orchestrator has handled. Split a research task into five independent sub-questions, each sent to its own worker, and each worker's context holds one question and the sources it gathers. A single agent would instead accumulate the reading history of all five, most of it irrelevant to questions two through five once question one is done. The orchestrator's context stays smaller too: five subtasks and five returned results, without each worker's scratch work. An orchestrator that has dispatched a dozen subtasks carries a dozen distilled answers.

Context engineering makes the same case for offloading bulky tool results to a file. This applies it to a whole subtask: work that would bloat one shared context happens in isolation, and only the result crosses back into the context that reasons about the bigger picture.

4. Coordination failure modes

Splitting work creates failure modes a single agent can't have, because one agent's context is never inconsistent with itself. Duplicated work happens when two subtasks overlap and two workers independently do much the same research. That wastes both workers' calls and can return subtly different answers to the same underlying question, leaving the orchestrator to reconcile a disagreement neither worker knew about. Conflicting writes happen when workers modify shared state (a shared document, a shared set of records) without a defined ownership boundary, and their changes combine into something other than the union of two independent edits.

Lost handoffs are harder to spot. A worker returns a complete answer to its narrow question, but the orchestrator's synthesis step drops or misweights it. That's the lost-in-the-middle risk from context engineering, with five workers' results competing for the orchestrator's attention in place of five documents. These failures are the cost of the coordination the pattern introduces. A decomposition without independent subtasks, clear ownership, and a synthesis step built to weigh every result pays that cost and doesn't get the isolation benefit.

5. Sequential pipelines versus parallel fan-out

Not every decomposition is parallel. In a sequential pipeline, each stage's output is the next stage's input: a drafting agent, then a review agent, then a formatting agent. Each stage's context is scoped to its own concern. The review agent sees only the finished draft, without the drafting agent's dead ends and discarded approaches. Parallel fan-out dispatches several independent subtasks at once and saves wall-clock time on top of the context benefit, but the coordination risks in Section 4 go live the moment two subtasks turn out to be less independent than the decomposition assumed.

Choose by whether the subtasks depend on each other's output. If stage two needs stage one's finished result to start correctly, use a sequential pipeline. Forcing dependent subtasks into parallel fan-out to save time produces the conflicting-state and lost-dependency failures from Section 4, because the independence the pattern assumes isn't there.

6. When one better-equipped agent wins

A task with a small, well-scoped context, one a single window holds comfortably without the degradation context engineering describes, gains nothing from being split. It pays the overhead from Section 4 for no benefit: extra round trips to dispatch and collect subtasks, an orchestration and synthesis layer that's a new source of bugs, and coordination latency a single agent working straight through would never incur. Split only when the task's context doesn't fit comfortably in one window, or when the subtasks have an independent structure that benefits from isolation. A task sounding complex is not a reason.

A frequent, avoidable mistake is reaching for multi-agent orchestration first for anything that looks hard, when the single agent's tools or system prompt were poorly designed for the task. Better tool design or a tighter prompt solves that directly, with no coordination cost.

7. Worked example: a research task, split well and split badly

A comparison of five competing products, each needing independent web research and a structured summary, fits parallel fan-out. The products don't depend on each other's research, each worker needs only its product's sources, and the orchestrator's synthesis is bounded: combine five structured summaries into one comparison. It never has to reconcile five workers' open-ended, possibly conflicting exploration.

Compare a task to debug one failing test, fix the root cause, and verify the fix broke nothing else. Splitting it into a diagnosis agent, a fix agent, and a verification agent looks like the Section 5 pipeline, but the stages share one small, tightly coupled context. The fix agent needs the diagnosis agent's exact reasoning about the root cause. A distilled summary isn't enough, because a subtly wrong distillation at the handoff is how a fix agent ends up patching the wrong thing. This task's context never came close to the size that justifies isolation, and splitting it added handoff and synthesis risk that a single agent, keeping the full diagnostic context at every step, never had.

See building agents with Claude: the agentic loop for the single-agent loop this pattern composes on top of, and context engineering for the window-budget problem that makes context isolation the reason to split work across agents.