Why multi-agent LLM systems fail: 14 failure modes from 1,600 traces

The short answer

Multi-agent LLM systems, where several model-driven agents split and pass work between them, fail in recognisable ways. A 2025 study by researchers including Ion Stoica and Joseph Gonzalez built a taxonomy called MAST from 150 traces, then annotated over 1,600 traces from seven popular frameworks. It found 14 failure modes in three groups: system design issues, misalignment between agents, and task verification.¹

The most common were step repetition (15.7%), a mismatch between an agent’s reasoning and its action (13.2%), and agents not knowing when to stop (12.4%). Improving role specifications raised one system’s success by 9.4%, and adding a high-level verification step raised it by 15.6%, but failures remained.¹ For anyone running agents that hand work to each other, the practical lesson is to verify outcomes at the end and record who did what along the way.

How the study was done

The authors first read 150 traces closely to define failure modes, then validated the taxonomy with human annotators, reaching inter-annotator agreement of kappa 0.88.¹ They then annotated more than 1,600 traces from seven multi-agent frameworks, across models including GPT-4, Claude 3, Qwen2.5 and CodeLlama, on coding, math and general tasks, and built an LLM-as-a-judge pipeline that agreed well with human annotations to scale the labelling.¹

The 14 failure modes

From the paper, with the share of observed failures for each:¹

Two observations. Exotic failures, such as one agent withholding information from another, are rare. And the verification group together, premature stops, missing checks and wrong checks, accounts for a large share: a system often believes it’s finished when it isn’t.

What the top three have in common

Step repetition. An agent repeats work already done, often because another agent’s output didn’t register as complete. Costly in time and tokens, and dangerous when the repeated step writes: a second refund, a second email, a second row.

Reasoning-action mismatch. The agent’s stated reasoning says one thing and its action does another. For anyone reviewing transcripts, this is the key finding: what an agent says it’s doing is not a reliable record of what it did.

Unaware of termination conditions. Agents keep going past the point where the task was done, or loop without a stopping rule. Without an external limit, a loop can run up cost or repeat side effects.

All three are visible only by looking at actions and their effects, not at the conversation. That is the same conclusion single-agent benchmarks reached: τ-bench grades the final database state rather than the dialogue.²

What fixes helped

The paper tested interventions on ChatDev, a multi-agent software development framework:¹

The verification step helped most, which fits the failure table. The authors are clear that these fixes didn’t resolve all failure modes and overall completion stayed low, and they argue the failures need more sophisticated solutions, starting with better system design.¹

Should you use several agents at all?

The study doesn’t argue against multi-agent designs, but its findings are a reason to ask whether you need one. Every hand-off between agents adds places for the failures above: a reset conversation, an ignored input, a task that drifts, a verification that one agent assumes another did. A single agent with a clear tool set and a final check avoids most of the inter-agent column entirely.

Multi-agent designs earn their complexity when the work genuinely splits into parts that need different tools, permissions or context, and when you can check each part’s result independently. If you can’t name the check that confirms each agent’s output, the extra agents mostly add more ways to fail quietly. Start with one agent, measure where it falls short, and add a second only for that gap.

Records for multi-agent systems

When work passes between agents, a failure can start in one agent and surface in another. Investigating it needs a record of the chain: which person started the task, which agent asked which, with what arguments, and what each step changed. A transcript per agent is not enough, because of the reasoning-action mismatch above.

We built a version of this for agent-to-agent calls. Deedglass’s A2A proxy puts its rules between an agent and a remote agent reached over A2A, forwarding message and task calls only when the policy allows.³ A two-agent delegation shows the whole chain, from the person to the remote agent, in the action history and the record.³ The limit is stated plainly: the remote agent’s answer is recorded as what the peer reported, not what it did.³ A gate between agents can see the hand-offs; checking each agent’s effects still needs a check at the system it changed.

A checklist

1. Verify the outcome at the end, against the system’s state, with a step that doesn’t trust earlier agents’ reports.
2. Make repeated writes safe with idempotency keys, so step repetition can’t duplicate effects.
3. Set hard limits: maximum steps, time and spend per task, enforced outside the agents. Our kill switch post covers stopping agents fast.
4. Write explicit role and termination rules into each agent’s instructions.
5. Record every hand-off with who asked whom and on whose behalf; the agent action record entry describes a format.
6. Evaluate by effects, as in how to evaluate agent actions; use model judges only for text, as the LLM-as-a-judge post explains.

To see actions checked against a real database in your browser, try the playground; to grade what agents can reach on your machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.