Engineering
Parallel work without duplicated effort.
Parallelism is the most oversold and most under-specified idea in agent design. The published results show both a large upside and a well-catalogued set of ways it goes wrong. Both come from the same property: what the workers can and cannot see.
The upside is real and it is large
Anthropic's write-up of their multi-agent research system reports that a lead agent on Claude Opus 4 delegating to Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." For breadth-first research — where the work divides into genuinely independent lines of enquiry — this is not a marginal gain.
The cost line in the same post is the part people skip: "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." Anthropic's later guidance narrows the range to 3–10x for equivalent tasks. Either way, parallelism buys quality with tokens, and only pays when the task actually has independent parts.
The failure mode is duplication, not slowness
The same Anthropic post documents what goes wrong without careful task descriptions: agents "duplicate work, leave gaps, or fail to find necessary information," including subagents running the "exact same searches as other agent." Nothing about parallel execution prevents two workers doing identical work and billing you twice.
Cognition's Don't Build Multi-Agents makes the sharper version of the argument: "Actions carry implicit decisions, and conflicting decisions carry bad results." Their worked example has one subagent building a Super Mario Bros. style background while another builds an incompatible bird sprite — not because either failed, but because "the actions subagent 1 took and the actions subagent 2 took were based on conflicting assumptions not prescribed upfront."
Their recommendation is to share full agent traces rather than individual messages. That is a real constraint, and it pushes directly against the token savings that made you split the work in the first place.
The failures have been catalogued
Why Do Multi-Agent LLM Systems Fail? (Cemri et al., UC Berkeley, NeurIPS 2025) is the most useful reference here because it is systematic rather than anecdotal. The authors hand-analysed 150 execution traces and produced MAST, a taxonomy of 14 distinct failure modes in 3 categories: system design issues, inter-agent misalignment, and task verification. They released 1,600+ annotated traces across 7 popular frameworks, with inter-annotator agreement of κ = 0.88.
Their headline framing is worth sitting with: multi-agent system "performance gains on popular benchmarks are often minimal." The upside is conditional, not automatic.
Split by context, not by job title
Anthropic's guidance names the discriminating rule directly: take "a context-centric view rather than a problem-centric view when decomposing work," because "work should only be split when context can be truly isolated." Separate components with clean interfaces qualify. Tightly coupled components do not — splitting by type of work "creates constant coordination overhead."
This is why "one agent writes, one agent reviews, one agent tests" tends to disappoint. Those roles all need the same context. Whereas "one track per market, one track per data source, one track per subsystem" divides the context along with the work.
The contract is what makes the tracks non-overlapping. Without it, "divide the landscape" is an instruction two workers can satisfy identically.
Synthesis is a stage, not an afterthought
Chain of Agents (Zhang et al., NeurIPS 2024) is the cleanest published demonstration that the merge step carries real weight. Workers each handle an assigned portion plus the message passed from the previous agent, and a manager agent "synthesizes relevant information accumulated by the end of the worker-agent chain to generate the final answer."
Across nine datasets — HotpotQA, MuSiQue, NarrativeQA, Qasper, QuALITY, QMSum, GovReport, BookSum and RepoBench-P — the approach improved on strong RAG, full-context and multi-agent baselines by up to 10%, with the gap widening as inputs grew past the point where a single context could hold them.
What this means in practice
Four rules fall out of the evidence:
- Write the contract before splitting. Scope, quotas, required fields, exclusions, and what counts as a duplicate. If two workers could satisfy the brief with the same output, the brief is wrong.
- Give each track exclusive ownership. Overlapping ownership is the mechanism behind both duplicated searches and conflicting assumptions.
- Budget the synthesis step. Normalisation, deduplication, contradiction checks, and coverage reporting are work, not formatting.
- Do not parallelise coupled work. If a worker needs another worker's reasoning to decide, the coordination cost will exceed the speed-up.
Parallelism is a way to buy coverage. It is not a way to buy coherence — coherence comes from the contract and the synthesis, and both are sequential.
Sources
Every figure in this article was read from the source below on 2 August 2026. Where a source carries no publication date, an access date is given instead.
- How we built our multi-agent research system90.2% improvement over single-agent on internal research eval; ~15x token usage; documented duplicate searches.
- Building multi-agent systems: When and how to use them3-10x token cost; split only when context can be truly isolated.
- Why Do Multi-Agent LLM Systems Fail?MAST taxonomy: 14 failure modes in 3 categories, 1600+ annotated traces, κ = 0.88.
- Chain of Agents: Large Language Models Collaborating on Long-Context TasksUp to 10% improvement over strong RAG, full-context and multi-agent baselines across nine datasets.
- Don't Build Multi-AgentsConflicting implicit decisions as the core multi-agent failure; share full traces, not messages.