Most multi-agent systems break for the same reason distributed teams break: the agents cannot see what the other agents did, and no one owns the final decision. A UC Berkeley study of more than 1,600 execution traces across seven popular frameworks found that roughly 79 percent of failures trace back to bad specification and coordination breakdowns, with weak verification behind the rest (Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv, March 2025). The bottleneck is rarely the model or the GPU budget. It is the wiring between agents. If you are deciding whether to build one, the honest answer is that coordination cost scales faster than the value most people expect to get back.
What actually fails when a multi-agent system fails?
The Berkeley team built a taxonomy they call MAST from expert annotation of agent traces, reaching high inter-annotator agreement (κ = 0.88) before scaling the labelling across 1,600-plus traces. It landed on 14 distinct failure modes grouped into three families. The split is worth memorising: specification and system-design issues account for about 42 percent of failures, inter-agent misalignment for about 37 percent, and task verification gaps for about 21 percent (Cemri et al., arXiv, March 2025).
Read that again. More than three quarters of the failures come from agents operating on incorrect assumptions, ignoring peer output, duplicating work, and skipping the check step, rather than from a weak model choice. Those are organisational problems reproduced in software. A stronger model does not fix an org chart.
The single most cited concrete example comes from Cognition, the team behind Devin. In their June 2025 essay Don't Build Multi-Agents, they describe two sub-agents asked to build a Flappy Bird clone in parallel. One renders a Super Mario style background. The other builds a bird that does not match the game art. Neither is wrong in isolation. Together they produce something unusable, because neither agent could see the other's context or decisions. That is coordination cost made visible.
Why does coordination get expensive faster than compute?
Compute scales the way you expect. Add a subagent, pay for its tokens. Coordination scales the way distributed systems always have, which is worse than linear.
Every agent you add creates potential communication paths with every other agent. Context that lived in one head now has to be serialised, passed, re-read, and reconciled. Each hop is a place for meaning to drift. Anthropic, describing their own research system in June 2025, reported that multi-agent setups burned roughly 15 times more tokens than a normal chat interaction, and that token usage alone explained about 80 percent of the variance in task performance (Anthropic Engineering, *How we built our multi-agent research system*, June 2025). A large share of those tokens goes into agents re-establishing shared state that a single agent would have kept for free, rather than into thinking.
This is the part builders underestimate. The coordination tax compounds with every additional agent and every additional step, rather than being a fixed overhead you pay once, because the surface area for misalignment grows with the number of interfaces, and each misaligned handoff triggers rework downstream. Error propagation in multi-step chains is its own subject, and it interacts badly here: a small ambiguity introduced at step one gets amplified by every agent that reads it as ground truth.
When is a multi-agent system worth the coordination tax?
Anthropic's own framing is the cleanest test I have seen. Their multi-agent research system beat a strong single-agent baseline by 90.2 percent on an internal research evaluation (Anthropic Engineering, June 2025). That is a real gain. It came on a specific shape of problem: open-ended research where the sub-tasks are genuinely independent, the directions can be explored in parallel, and the answer is worth spending a lot of tokens to get right. Legal due diligence, competitive intelligence, and biomedical literature review fit that shape.
The same essay is blunt about where the pattern falls apart. Work that requires every agent to share one evolving context, or that carries heavy dependencies between agents, is a poor fit today. That covers most enterprise workflows I see in regulated industries. A hospital discharge workflow, a claims adjudication path, a compliance review: these are chains of dependent steps over shared state, exactly the case where coordination cost dominates and the multi-agent premium buys you nothing.
So the decision rule is arithmetic. Multi-agent wins when the value of the task clearly exceeds the coordination and token cost, and when the sub-tasks are parallel and independent. If the sub-tasks talk to each other constantly, you are paying distributed-systems prices for a problem that wanted a single mind.
How do you build one that scales?
If you have concluded the task genuinely warrants multiple agents, the failure data tells you where to spend your engineering. Three things move the needle.
First, treat the specification as a living artefact. The largest failure family is specification and design. Vague role definitions and unclear task boundaries are what cause agents to duplicate work and misinterpret their scope. Write down, in structured form, what each agent owns, what it must return, and what it must never touch. Version it. When behaviour drifts, the spec is the first place to look, and often the only place that needs changing. PwC, working with the CrewAI framework, reported that structured orchestration lifted the accuracy of an internal code-generation workflow from 10 percent to 70 percent, about a 7x improvement (CrewAI, PwC Chooses CrewAI to Help Power Their Global Agent OS, 2025), which is consistent with specification being the dominant lever.
Second, make coordination an explicit architectural layer instead of an emergent property. Naive setups let agents message each other freely and hope shared understanding emerges. It does not. Give the system an orchestrator that holds the authoritative context, decides what each agent sees, and reconciles their outputs before anything moves downstream. Anthropic's winning design used exactly this: a lead agent that plans and delegates, with subagents that report back into a single controlled context rather than talking sideways to each other.
Third, verify at the boundaries. Roughly a fifth of failures are agents failing to check their own or each other's work. Cheap deterministic checks between steps, a schema validation, a constraint assertion, a small verifier model, catch drift before it propagates. This is unglamorous and it is where reliability actually comes from.
For regulated deployments there is a fourth requirement that sits on top of the other three: the coordination layer has to be auditable. If a clinical or compliance workflow produces an outcome, you need to reconstruct which agent decided what, on what context, and who approved it. Under India's DPDP Act 2023, and for anything touching clinical decisions under NMC guidance, an opaque swarm of agents passing state around is a liability. The same orchestrator that fixes reliability is what gives you the audit trail.
What this means in practice
At Nextdot we build production agent systems for regulated industries, and the pattern holds every time. The teams that scale are the ones who stopped asking "how many agents" and started asking "how little coordination can I get away with". Our voice-first CX agents live at Narayana Health and Gleneagles, with a build underway at Fortis Mulund, and the reliable ones are deliberately narrow, with a single controller holding context and hard verification at every handoff. When a workflow genuinely fans out into independent research, we split it. When it is a dependent chain over shared state, one well-specified agent with tools beats a committee of agents every time.
The compute is cheap and getting cheaper. Coordination is the cost that does not fall on Moore's law. Design for it first.
Frequently asked questions
Why do multi-agent systems fail more than single agents?
Because most failures come from coordination, specification, and verification, rather than model quality. The Berkeley MAST study attributes about 42 percent of failures to specification and design, 37 percent to inter-agent misalignment, and 21 percent to weak verification (Cemri et al., arXiv, March 2025). Adding agents adds interfaces, and each interface is a place for shared context to drift.
Are multi-agent systems ever worth it?
Yes, for open-ended tasks with independent sub-problems and high value per answer, such as research and due diligence. Anthropic's research system outperformed a single-agent baseline by 90.2 percent on that kind of work (Anthropic Engineering, June 2025). The economics fail when sub-tasks are dependent and share one evolving context.
Why do multi-agent systems cost so much more to run?
They spend a large share of tokens re-establishing shared state across agents. Anthropic measured roughly 15x the token usage of a single chat, with token volume explaining about 80 percent of performance variance (Anthropic Engineering, June 2025). Coordination overhead grows faster than the number of agents.
How do I make a multi-agent system reliable?
Write structured, versioned specifications for each agent's scope, use a single orchestrator that owns the authoritative context, and add deterministic verification at every handoff. These map directly onto the three failure families in the MAST taxonomy.
Is this safe for healthcare or compliance workflows?
Only if the coordination layer is auditable. You need to reconstruct which agent decided what, on what context, and who approved it, which the DPDP Act 2023 and NMC guidance effectively require for clinical and personal-data workflows. A controlled orchestrator gives you both reliability and the audit trail.