Why Do Multi-Agent LLM Systems Fail? The Research, the Case Studies, and the Fixes

Multi-agent systems are the most seductive idea in applied AI. One agent struggling with a hard task obviously becomes several agents that divide it up, check each other's work, and deliver something better. It is intuitive, it demos beautifully, and it is — according to a growing body of published evidence — frequently wrong. The uncomfortable finding is not that multi-agent systems are bad. It is that their gains on real benchmarks are often minimal, while their failure surface is enormous and strangely specific. This post is about that failure surface: what breaks, how often, why, and what the teams who have actually shipped these systems do about it.

Everything below is drawn from published work — an academic study of 1,600+ annotated execution traces, plus engineering write-ups from two companies running agents in production. No invented statistics, no imagined incidents. Sources are linked at the end.

Start with the uncomfortable finding

In 2025, a team led by Mert Cemri at UC Berkeley — with co-authors including Matei Zaharia, Joseph Gonzalez and Ion Stoica — published a paper with the exact title of this post: Why Do Multi-Agent LLM Systems Fail? Their opening observation is blunt: despite enthusiasm for multi-agent LLM systems, their performance gains on popular benchmarks are often minimal.

So they did the unglamorous thing. They collected execution traces from seven popular multi-agent frameworks — MetaGPT, ChatDev, HyperAgent, AppWorld, AG2, Magentic-One and OpenManus — across coding, math and general-agent tasks, on models including GPT-4, Claude 3, Qwen2.5 and CodeLlama. Six expert human annotators read through them. They developed the taxonomy on 150 traces using grounded theory, reached an inter-annotator agreement of Cohen's κ = 0.88, and ultimately released a dataset of 1,600+ annotated traces.

What came out is MAST — the Multi-Agent System Failure Taxonomy: 14 distinct failure modes grouped into three categories. Crucially, they measured how often each one actually occurs. That distribution is the most useful thing published on this subject, so let's look at it directly.

Read that distribution slowly, because it overturns the usual intuition. The single most common failure mode is step repetition (17.14%) — agents redoing work they have already done. Second is reasoning-action mismatch (13.98%) — an agent reasons its way to a correct conclusion and then does something else. Third is failing to ask for clarification (11.65%). Meanwhile the failure everyone worries about — one agent ignoring another's input — accounts for 0.17%.

Three case studies from people who actually shipped

Academic taxonomies are only half the picture. Two of the most-read engineering write-ups on multi-agent systems come from companies that built them in anger — and they reach conclusions that are both more optimistic and more brutal than the paper. Tap between all three:

ChatDev: a 33% success rate, and fixes that weren't enough

ChatDev is one of the best-known multi-agent software companies-in-a-box: a CEO agent, a CTO agent, programmers, reviewers, testers. In the MAST study, it scored 33.33% correctness on the authors' ProgramDev benchmark. Two thirds of the time, a simulated software company staffed entirely by LLMs shipped something wrong.

The authors then did what any sensible engineer would do: they tried to fix it. They improved the prompts and added multi-level verification. It worked — a +15.6 point absolute improvement in task success. And they still concluded, in their own words, that simple fixes are insufficient for achieving reliable MAS performance and that more fundamental changes in system design are required. That is the single most important sentence in the literature: you cannot prompt-engineer your way out of a structural problem.

Anthropic: it works, and it costs 15×

The counterweight comes from Anthropic's engineering write-up on their multi-agent research system. They found the architecture genuinely wins for the right shape of problem: a lead Opus 4 agent directing Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on their internal research evaluation. Multi-agent is not a myth.

But they were equally clear about the bill and the breakage. Agents already use roughly 4× the tokens of a chat; multi-agent systems use about 15×. In fact, token usage alone explained 80% of the variance in their browsing-agent performance. And the failures they describe are almost comically concrete: agents spawning 50 subagents for a simple query, scouring the web endlessly for sources that did not exist, duplicating each other's work when instructions were vague, and preferring SEO content farms over authoritative sources.

Their guidance on when to use multi-agent is the most practical thing in the piece: it pays off for breadth-first queries that parallelize and tasks exceeding a single context window. It does not pay off for most coding, because — as they put it — most coding tasks involve fewer truly parallelizable subtasks than research does. They also note, plainly, that LLM agents are not yet great at coordinating and delegating to other agents in real time.

Cognition: don't build them (mostly)

The sharpest dissent comes from Cognition, the team behind the Devin coding agent, in an essay titled simply “Don't Build Multi-Agents.” Their argument is not about model quality at all. It is that splitting a task across parallel subagents produces fragile systems, because context is not shared and the agents make conflicting decisions. Two agents each doing something locally reasonable produce something globally incoherent.

Their two principles are worth memorizing. Share context — and share full agent traces, not just individual messages. And: actions carry implicit decisions. When Agent A picks a dark theme, that is a decision Agent B never sees but must respect. The essay's later refinement is more nuanced and, I think, correct: multi-agent works best when writes stay single-threaded and the additional agents contribute intelligence rather than actions.

The deeper reason: compounding, not stupidity

Underneath every failure mode in MAST sits a piece of arithmetic that no amount of model progress erases. Agentic systems are sequential and probabilistic. Each step has some chance of being right. Chain them, and the probabilities multiply.

This is why the MAST failure modes cluster where they do. Step repetition and unaware of termination conditions are what a system does when nothing tells it to stop. Premature termination and no or incomplete verification are what happens when nothing checks whether the chain actually succeeded. The system is not confused — it is unsupervised. And each additional agent adds another multiplication, another handoff where context can drop, another place for a locally-sensible decision to become globally wrong.

How to prevent it

The good news about a taxonomy with measured frequencies is that it tells you exactly where to spend your effort. Here is the prevention stack, each item mapped to the MAST category it defends against. Tick them off against your own system.

Against specification failures (41.77% of all failures)

• Write the spec down, per agent — an explicit role, an explicit tool allowlist, and an explicit stop condition. “Unaware of termination conditions” is 9.82% of failures on its own.
• Cap turns, time, and budget outside the model. A prompt is a suggestion; a cap is a control. This converts a silent runaway loop into a hard, catchable failure — and directly attacks step repetition, the single most common mode at 17.14%.
• Persist conversation state deliberately. Loss of conversation history (3.33%) is an engineering bug, not a model limitation. See Memory Management in Agentic AI.

Against inter-agent misalignment (36.94%)

• Share the full trace, not the last message. This is Cognition's central point and it kills conflicting implicit decisions. The techniques for doing it without blowing the context window are in Advanced Context Engineering.
• Make clarification a first-class action. Failing to ask for clarification is 11.65% of failures. Give agents an explicit ask_user tool and reward using it — a question is cheaper than a wrong deliverable.
• Close the reasoning-action gap. At 13.98%, reasoning-action mismatch is the second-biggest mode. Force structured, validated tool calls so an agent cannot reason one way and act another. Pydantic as the contract layer covers the typed-output discipline.
• Prefer single-threaded writes. Let extra agents contribute analysis; let one agent commit the change.

Against verification failures (21.30%)

• Verify every step, not just the final answer. Assert on intermediate outputs; a cascade is only visible mid-chain.
• Verify the verifier. “Incorrect verification” (6.66%) is its own failure mode — a broken checker is worse than no checker, because it manufactures confidence.
• Put a human on the irreversible steps. For anything that spends money or ships to a customer, the model proposes and a person disposes. See Human-in-the-Loop with LangGraph.

And the two rules that matter most

First: run it more than once. A multi-agent workflow is a stochastic system, and Anthropic notes that agents are non-deterministic between runs, even with identical prompts. One green demo is a single sample from a distribution you have not measured. Report a pass-rate across many seeds, not a screenshot. The full method is in Multi-Agent Simulation: testing agentic workflows in a sandbox.

Second: start with one agent and only add more when you must. The evidence is consistent across all three sources — multi-agent buys you parallel breadth at the price of 15× tokens, coordination overhead, and 14 new ways to fail. Add the second agent when you have a genuinely parallelizable task, not because the architecture diagram looks better with more boxes. If you are still choosing a framework, LangGraph vs CrewAI vs AutoGen compares how each handles state, handoffs and termination.

Go break one on purpose

Reading about failure modes builds vocabulary. Reproducing them builds intuition. AgentSwarms is built around exactly that loop, and there are three places to do it:

• The failure-modes deep dive — 7 Failure Modes That Kill Multi-Agent Systems is our field-engineering companion to this post: the same failures, told from the debugging chair.
• The Failure Modes Lab notebook — a 38-cell runnable notebook that reproduces 12 real production failures (hallucination snowballs, runaway loops, prompt injection, RAG poisoning, context rot, goal drift, cascading errors) and then ships the exact fix for each, with cells you can edit and re-run in the browser.
• The failure-mode swarms — in the visual swarm canvas you can load a swarm that has a fault deliberately injected — a coordination deadlock, a cascading error, a runaway loop — watch it fail in the trace, then repair it and get graded on your fix.

That last one is the closest thing to the experience the MAST annotators had: reading a real trace of a real multi-agent run and figuring out precisely where the team of agents went wrong. It is a genuinely different skill from writing prompts, and it is the one that separates a demo from a system.

The conclusion the Berkeley authors reached after 1,600 traces is worth ending on. The failures are not exotic. They are agents that repeat themselves, don't stop, don't ask, don't check, and act against their own reasoning. Fix those five things and you have fixed most of what breaks — not by making the models smarter, but by building the system as though you expected it to fail. Because it will.