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-running task; nothing about that loop requires more than one agent to be technically possible. What changes when a task is split across multiple agents isn't what's possible, it's how the context accumulated by doing the work gets divided up. A single agent working a long, multi-part task carries the entire accumulated history of every subtask in one context window, which is exactly the context-rot problem context engineering describes: the more unrelated work piles into one window, the worse the model's attention gets spread across the parts that actually matter for the step it's on right now. Multi-agent orchestration is a design for containing that, not a separate capability the model didn't already have.

2. The orchestrator-worker pattern

The dominant shape in practice is one orchestrator agent that holds the overall task and decomposes it into scoped subtasks, dispatching each to a worker (subagent) that receives only what it needs for that one piece, does the work, and returns a result back to the orchestrator. The orchestrator never delegates its own judgment about how the pieces fit together; it delegates the execution of a bounded piece, then integrates what comes back. This is structurally the same shape as a manager assigning a well-scoped task rather than narrating every step of how to do it, and the analogy is useful for spotting a bad decomposition: a subtask handed to a worker with an ambiguous boundary, or with dependencies on another worker's not-yet-finished output, produces the same confusion a badly scoped work assignment would.

3. Context isolation is the actual benefit

The concrete payoff of the pattern is that a worker agent's context contains only what its specific subtask needs, not the accumulated history of every other subtask the orchestrator has dispatched or received. A research task broken into five independent sub-questions, each dispatched to its own worker, means each worker's context holds only its one question and the sources it gathers answering it, rather than a single agent's context growing by the full reading history of all five questions combined, most of which is irrelevant to the reasoning needed for questions two through five once question one is done. The orchestrator's own context stays smaller too: it holds the five subtasks and their five returned results, not the full working history each worker generated getting there, so an orchestrator that has dispatched a dozen subtasks isn't carrying a dozen workers' worth of scratch work in its own window, only the distilled answers.

This is the same case for offloading tool-result bloat to a file that context engineering describes, applied at the scale of a whole subtask instead of a single tool call: work that would otherwise bloat one shared context happens somewhere isolated, and only the result that matters crosses back into the context that has to reason about the bigger picture.

4. Coordination failure modes

Splitting work introduces failure modes a single agent structurally can't have, because a single agent's context is never inconsistent with itself. Duplicated work happens when the orchestrator's decomposition has genuine overlap between two subtasks, and two workers independently do largely the same research or reach largely the same conclusion, wasting the calls both of them made and, worse, sometimes returning subtly different answers to what was actually the same underlying question, leaving the orchestrator to reconcile a disagreement neither worker was in a position to know existed. Conflicting writes happen when workers operate on shared state, a shared document, a shared set of records, without a defined ownership boundary, and two workers' changes land in a way that isn't simply the union of two independent edits.

Lost handoffs are the quieter failure: a worker returns a result that's genuinely complete for the narrow question it was asked, but the orchestrator's synthesis step drops or misweights it, the same lost-in-the-middle risk context engineering describes, now applied to five workers' results competing for the orchestrator's attention instead of five documents. None of these are argument against the pattern; they're the concrete cost of the coordination it introduces, and a decomposition that doesn't create genuine subtask independence, ownership, and a synthesis step actually built to weigh every returned result, pays that cost without getting the context-isolation benefit that was supposed to be worth it.

5. Sequential pipelines versus parallel fan-out

Not every multi-agent decomposition is parallel. A sequential pipeline, where each stage's output is the next stage's input, a drafting agent followed by a review agent followed by a formatting agent, gets a different benefit from the same underlying mechanism: each stage's context is scoped to its own concern, and a review agent judging a draft doesn't carry the drafting agent's exploratory dead ends and discarded approaches into its own reasoning, only the finished draft it's actually meant to evaluate. Parallel fan-out, several genuinely independent subtasks dispatched at once, buys wall-clock time on top of the context benefit, at the cost of the coordination risks in Section 4 becoming live the moment two workers' subtasks turn out not to be as independent as the decomposition assumed.

The choice between the two isn't a preference, it's a direct read on whether the subtasks are actually independent of each other's output. Subtasks with a real dependency, stage two genuinely needs stage one's finished result to start correctly, belong in a sequential pipeline; forcing them into parallel fan-out to save time produces exactly the conflicting-state and lost-dependency failures Section 4 describes, because the independence the pattern assumes was never actually there.

6. When one better-equipped agent wins

A task with a genuinely small, well-scoped context requirement, one that a single agent's window comfortably holds without approaching the degradation context engineering describes, gets nothing from being split, and pays the coordination overhead of Section 4 for no benefit: extra round trips dispatching and collecting subtask results, an orchestration and synthesis layer that's itself a new source of bugs, and latency from the coordination steps that a single agent working straight through wouldn't have paid at all. The decomposition only earns its cost when the task's context requirement genuinely doesn't fit comfortably in one window, or when the subtasks have a real, independent structure that benefits from isolation, not whenever a task merely sounds complex enough to justify more than one agent.

A frequent, avoidable mistake is reaching for multi-agent orchestration as a first design instinct for anything that looks hard, when the actual problem is that a single agent's tools or system prompt weren't well designed for the task, and better tool design or a tighter, more scoped prompt would have solved it directly, with none of the coordination cost a multi-agent split adds on top.

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

A research task asking for a comparison across five competing products, each requiring independent web research and a structured summary, is a strong fit for parallel fan-out: the five products don't depend on each other's research, each worker's context needs only its one product's sources, and the orchestrator's synthesis step is a genuinely bounded job, combining five structured summaries into one comparison, not reconciling five workers' worth of open-ended, potentially conflicting exploratory reasoning.

Contrast that with a task asking an agent to debug a single failing test, then fix the root cause, then verify the fix didn't break anything else. Splitting this into three agents, a diagnosis agent, a fix agent, and a verification agent, looks superficially similar to the pipeline pattern in Section 5, but the stages here share a single, small, tightly coupled context: the fix agent needs the diagnosis agent's exact reasoning about the root cause, not just a distilled summary of it, because a subtly wrong distillation at the handoff is exactly how a fix agent ends up patching the wrong thing. This task's context never approached the size that would justify isolation in the first place, and splitting it added a synthesis and handoff risk the single-agent version, working straight through with the full diagnostic context intact at every step, never had to pay.

This pairs with building agents with Claude: the agentic loop for the single-agent loop mechanics this pattern composes on top of, and with context engineering for the underlying window-budget problem that makes context isolation the actual, load-bearing benefit of splitting work across agents in the first place.