Five connected processing blocks stand on a shared foundation split by a crack.

How multi-agent systems fail, ordered by how late you find out

A loop pages you in minutes. A verifier that only checks that the code compiles can pass broken work for weeks. Multi-agent failures, sorted by how long each one hides.

Andrei Gaspar

· 10 min read

Multi-agent systems fail at three speeds. A deadlocked handoff or a delegation loop is loud: you hear about it in minutes. Duplicated work and runaway fan-out are slower, and they arrive on the bill. The silent failures pass every check. The agents agree, the verifier approves, nothing errors, and the output stays wrong for weeks.

The order matters because the cost of catching each class runs the other way. A loop needs a counter. A verifier that approves broken work needs a test of the verifier, written before anyone knows it is broken. It is tempting to build signals in the order failures announce themselves, and that order is backwards.

The evidence comes from a handful of sources that looked hard at the failures. Cemri et al.'s Why Do Multi-Agent LLM Systems Fail? annotated 1,642 execution traces from seven open-source frameworks, most of them with an LLM judge calibrated against human labels. They sorted what broke into 14 failure modes, a taxonomy they call MAST. Anthropic wrote up what the early versions of its multi-agent research system got wrong. Its Frontier Red Team ran fleets of agents to watch them fail together. Cognition's Walden Yan argued against the whole planner-and-workers shape in Don't Build Multi-Agents. The structures themselves are laid out in The ReAct agent loop fits on a page; this piece is the failure side.

The taxonomy, sorted by time to detection

Each row is a failure class, where it shows up, how long it tends to hide, and the signal that would catch it sooner. The detection times are orders of magnitude reasoned from the mechanism, not measurements. Read the last two columns top to bottom. The signals get more expensive as the failures get quieter, and the bottom rows need a signal somebody has to design.

FailureHow it shows upTime to detectionSignal that catches itWhat the signal costs
Deadlocked handoffRun hangs with no outputMinutesWall-clock timeout on every handoffA timer
Delegation or step loopSame call repeated; run never endsMinutes, if something is countingStep budget; repeated-call detectorA counter and a hash
Crash or tool timeoutError in the logsMinutesError rate per agent roleAlerting you already run
Over-delegationMore subagents than the task needsDays, on the invoiceTokens and subagents per run, by task classTagging every model call with run and agent ids
Duplicated workTwo agents do the same thingHours at a merge, days on the billOverlap between what sibling agents touchedLogging every file or URL per agent
ContentionAgents swamp one shared resourceHours to daysRequests per success on each shared resourceOne metric per resource
Unread acceptanceAn agent accepts a claim its own trace contradictsWeeksClaimed actions checked against the tool logStructured claims on every handoff
Withheld informationA decision made without a fact another agent heldWeeks, or neverHidden-fact probe tasksWriting probes; extra runs
ConformityIndependent agents converge on one answerWeeksSpread of outputs across parallel agentsSampling and comparing outputs
Premature terminationRun reports done with work missingDays to weeksObjective-level check at the endOne more model call per run
Verification that checks nothingVerifier approves broken outputWeeksCatch rate on seeded faultsBuilding known-bad cases

Loud: the failures that page you

Loud failures stop the run. A deadlocked handoff is two agents each waiting on the other. The planner waits for a worker's result; the worker waits for a clarification the planner never sends. A delegation loop is a planner that hands a task down, gets back something it cannot use, and hands it down again. Crashes and tool timeouts need no description.

MAST counts the loop's relatives, and they are common. Step repetition, an agent redoing steps it already finished, is the most frequent of the 14 modes at 15.7% of labeled failures. Being unaware of termination conditions is 12.4%. In one of the paper's examples, an AG2 math run, the proxy agent keeps telling the solver to continue after the solver has said it cannot go on without more information. Anthropic's write-up adds the synchronous version. When a lead agent waits on its subagents, "the entire system can be blocked while waiting for a single subagent to finish searching."

A loop is loud only if something is counting. Without a step budget, a loop is a run that never ends, and a run that never ends shows up as a bill. The cheapest signals in the whole taxonomy live here. Put a wall-clock timeout on every handoff and a step budget on every agent. Add a detector that hashes each tool call's name and arguments and flags the third repeat. Each is a few lines in the harness.

The bill for these signals is false positives. A research task that legitimately runs for an hour trips a budget set for a lookup. Set budgets per task class, and log every budget stop with the run id so someone can tell a real loop from a long task. The budgets exist to turn the quiet versions of these failures into loud ones.

Sponsored: Gitdailies — Install today. Move faster daily.

On the bill: duplicated work and runaway fan-out

The middle class of failure completes the task. It does the work twice, or with ten agents where one would do, and nothing in the output says so.

Anthropic's list of what its early research agents did reads like a field guide to this class: "spawning 50 subagents for simple queries," "scouring the web endlessly for nonexistent sources," and "distracting each other with excessive updates." Given vague task descriptions, subagents duplicated each other. For instance, "one subagent explored the 2021 automotive chip crisis" while "2 others duplicated work investigating current 2025 supply chains." The remedy the team describes is a contract for every delegation: "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."

The team also wrote effort rules into the prompt. "Simple fact-finding requires just 1 agent with 3-10 tool calls." Direct comparisons might need two to four subagents with 10 to 15 calls each, and complex research might use more than ten. Those rules double as a monitoring spec. If the prompt says a fact-finding query gets one agent, a fact-finding run with six agents is a finding, and you can alert on it.

The multiplier is large enough to deserve the alert. Anthropic reports that, in its data, multi-agent systems use about 15× more tokens than chats. It also found that "token usage by itself explains 80% of the variance" on its BrowseComp evaluation. That second number cuts both ways. Spending more is how the system gets better, which makes over-spending hard to tell apart from effort in a single run. Only the distribution per task class separates the two. Where the tokens go is its own piece.

Contention is the same failure pointed at a shared resource. The Frontier Red Team gave agents a bandwidth-limited job system and no other way to coordinate, and they flooded it with polling daemons. "In one run there were 2.4 million job requests and only 117 jobs accepted." A requests-per-success ratio on each shared resource catches that in hours. Overlap catches duplication: log every file path or URL each agent touched, and compare sibling agents. Both signals depend on per-agent tracing, which is the subject of agent observability after an incident.

Silent: agents that agree without checking

The silent class produces an answer, and the answer looks fine. Nothing errors, because no agent disagreed.

The plainest case in the MAST appendix is a HyperAgent run on a matplotlib bug. The Executor says the output it returned is "just an example." The Planner replies, "Thank you for running the test and providing the results," and carries on as if the tests had passed. The Planner received a message that said what it was, and acted as if it had not read it. MAST labels that trace with role disobedience and information withholding, and files its neighbors under inter-agent misalignment: reasoning-action mismatch at 13.2%, ignoring another agent's input at 1.9%, and information withholding at 0.85%.

That last figure looks reassuring. As evidence of rarity, it is weak. Withholding leaves no mark in a transcript; the missing message is missing. The paper's own Insight 2 says similar surface behavior can come from withholding, ignored input, or context loss. Telling them apart takes a close read. Its Figure 3 shows a withholding case. A Phone Agent never tells the Supervisor Agent the username format an API requires. The supervisor never asks, and the run ends in repeated failed logins. That run ended loud only because the API refused. When nothing downstream refuses, withholding is silent.

The Frontier Red Team tested this directly with hidden-profile tasks. The shared evidence points to the wrong choice, and individual agents hold the private facts that should decide it. Performance rose with model capability and did not saturate even at the top of the range they tested. They note that this matches the human literature, in which "unshared facts are either never volunteered or not pressed once a consensus has formed."

Conformity is the fleet-sized version. Agents on the same model with the same context make correlated choices. In one run, 18 of 30 agents created a git branch with the same name, "mvp-game-loop." A branch name collides at merge time and gets noticed. The same correlation in a judgment call collides with nothing, and the red team's summary of the risk is exact: "What would have been isolated problems can quickly become systemic failures."

Yan's Flappy Bird thought experiment at Cognition shows the opposite mechanism with the same outcome. Two subagents build a background and a bird. Even with the earlier context shared, neither can see what the other is doing, and the two visual styles can conflict. His second principle names it: "Actions carry implicit decisions, and conflicting decisions carry bad results."

The signals here cost design work, and each one has a price you can name.

  • Claim checks. When an agent reports an action ("ran the tests," "applied the edit"), check the tool log for that call and its result. The check is deterministic and cheap to run. The cost is a contract change: claims have to travel as structured fields on every handoff.
  • Disagreement rate. Chart how often each reviewing agent says no, per week. A reviewer that never rejects is either reviewing perfect work or not reading it. The metric is free once verdicts are structured.
  • Hidden-fact probes. Write tasks where one agent holds the deciding fact, and measure how often the group reaches the right decision. This is an eval suite, with the costs an eval suite carries: somebody writes the cases, and every run spends tokens.
  • Output spread. For parallel agents on a judgment call, compare their answers. Near-identical answers from agents that share a model and a prompt are a shared prior, not independent confirmation.

Verifiers that check nothing

MAST's third category is task verification: premature termination at 6.2%, no or incomplete verification at 8.2%, and incorrect verification at 9.1%. Together that is 23.5% of the labeled failures. These arrive last because a verifier's approval is the signal everything else trusts. When the verifier checks the wrong thing, every dashboard downstream of it is green.

The authors are blunt about what they saw. "Many existing verifiers perform only superficial checks, despite being prompted to perform thorough verification, such as checking if the code compiles or if there are leftover TODO comments." Their example is a ChatDev chess program that passes code compilation and contains runtime bugs, because nothing validated it against the rules of chess. Premature termination looks similar from outside: in another HyperAgent run, the editor claimed an edit it never made.

In the paper's comparison, fewer design and coordination failures did not buy better verification. MetaGPT showed 60–68% fewer system-design and misalignment failures than ChatDev on the same benchmark, and 1.56 times more verification failures. The fix the paper measured was structural. The authors turned ChatDev's workflow into a loop that ends only when the CTO agent confirms every review is satisfied, a high-level check against the task objective. Task success on ProgramDev-v0, a variant of the benchmark, rose 15.6 points, from 25.0% to 40.6%. The authors add that "not all failure modes are resolved, and task completion rates still remain low."

The signal that catches a hollow verifier is a mutation test for the verifier. Seed outputs you broke on purpose: a function that compiles and returns the wrong total, a chess move that breaks the rules, a diff whose summary claims a file it did not touch. Run the verifier on them and count what it passes. The cost is real. Somebody writes the faults, every seed costs a verifier call, and the set goes stale whenever the verifier's prompt changes. It is still the only signal in the table that tests the checker everything else trusts.

Multi-agent systems pay for every seam

Each handoff between agents adds rows to the bottom of the table. A single loop can still loop, crash, and stop early. It cannot withhold a fact from itself or accept its own output unread in the way two agents can.

The sources come at that line from different directions. Anthropic's team writes that multi-agent systems excel at "valuable tasks that involve heavy parallelization." It names domains that "require all agents to share the same context" as a poor fit today. It adds that "most coding tasks involve fewer truly parallelizable tasks than research." Yan, writing in June 2025, goes further: he argues teams should by default rule out any architecture that breaks his two principles. MAST's first insight comes from the other side. Failures are "not merely a function of challenges in the underlying model." In one ChatDev intervention, a prompt change that let only senior agents end a conversation, so the CEO had the final say, contributed to a 9.4-point rise in task success. The red team's conclusion covers both: "Coordination doesn't naturally emerge from stronger intelligence nor alignment at the individual level."

The working rule follows. Before you add an agent, write down which row of the table it adds, the signal that would catch that row's silent version, and what the signal costs. If you cannot afford the signal, you cannot afford the agent. A second agent that exists to make the diagram symmetrical adds a seam and no capability, and its failures sit in the rows nobody is watching.

Monday

Put a wall-clock timeout on every handoff, a step budget on every agent, and a repeated-call detector in the harness. Then replay last week's runs against those limits and count how many each one would have stopped.

Break ten outputs on purpose, of the kind your verifier is meant to reject, and run the verifier on them. Each one it passes is a class of broken output your green runs could be hiding.

Pull every verdict your reviewing agent returned last month and compute how often it said no. If the answer is never, read ten of the approvals yourself.

This blog exists thanks to the support of our sponsors:

GitdailiesQA.techAppSignalSuperlinked

Comments

Loading comments…

Keep reading