Why Do Multi-Agent LLM Systems Fail?

Multi-agent LLM systems mostly fail for organizational reasons, not because the underlying model is weak. MAST, the Multi-Agent System Failure Taxonomy (arXiv 2503.13657), catalogs 14 distinct failure modes in 3 categories: specification and system design, inter-agent misalignment, and task verification. Failures spread across all three with no single dominant cause, which is why they respond to design discipline (scoped roles, explicit handoff contracts, independent verification) and rarely to adding another agent.

I run two agent runtimes side by side on one production server, and I'm the one who gets woken up when they break. So a paper with this exact title got a close read. Most pages ranking for it just re-tell the taxonomy. What follows is the part they skip: which design control closes which class of failure, checked against my own incident history.

More agents, minimal gains

Start with the finding that should cool the agent-swarm hype. The authors put it plainly: "Despite the increasing adoption of MAS, their performance gains often remain minimal compared to single-agent frameworks or simple baselines like best-of-N sampling."

A team of agents, with all its role prompts and routing, often barely beats one agent. Sometimes it loses to best-of-N sampling: run one agent N times and keep the best answer.

I run one anyway, so read this as a warning about expectations, not a verdict on the architecture. More agents always costs more, and only sometimes buys you anything. Each one you add brings a role spec that can be violated, a handoff that can drop state, and an output somebody has to check. The paper's 14 failure modes are mostly a list of those costs.

The MAST taxonomy on one screen

MAST stands for Multi-Agent System Failure Taxonomy: Cemri and twelve co-authors, Berkeley among the affiliations, first posted in March 2025, revised through October 2025, accepted as a NeurIPS 2025 poster (abstract, PDF, OpenReview). It's the first structured failure taxonomy for LLM multi-agent systems, and the method is why I trust its numbers. Expert annotators worked through 150 execution traces and agreed at κ = 0.88, high for trace annotation. An LLM-as-a-judge pipeline built on the o1 model, validated against those experts, scaled the analysis; the resulting dataset, MAST-Data, covers 1,642 annotated traces across seven frameworks (ChatDev, MetaGPT, HyperAgent, AppWorld, AG2 (MathChat), Magentic-One, OpenManus), with GPT-4, Claude 3, Qwen2.5, and CodeLlama underneath, on coding, math, and general agent tasks. On out-of-domain traces, agreement with the final taxonomy held at κ = 0.79.

Here it is. Mode names are verbatim from the paper; the one-line glosses are mine.

Three notes on reading the table, since summaries often get these wrong.

First: the paper reports failure rates per mode (Figure 1), and no single mode dominates. The most frequent, step repetition and reasoning-action mismatch among them, each account for only about 12–16% of observed failures, so no single fix removes most of them.

Second: the paper states no aggregate failure share per category. If a summary hands you "category X causes N% of failures," that roll-up was added downstream; I caught one in my own early notes. Check it against Figure 1 before you repeat it, because the paper gives no such number.

Third: sum the per-mode shares yourself and specification and system design comes out the largest class, coordination second, verification third. The paper never headlines that ordering, so treat it as my arithmetic on their figure. I come back to it below.

The handoff meme is half right

Practitioner threads keep producing the same line: "it's the handoffs, not the model." I've muttered a version of it at 3 a.m. while two runtimes argued over a port. The frustration is fair. Handoffs are where production pain concentrates, and inter-agent misalignment holds the most modes, six of fourteen.

But as a reading of the data it overshoots. By mode share (the arithmetic above), specification and design is the bigger class: tasks under-specified, roles overrun, termination conditions nobody wrote down. Anyone telling you handoffs are most of the story hasn't read the distribution. What the data supports is narrower: specification failures are the largest bucket, coordination failures hurt the most in operation, and verification failures are what let the first two reach the user. The three categories need different fixes.

FC1. Specification and system design: broken before the first handoff

This category fails before the agents ever disagree. The task arrives vague, and an agent ignores a constraint that was stated (FM-1.1). Roles bleed, and an agent quietly takes over a teammate's job (FM-1.2). Work loops: step repetition (FM-1.3) is one of the most frequent modes in the corpus, an agent redoing finished work because nothing marked the step closed. Context evaporates mid-run (FM-1.4). And nobody defined "done," so the system keeps running long after the job is done (FM-1.5).

The controls are unglamorous. Write each role so narrow it feels almost insulting, then give the task the fewest agents it can get away with; each extra agent is another spec to get wrong. And treat memory as a boundary you set on purpose: decide what carries across steps and sessions and what has to be re-derived. I underrated that one for a long time. In practice FM-1.4 looks like an agent acting confidently on stale state, and it's worth designing against early.

FC2. Inter-agent misalignment: where the seams tear

The six modes here read like an operator's incident log. A conversation resets and progress evaporates (FM-2.1). An agent pushes through ambiguous input instead of asking, and the whole chain inherits its guess (FM-2.2). The task drifts off its goal (FM-2.3). One agent withholds information a teammate needs (FM-2.4), or flatly ignores what a teammate handed over (FM-2.5). The weirdest one to watch is reasoning-action mismatch (FM-2.6): the agent writes out a correct plan, then does something else. It's among the most frequent modes in the corpus, which suggests better reasoning alone doesn't buy better coordination.

My clearest view of this category comes from running two agent runtimes on one production machine. They share a host, a messenger, and a user, and most of the failures happen at the boundaries between them. Auth tokens drift out of sync between a control layer and its gateway after a restart, each side convinced it's fine while the pair fails. An update to one runtime knocks the other over. Both decide they own the same port. None of those incidents involved a weak model: every one was two components behaving as designed, with no contract covering the seam. That's FC2 running on real hardware.

The control is handoff discipline. For every seam, write down who owns the task right now, what exactly transfers (an artifact with a format, never "the vibe of the conversation"), and what gets logged so a human can replay the handoff later. If you can't replay a handoff, it's running on luck.

FC3. Task verification: success signals are hints

Three modes. The system stops early and reports completion (FM-3.1). The result ships unchecked, or half-checked (FM-3.2). Or a check runs and passes broken output (FM-3.3), worse than no check, because now you trust broken output.

The one that cost me the most sleep: a process can exit clean while the thing you cared about didn't happen. An update command reports success; the service that comes back is still on the old version. Since then I verify forward after every consequential action: inspect the state you care about (the version, the health endpoint, the artifact itself) and treat the tool's success signal as a hint, not proof. That rule is written into my update procedure, and it transfers to agent pipelines unchanged. "The sub-agent said done" deserves as much trust as "the command printed OK."

The other half of this category is deciding which verifications need a human. My line in production: an agent runs free on anything reversible and visible only to me; anything irreversible or externally visible (a sent message, a deleted record, money) waits for a yes. An agent that presses send against its own stated reasoning is FM-2.6 stacked on FM-3.2, so I design for that combination. An approval gate puts verification in the architecture, where no prompt can skip it. The specific approval list is in the chief-of-staff piece.

Why "add a verifier agent" doesn't close the loop

The reflex answer to FC3 is one more agent that checks the others. Verifiers do sometimes help. But they can't be the whole answer, and the paper carries its own rebuttal: verification failure is a category inside the taxonomy. A verifier is an agent, so it inherits the modes, and FM-3.3, the check that passes bad output, is exactly what an LLM judging an LLM produces on a bad day. The failure class is still there. Now it has a second employee.

Coordination resists the quick fix the same way. The authors argue that inter-agent misalignment demands deeper "social reasoning" from the agents, beyond another protocol layer or a longer context window, and they're explicit that solutions to these failure classes aren't trivial. The two reflexes that dominate agent-stack marketing, add an agent and add a checker, both collide with the paper's own data. A framework that promises to make the taxonomy disappear is selling open research as a feature.

What actually reduces failures

Four controls, mapped to the categories they attack. None ships as a product feature. They apply to any agent team, including the duct-tape swarm you assembled last weekend.

1. Scoped roles, minimum headcount (against FC1, and against the more-agents reflex). If you can't name what an agent uniquely owns, remove it and watch what breaks. Usually nothing does. 2. Explicit handoff contracts (against FC2). For each seam: current owner, exact payload and format, and a log complete enough to replay. Ambiguity at a seam doesn't average out; it compounds down the chain. 3. Independent verification, plus approval before irreversible actions (against FC3). The agent that produced the work never checks it. State gets inspected after actions instead of trusting exit signals. Anything external or irreversible waits for a human yes. 4. Memory boundaries (against FM-1.4 and its neighbors). Decide what persists across steps and sessions and what dies with the task. Decide what context you keep, or you'll get context that contradicts itself.

For a new build I'd implement them in that order. Rank them by how much production trouble each has saved me, and the order flips.

What MAST doesn't tell you

The taxonomy gets cited past what its data supports, so here's what it doesn't cover.

• The corpus is research systems on benchmark tasks. Seven frameworks; coding, math, and general agent work. A production system with a different topology (a single-owner assistant, say, rather than a code-writing swarm) can fail in ways this corpus never sampled, and will skip some it did.
• It's a diagnosis, not a cure. MAST tells you what broke. The controls above are engineering judgment, mine and other operators', and the paper shouldn't be cited as proof that they work.
• The percentages describe their traces only. Use them to order your hypotheses, then measure your own system before you move a roadmap.
• My production mapping is one operator's experience. Two runtimes on hosts I answer for, incidents that rhyme with the categories. It's an illustration from a sample of one.

None of that is a knock on the paper. It gives everyone the same names for the failures, which is step one toward fixing them.

FAQ

Why do multi-agent LLM systems fail? Mostly for systemic reasons rather than raw model weakness. MAST (arXiv 2503.13657) identifies 14 failure modes in 3 categories: specification and system design, inter-agent misalignment (the handoffs), and task verification. Observed failures spread across all three categories, with no single dominant cause.

What is the MAST taxonomy? MAST is the Multi-Agent System Failure Taxonomy, the first structured taxonomy of failure modes in LLM multi-agent systems. It was built from expert annotation of 150 execution traces (inter-annotator agreement κ = 0.88) and applied to a dataset of 1,642 traces across 7 frameworks, including ChatDev, MetaGPT, and Magentic-One.

Are multi-agent LLM systems better than a single agent? Not automatically. The MAST paper reports that performance gains from multi-agent systems often remain minimal compared to single-agent frameworks or simple baselines like best-of-N sampling. Every extra agent has to earn its keep.

What are the most common failure modes in multi-agent systems? No single mode dominates. Among the most frequent in the MAST corpus: step repetition, reasoning-action mismatch (an agent's actions contradict its own reasoning), disobeying the task specification, and weak or incorrect verification. The most common modes each account for only about 12–16% of observed failures.

How do you reduce failures in multi-agent LLM systems? Mainly through design, not agent count: scoped roles with the minimum number of agents, explicit handoff contracts (ownership, payload, logging), independent verification of results, human approval before irreversible or external actions, and deliberate memory boundaries between steps and sessions.

Do multi-agent systems fail because of the model or the system design? Mostly the system design. The taxonomy's three categories (specification, coordination between agents, verification) all describe how the work is organized, which is why swapping in a bigger model rarely fixes a failing multi-agent system on its own.

Does adding a verifier agent fix multi-agent failures? No. A verifier agent inherits the same failure modes: verification failure is itself a MAST category (missing, incomplete, or incorrect checks). The paper also argues that coordination failures call for deeper "social reasoning" rather than just another protocol layer.

Ilya Prudnikov writes this because he builds and runs a multi-agent system in production ([Cain](https://cain-ai.com)): two agent runtimes on one server, seams and all. These are an operator's notes on the paper, not a substitute for reading it; the original: [arxiv.org/abs/2503.13657](https://arxiv.org/abs/2503.13657).