Multi-Agent Orchestration: What Works and What Just Multiplies Your Problems

This is a genuine, public, unresolved tension between two teams who both ship production agent systems. Presenting it honestly is more useful than picking a side. Anthropic's position. In "How we built our multi-agent research system" (13 June 2025), Anthropic describe an orchestrator-worker architecture: a lead agent running Claude Opus 4 plans the approach and saves the plan to memory, then spawns parallel subagents running Claude Sonnet 4, each with its own context window and tool access, each chasing one independent thread. Subagents return condensed findings rather than raw transcripts. A separate citation agent handles attribution. The headline result is that this "multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%" on their internal research eval. Cognition's position. One day earlier, on 12 June 2025, Walden Yan of Cognition published "Don't Build Multi-Agents". Two principles, verbatim: 1. "Share context, and share full agent traces, not just individual messages" 2. "Actions carry implicit decisions, and conflicting decisions carry bad results" His illustration is worth retelling because it is exactly what goes wrong in practice. A parent agent splits "build a Flappy Bird clone" into two subtasks. Subagent 1 misreads the assignment and builds a Super Mario Bros background. Subagent 2 builds a bird that "doesn't look like a game asset and it moves nothing like the one in Flappy Bird". The coordinator is then left with "the undesirable task of combining these two miscommunications". Yan's diagnosis: "The decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough between the agents." Neither team has retracted. Yan's April 2026 follow-up, "Multi-Agents: What's Actually Working", sharpens rather than reverses the original: most people still should not, but a narrow class of setups genuinely works. His rule now is the most useful single sentence anyone has published on this: "multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions."

The uncomfortable detail sits in the same Anthropic post as the headline number, and it changes how you should read it. First, the token cost. Anthropic report that "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens". So the comparison is not one architecture against another at equal spend. It is a system allowed to spend roughly fifteen times as much against one that was not. Second, and more revealing, their variance decomposition: three factors explained 95% of performance variance on their research eval, with token usage alone explaining 80% of it. Read those together and a different story emerges. Most of the measured multi-agent advantage is explained by the system being permitted to spend more compute, not by the architecture being cleverer about coordination. That does not make the result wrong or unimportant. Being able to usefully spend more compute on a hard question is a real capability, and parallel subagents are a workable way to do it. But it does mean the honest question before you build a multi-agent system is not "will multiple agents beat one agent" but "will multiple agents beat one agent that is allowed to think and search fifteen times longer". Very often that single, patient, well-equipped agent captures most of the gain without any coordination risk at all. Anthropic also state the boundaries themselves, which is easy to miss under the headline. Multi-agent does not suit domains "that require all agents to share the same context or involve many dependencies between agents", and specifically: "most coding tasks involve fewer truly parallelizable tasks than research". They add that current models are not yet great at coordinating and delegating to other agents in real time. There is a second cost that compounds quietly. When each step in a chain can fail independently, overall reliability multiplies rather than averages, and more agents means more steps. The arithmetic of that is worked through in our agent reliability calculator guide, and it is worth reading before you commit to any architecture with more than a couple of hops in it.

The most valuable measurement on this page comes from CooperBench, built by Arpandeep Khatua and Hao Zhu at Stanford with collaborators at SAP Labs, published January 2026 under the title "The Curse of Coordination". The design is what makes it useful. They construct tasks where two agents build different features in shared open-source libraries that touch the same files, so coordination is genuinely required rather than nominal. This is the situation almost every real engineering team ends up in when they try to parallelise agents across a codebase. | Configuration | Task success rate | |---|---| | One agent doing both tasks alone | About 50% | | Two agents splitting the same work | 25% | Their conclusion, verbatim: "Two agents working together perform worse than one agent doing both tasks alone." A separate scaling experiment, run on a different configuration, shows the decline continuing as you add agents: | Number of agents | Task success rate | |---|---| | 2 agents | 68.6% | | 3 agents | 46.5% | | 4 agents | 30.0% | A caveat worth stating rather than hiding: those two sets of figures come from different task configurations, so read them as two separate findings, not as one continuous series. The 2-versus-1 halving is one result. The monotonic decline from 68.6% to 46.5% to 30.0% as agent count rises is another. Both point the same direction. The communication finding is the part that should change your instinct, because it kills the obvious fix. The researchers gave the agents a real-time natural-language messaging tool so they could coordinate. The result: - Communication did reduce merge conflicts. Agents produced more structurally compatible patches. - Communication did not improve overall success. The merged code did not pass more tests. - Agents spent up to 20% of their action budget on messaging. - The channel filled with the same failure modes human teams have: repetition, verbose low-information status updates, and unresponsiveness. So the agents got better at not colliding and no better at being right. One fifth of the action budget bought tidier merges and nothing else. The authors' closing assessment: "Right now, you're better off with one agent doing everything than two agents splitting the work. The coordination overhead eats the gains." They also note that industry labs work around this with explicit role hierarchies rather than peer coordination, which lines up exactly with Anthropic's star topology and with Yan's single-threaded-writes rule.

Set the headlines aside and the two camps agree on more than they disagree on. - Both agree that parallel writes are the problem. Anthropic's use case is research, which is read-only: subagents search and read, they do not edit shared state. Cognition's use case is coding, which is write-heavy by definition. - Both agree context sharing is the binding constraint on the whole approach. - Both agree coding parallelises worse than research. Anthropic say so explicitly in the same post as the 90.2% figure. - They differ mainly in emphasis. Anthropic say: here is the architecture that wins on the task class where it wins, and here is its 15x token bill. Cognition say: your task class is probably not that one. Jason Liu, who hosted Yan for a recorded session in September 2025, reached the same reading: "even Anthropic's multi-agent blog post (which seems to contradict Walden's 'Don't Build Multi-agents' post) actually agrees on these fundamental principles." The rule that falls out of this is simple enough to apply on a whiteboard before you write any code. Keep writes single-threaded. Parallelise reads. If a task involves several agents proposing changes to the same files, the evidence says you will do worse than one agent doing all of it. If a task involves several agents gathering information that a single agent will then act on, parallelism is genuinely helping and the cost is tokens rather than correctness. The mechanism behind all of this is context. Yan names it directly: "Context Rot is a well-documented phenomenon that is a result of models making less intelligent decisions at longer context lengths." Chroma Research measured it across 18 models in 2025 with task complexity held constant and only input length varying, and every model degraded, unevenly. This is why the naive fix of giving every agent all the context does not work. You cannot both satisfy Yan's first principle, share full traces, and avoid context rot by brute force. Both camps land on compression instead: subagents return condensed findings rather than transcripts, or a single agent runs with active context compression. There is a sharper version of Yan's principle that deserves attention because it is nearly self-refuting in a useful way. He argues sub-agents should have at least as much context as the main agent. Follow that honestly and it mostly argues against sub-agents, because a sub-agent holding the full parent context is just a more expensive copy of the parent.

If the rule is that additional agents should contribute intelligence rather than actions, the cleanest expression of it is the advisor pattern. A cheap executor model runs the entire agent loop, holds the context, and does all the writing. When it hits a hard decision, it consults a frontier model, gets a short answer back, and carries on. One writer, one thinker, no shared state to fight over. Anthropic productised this as an advisor tool in 2026, and the published benchmarks are the strongest evidence available that this is where the reliable gains sit. | Setup | Benchmark | Result | Cost | |---|---|---|---| | Sonnet alone | SWE-bench Multilingual | 72.1% | baseline | | Sonnet with an Opus advisor | SWE-bench Multilingual | 74.8%, a gain of 2.7 points | 11.9% lower cost per task | | Haiku alone | BrowseComp | 19.7% | baseline | | Haiku with an Opus advisor | BrowseComp | 41.2% | 85% less than Sonnet running solo | The Haiku row is the striking one. More than doubling the score of a small model while spending less than a mid-sized model does on its own is not the trade-off anyone expects from adding a second model to the loop. And the reason it works is exactly the reason multi-agent coding fails: the advisor never touches the repository. It emits typically only 400 to 700 tokens per call, pure judgement, no actions. This is the productised form of what Yan calls the "Smart Friend" pattern. Two of his other working patterns follow the same logic: - Code-Review-Loop. A review agent gives feedback to a coding agent, deliberately without shared prior context so it is not anchored by the writer's reasoning. Cognition report Devin Review catching an average of 2 bugs per pull request, 58% of them severe. - Map-reduce-and-manage. A manager splits work and children execute, with the manager holding coherence rather than delegating it. The common thread: the extra model contributes a judgement, not a commit.

Anthropic's "Building effective agents" (19 December 2024) remains the right taxonomy to work from, and their overarching rule is the one to internalise first: "You should consider adding complexity only when it demonstrably improves outcomes." They add, in the same post, that "For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough." | Pattern | Shape | Use it when | Watch for | |---|---|---|---| | Single agent with tools | One loop, one context, tools attached | The default, and almost always the right starting point. Open-ended problems where the step count is unpredictable and you cannot hardcode the path | Context rot on long runs. Needs a stopping condition and a cost ceiling | | Sequential pipeline (prompt chaining) | Fixed steps, each feeding the next | The task decomposes into a known fixed sequence, such as generate copy then translate it | Errors compound down the chain. Put a gate check between steps | | Routing | Classify the input, dispatch to a specialised handler | Input categories are genuinely distinct and your classifier is accurate, such as support triage into refunds, technical and billing | The classifier is now a single point of failure. Eval it separately | | Parallel fan-out with a synthesiser | Independent subtasks run at once, one agent merges the results | The subtasks genuinely do not need each other's output, and the merge step is read-only | Only helps if independence is real. If the subtasks write to the same place, see the CooperBench numbers above | | Orchestrator-workers | A lead agent decomposes dynamically, delegates, then synthesises | Subtasks cannot be known in advance. This is the Claude Research architecture | Roughly 15x the token cost. Only pays off on breadth-first, read-mostly work | | Evaluator-optimiser | Generator plus critic in a loop | Clear evaluation criteria exist and iteration measurably helps | Can loop forever. Needs a turn cap and an explicit exit gate | | Handoffs | Agent A transfers full control and conversation to Agent B | Sequential specialisation where only one agent is active at a time | This is the pattern that survives Yan's second principle, because control stays single-threaded | The decision rule to carry into a planning meeting: start with one agent and good tools. Move to a workflow, chaining or routing, when the path is known in advance. Move to orchestrator-workers only when the subtasks genuinely cannot be known ahead of time, and they are read-mostly, and the task is valuable enough to justify roughly fifteen times the tokens. Three conditions, all of them, not one. On frameworks, treat descriptions as functional rather than statistical, because there are no credible measured adoption figures worth quoting. LangGraph gives you an explicit graph and state machine, so control flow is inspectable and you can checkpoint and resume. CrewAI is fastest to a working demo, though its role metaphor encourages exactly the peer-coordination pattern CooperBench shows degrades. AutoGen models multi-agent work as a group conversation, which is hard to bound on cost and turns. The OpenAI Agents SDK is built around handoffs, which enforce one active agent at a time. The Claude Agent SDK gives subagents separate context windows, and Claude Code's Agent Teams uses a shared task list with claim and lock flags plus a git worktree per agent, which is a direct engineering answer to the parallel-write problem.

If you do run several agents on a codebase, these are the things that break, roughly in order of how often they catch people out. Agents undoing each other's work. Two agents given adjacent tasks both decide the same helper function needs changing, in different directions. The second write silently reverts the first. Nothing errors, and the only signal is a feature that worked an hour ago and does not now. Merge conflicts clustering on hotspot files. Conflicts are not evenly distributed. They pile up on a predictable set of files: routing tables, config, component registries, barrel exports, type definitions, database schemas, because nearly every feature touches them. Git catches the textual conflicts. It does not catch the semantic ones. Semantic conflicts that compile. The genuinely dangerous case. Two agents implement the same interface differently. Both branches compile, both pass their own tests, and the integration either breaks in a way nobody expects or silently drops a feature. There is no automated signal for this at all. It is the strongest argument for keeping writes single-threaded, and the strongest argument for having an eval suite that runs on the merged result rather than on each branch, which our guide on knowing whether AI output is right covers in detail. Stale snapshots and compounding conflict cost. Each agent branches from a frozen view of the codebase and cannot observe the others' in-flight changes. Merging branch A changes the base for every remaining branch, creating conflicts that did not exist when those branches were created. The practitioner Dave Paola frames the conflict surface across N parallel branches as roughly N times N minus 1, over 2, and notes that Amdahl's law does not model merge cost at all. That is blog reasoning rather than measurement, but it matches the shape of the CooperBench decline, and his practical scale is worth keeping in mind: two agents means occasional easy conflicts, five means frequent cascading ones, nine means agents spend more time resolving conflicts than writing code. Runaway spawning. Anthropic report early versions of Claude Research "spawning 50 subagents for simple queries" and agents "scouring the web endlessly for nonexistent sources". Their fixes were explicit termination conditions in prompts and better spawn logic, which is to say the surrounding code has to enforce limits, because the agent will not. The review bottleneck. Three agents produce three noisy diffs that overlap in surprising ways, and the human becomes the integration layer. Parallelism that moves work from the agent to the reviewer is deferred cost, not a gain. This is the failure mode that looks like success on a dashboard, because the agents all finished. The mitigations practitioners converge on are consistent, and they are all versions of the same principle: - One writer per module. Make write scopes disjoint by construction. This is Yan's second principle turned into a rule you can enforce. - Map file ownership before spawning, not after. Only parallelise tasks whose expected file sets do not overlap. - A git worktree per agent, so agents cannot clobber a shared index. - A serialised merge queue with automated verification before anything lands. - Each agent returns a receipt: files changed, commands run, checks passed, risks left open. One integration pass can then reconcile without re-deriving everything from the diff. - Turn caps and boolean exit gates enforced by the surrounding code rather than by the agent's own assessment of whether it is done.

Do multi-agent systems actually work better than a single agent? For read-heavy, parallelisable work, yes. Anthropic measured a multi-agent research system outperforming single-agent Claude Opus 4 by 90.2% on their internal research eval in 2025. For write-heavy work on shared files, no. CooperBench measured task success roughly halving, from about 50% to 25%, when the same coding work was split between two agents. Why did the multi-agent system win by so much on research? Partly architecture and substantially compute. In the same post, Anthropic report that multi-agent systems use about 15x more tokens than chat interactions, and that token usage alone explained 80% of performance variance on their eval. Before building one, it is worth checking whether letting a single agent search and think for longer captures most of the gain without the coordination risk. Does letting agents talk to each other fix coordination problems? Not in the only controlled measurement available. CooperBench gave agents a real-time messaging tool. It reduced merge conflicts, so patches were more structurally compatible, but overall task success did not improve, and agents spent up to 20% of their action budget on the messaging itself. Better-coordinated agents were not more correct agents. What is the safest way to add a second model to my system? The advisor pattern, where a cheaper executor runs the loop and consults a frontier model only when stuck. Anthropic's published benchmarks show Sonnet with an Opus advisor scoring 74.8% on SWE-bench Multilingual against 72.1% alone, at 11.9% lower cost per task, and Haiku with an Opus advisor going from 19.7% to 41.2% on BrowseComp at 85% less cost than Sonnet running solo. Advisor calls are typically only 400 to 700 tokens. The advisor never writes anything, which is exactly why it works. How many agents is too many? The measured trend goes the wrong way immediately. CooperBench's scaling run showed success falling from 68.6% with 2 agents to 46.5% with 3 and 30.0% with 4. Note that this series comes from a different configuration to their 2-versus-1 result, so treat it as a separate finding, but the direction is consistent. For coding work with shared files, treat every agent past the first as something you have to justify. Should I use a multi-agent framework? Only after you have a task that meets all three conditions: the subtasks cannot be known in advance, the work is read-mostly, and the outcome justifies roughly fifteen times the tokens. Anthropic's own guidance is that "You should consider adding complexity only when it demonstrably improves outcomes", and that for many applications a single well-equipped LLM call with retrieval is enough. Why do agents lose context when handing work to each other? Because they pass messages, not traces. A subagent told to "build the bird sprite" never sees the discussion that settled the art style, the framework choice or the physics constants, so it fills those gaps with its own assumptions, and the assumptions stay invisible until integration. That is Walden Yan's first principle: "Share context, and share full agent traces, not just individual messages."