Why Multi-Agent Systems Fail: 14 Failure Modes
Fourteen. That is how many distinct failure modes Berkeley researchers catalogued after reading 200-plus execution traces from seven popular multi-agent systems. The uncomfortable part: most failures did not come from a weak model. They came from how the agents were wired together.
The study — Why Do Multi-Agent LLM Systems Fail? (Cemri et al., UC Berkeley, March 2025) — is the closest thing the field has to a crash-investigation report. Anyone building multi-agent systems should treat it as required reading.
The short version
- Berkeley's MAST taxonomy identifies 14 failure modes in multi-agent LLM systems, grouped into three categories: specification failures, inter-agent misalignment, and weak verification or termination.
- In the frameworks studied, task correctness dropped as low as roughly 25% — on tasks the underlying model could often handle alone.
- Reliability compounds against you: at 99% per-step success, a 50-step pipeline finishes correctly only about 61% of the time. At 95% per step, a 20-step pipeline drops to about 36%.
- Most catalogued failures are architectural — bad role definitions, agents ignoring each other's outputs, and verifiers that rubber-stamp results.
- The fix is not a bigger model. It is an orchestration layer that plans, checks, and remembers between steps.
The taxonomy: three ways coordination breaks
MAST (Multi-Agent System Failure Taxonomy) sorts every observed failure into three buckets. The examples below are the patterns that showed up again and again across frameworks like ChatDev, MetaGPT, and AutoGen.
| Category | What breaks | Typical symptom |
|---|---|---|
| Specification failures | The system design itself | Vague role definitions, agents that disobey their own constraints, steps repeated or skipped |
| Inter-agent misalignment | Communication between agents | One agent ignores another's output, withholds information, or derails the conversation |
| Verification and termination | Quality control at the end | The verifier approves wrong answers, or the system stops before the task is done |
Two things stand out. First, none of these buckets is "the model hallucinated." The model sits inside a structure, and the structure fails. Second, the third bucket — verification — is where cheap fixes live. A verifier that actually checks work catches failures from the other two buckets before they reach the user.
ChatDev, the multi-agent "software company" framework, illustrates the stakes. In the study's evaluation, its correctness on programming tasks fell to roughly 25% — even though the individual model calls inside it were each locally reasonable.
Why do multi-agent systems fail more often than single agents?
Because errors compound across steps and agents. A single agent with 99% per-step reliability completes a 50-step task about 61% of the time. Add hand-offs between agents — each a chance to lose context or misread intent — and the coordination surface grows faster than the capability does.
The arithmetic is unforgiving. 0.99^50 ≈ 0.605. 0.95^20 ≈ 0.358. Every hand-off between agents adds steps: serialize the context, transmit it, have the receiver interpret it. A five-agent pipeline is not five chances to be smart. It is dozens of extra chances to silently drop a requirement.
τ-bench (Sierra, 2024) exposed a related problem: consistency. When agents were asked to complete the same task eight separate times, the share that succeeded every time fell far below single-attempt success rates. An agent that works in your demo and fails on Tuesday is, for production purposes, an agent that fails.
Verification is the layer everyone skips
Here is the counterintuitive finding buried in MAST: adding more agents often made systems worse, but adding better verification made them better. The field's instinct — decompose harder, spawn more specialists — attacks the wrong variable.
Most frameworks bolt on a "reviewer" agent that reads a transcript and says "looks good." That is not verification; it is vibes with extra latency. Real verification means checking outputs against ground truth where it exists — does the code run, does the number match the source, does the answer satisfy the stated constraint — and forcing a retry when it does not.
This is the design thesis behind COS: treat planning, verification, and memory as the operating layer that agents run on, not as features inside any single agent. We wrote earlier about why most agent pilots never reach production and why agents still lack a memory layer. MAST supplies the missing third leg: without step-level verification, plans and memory just help you fail faster.
What to do instead of adding another agent
Start by counting your hand-offs, not your agents. Every transfer of context between agents is a failure site. If two agents can be one agent with a checklist, merge them.
Write role specifications the way you would write an API contract: inputs, outputs, refusal conditions. MAST's specification failures mostly trace to prompts that describe a persona instead of a contract.
Then move verification from the end of the pipeline into the loop. Check after every consequential step, against something machine-checkable wherever possible. Log what failed and why — a system that remembers its failures stops repeating them, which is the difference between an agent that runs and an agent that improves.
The teams shipping reliable agents in 2026 are not the ones with the most agents. They are the ones whose systems can tell, at every step, whether the work is actually done.
Frequently Asked Questions
What are multi-agent systems in AI? Multi-agent systems are architectures where several LLM-powered agents divide a task — for example, a planner, a coder, and a reviewer — and coordinate through messages. Frameworks like ChatDev, MetaGPT, and AutoGen popularized the pattern for software tasks, research, and workflow automation.
Why do multi-agent systems fail? Berkeley's MAST study found 14 recurring failure modes in three categories: flawed system specifications, misalignment between agents, and weak verification or premature termination. Most failures are architectural — errors compound across steps and hand-offs — rather than caused by the underlying model's raw capability.
Are multi-agent systems better than single agents? Not by default. Each added agent increases hand-offs, and each hand-off can lose context or introduce misreads. A single agent with strong step-level verification often beats a multi-agent pipeline with weak coordination. Add agents only when the task genuinely needs parallel, specialized work.
How do you make multi-agent systems reliable? Reduce hand-offs, define agent roles as strict contracts with explicit inputs and outputs, verify outputs against machine-checkable criteria after every consequential step, and persist failure history so the system stops repeating mistakes. Reliability comes from the orchestration layer, not from larger models.
Request access to COS → dekryptlabs.com/dispatches
Abhishek Gupta is Co-Founder at Dekrypt Labs, building COS — the capability operating system for reliable AI agents. dekryptlabs.com