Multi-agent systems fail on coordination, not just capability
Multi-agent LLM systems introduce failure modes that stronger base models alone don't solve. What coordination failures look like — and what to check before adding a second agent.
A core appeal of multi-agent systems (MAS) is decomposition: split a hard task across specialized agents that can work in parallel, each with a narrower slice of context. Anthropic’s own multi-agent research system outperformed a single-agent Claude Opus 4 setup by 90.2% on an internal research eval. Separately, Anthropic reports that its multi-agent systems use roughly 15× as many tokens as ordinary chat interactions.
That result gets repeated constantly; far less often cited is a large empirical study of seven open-source LLM-based MAS, which found task failure rates between 41% and 86.7% across the evaluated systems. The systems were evaluated on different benchmarks, so those rates aren’t directly comparable.
Two agents that are each individually reliable still do not compose into a reliable MAS by default — many of the additional failure modes are architectural, and they show up in predictable places.
Coordination is not an implementation detail
The instinct when adding a second agent is to treat coordination as plumbing — a queue, a shared object, a call from one agent to another.
Recent work on LLM-based multi-agent systems argues this is the wrong mental model: coordination should be treated as a separate and configurable architectural layer, decoupled from agent logic and from information access. Coupling coordination logic into agent implementation is what makes failure modes hard to diagnose later — you can’t tell whether a bad outcome came from a bad plan, a failed tool call, or lost context, because there’s no layer where that distinction is made explicit.
A related runtime-architecture proposal draws a complementary boundary at the point where model output becomes system action, calling it the stochastic-deterministic boundary: a four-part contract among a proposer, a verifier, a commit step, and a reject signal. Treated this way, failures at the model-to-action boundary become inspectable at a specific point instead of buried inside a chain of agent and tool calls.
The diagram is that contract: a stochastic proposer emits an action, a deterministic verifier accepts or rejects it, and only an accepted action becomes a durable write.
flowchart LR
P["Proposer<br/>LLM, stochastic"] -->|Propose| V["Verifier<br/>Deterministic check"]
V -->|Accept| C["Commit<br/>Durable write"]
V -->|Reject| P
Three ways coordination actually breaks
A large-scale study of MAS failures derived a 14-mode taxonomy from expert analysis of 150 traces, then applied it at scale to 1,642 traces. The failures were grouped into three categories, and each maps to something concrete you can check in your own system. The study argued that stronger base models alone are unlikely to eliminate these system-level failure modes.
| Category | Share of failures |
|---|---|
| System design and specification issues | 44.2% |
| Inter-agent misalignment | 32.3% |
| Task verification | 23.5% |
1. System design and specification issues
The task, role boundaries, or termination conditions handed to an agent are ambiguous or incomplete. An orchestrator prompt that says “delegate research to sub-agents” without defining what counts as sufficient evidence produces sub-agents that either under-deliver or keep expanding scope indefinitely.
This is the most common failure category, and it’s the one most directly exposed to design-time intervention — explicit completion criteria, role boundaries, and termination conditions remove a class of avoidable ambiguity before execution begins.
One recent finding worth taking seriously here: an ETH Zurich study found that repository-level context files like AGENTS.md did not generally improve coding-agent success rates, while increasing inference cost by more than 20%. The authors’ conclusion: unnecessary requirements in these files make tasks harder, and human-written files should stick to genuinely minimal, non-obvious requirements. Specification quality is not monotonic in length.
2. Inter-agent misalignment
Agents pursuing locally reasonable actions that don’t compose into a coherent global outcome. Two sub-agents independently investigate the same lead. A worker acts on stale information another agent already superseded.
Cognition (the team behind the coding agent Devin) argues this is why naive MAS designs are fragile by default: sub-agents that only see their own slice of context, without the trace of decisions made upstream, produce actions that are locally correct and globally wrong. Their original recommendation — share full agent traces between collaborating agents, not just individual handoff messages — applies specifically when writes to the artifact aren’t single-threaded: once more than one agent can act on it in parallel, each action carries implicit decisions that need to stay visible to every other writer, or they start conflicting.
It does not generalize to every agent in the system. A verifier is a different case entirely: it doesn’t write to the artifact, and its value comes partly from not inheriting the generator’s assumptions. Cognition’s own follow-up work found this pattern in a dedicated review agent: Devin Review catches an average of 2 bugs per PR on Devin’s own output, roughly 58% of them severe. Cognition also found that the generator-reviewer loop works best when the coding and review agents do not share context beforehand.
Cognition attributes part of that improvement to context rot: a long inherited trace can degrade judgment before the reviewer ever gets to the diff, while a clean reviewer can rediscover only the context it needs from the code itself.
Shared context helps prevent siblings from making conflicting assumptions. Clean context is what lets a verifier see past the generator’s blind spots. Conflating the two — giving every agent in the system the same trace by default — trades one failure mode for the other.
This category is also a reason to consider shared-state coordination (multiple agents reading and writing one persistent state store) instead of relying only on orchestrator-driven message passing: a durable shared state can reduce information loss between agents and make partial failures easier to recover from. It doesn’t eliminate coordination problems — consistency, conflict resolution, and write ownership become problems of their own.
3. Task verification gaps
No agent — including the orchestrator — checks a sub-agent’s output before it’s treated as ground truth for the next step.
This is the failure mode that turns a local error into a cascading one: a single hallucinated intermediate result gets consumed by three downstream agents before anyone notices. A verify step at the propose/verify/commit boundary gives the system a place to catch this before it becomes durable state; a pure pipeline of trust does not.
Verification is itself an architectural problem, not a checkbox. If the same agent that generates or refines an output also grades it, the assumptions that shaped the generation can survive the grading step. An independent verifier often needs different inputs and different acceptance criteria than the generator — and, per the section above, sometimes a different context altogether. I covered the structural fix for this in depth in Reflection vs evaluation: why the Agent-Critic pattern fails without separation of concerns.
When single-agent wins
It’s worth stating the uncomfortable finding plainly: recent work comparing single-agent LLM systems and MAS under equal thinking-token budgets found that many reported MAS advantages on multi-hop reasoning tasks disappear once compute is controlled for. Some of the gains attributed to “architecture” are better explained by unaccounted-for additional test-time computation and context effects.
Coordination overhead is a first-order cost, not a rounding error — it shows up as more tokens, more latency, more failure points, and handoff complexity that a single well-scoped agent doesn’t pay.
The practical rule that follows: MAS decomposition earns its cost only once a single agent hits a real constraint — context limits, tool-set complexity, or genuinely parallel sub-problems — that a simpler architecture can’t solve. It shouldn’t be the starting design.
What to check before you add a second agent
Before reaching for orchestration, three questions expose the main failure surfaces above:
- Is the termination condition for each agent explicit, rather than left entirely to the model’s own judgment about when it’s “done”? If not, you have a specification issue waiting to happen.
- Is context sharing matched to each agent’s role — writers of the same artifact seeing each other’s relevant decision trace, and any independent verifier deliberately not inheriting it? A missing trace between co-writers is a silent source of downstream divergence; a verifier that inherits one loses the independence that made it useful.
- Is there a verification step between a sub-agent’s output and the next agent consuming it, or is trust implicit? Implicit trust is where single failures become cascades.
None of this requires new infrastructure to answer — trace the coordination path the same way you’d trace a request through a distributed system: origin, handoff, transformation, commit.
Reliable models don't make a reliable multi-agent system on their own. Coordination is a failure surface of its own, and treating it as glue code leaves its contracts, state transitions, and verification points implicit. Add the second agent once a single agent has actually hit a constraint that decomposition solves — not before.