Why do multi-agent LLM systems fail? The paper that asked the question in those words, presented in the NeurIPS 2025 Datasets and Benchmarks Track, annotated 1,642 execution traces from seven open-source multi-agent frameworks and measured failure rates of 41% to 86.7% on benchmark tasks [1, 2]. Its authors sort the failures into 14 modes and attribute many of them to organizational design and coordination between agents [1].
Later studies add three findings. In debates, agents switch from correct to incorrect answers in response to other agents' reasoning, and correct minority answers are often suppressed [7, 8]. One error spreads much further in some team designs than in others [11, 12]. And finding the agent and the step that caused a failure is hard from logs, more so from logs that keep only agent outputs [16, 17]. Every failure rate below comes from benchmark tasks or lab setups, so none of them is a production failure rate.
Why do multi-agent LLM systems fail?
The MAST paper defines a multi-agent system as "a collection of agents designed to interact through orchestration, enabling collective intelligence," and a failure as a run in which the system "does not achieve its intended task objectives" [1]. Its starting point was that multi-agent gains on popular benchmarks "are often minimal" [1]. Whether to split a task across agents at all is a separate question, covered in when a multi-agent system beats a single agent.
The failure rates need their context. MAST's authors note that the seven systems were measured on different benchmarks, so the rates "are not directly comparable" [1]. One benchmark, ProgramDev, was built to be "relatively straightforward" so that failure dynamics would stand out [1]. A May 2026 preprint restates MAST's range as failure "in production at rates between 41% and 87%" [34], which MAST does not claim. Why benchmark scores travel poorly is the subject of what agent benchmarks measure.
The MAST failure taxonomy
MAST stands for the Multi-Agent System Failure Taxonomy. Six expert annotators built it from over 150 traces, and three of them reached an inter-annotator agreement of κ = 0.88 [1]. An LLM annotator, calibrated against the experts at κ = 0.77, labelled the traces at scale [1].
| Category | What goes wrong | Leading modes, share of observed failures |
|---|---|---|
| System design issues (44.2%, derived) | Design decisions and poor or ambiguous prompt specifications | Step repetition 15.7%, unaware of termination conditions 12.4%, disobey task specification 11.8% |
| Inter-agent misalignment (32.35%, derived) | Information flow between agents breaks down during the run | Reasoning-action mismatch 13.2%, task derailment 7.4%, fail to ask for clarification 6.8% |
| Task verification (23.5%, derived) | Checks miss errors or fail to correct them, or the task ends early | Incorrect verification 9.1%, no or incomplete verification 8.2%, premature termination 6.2% |
Source: [1], Section 4. The category shares are sums of the October 2025 version's mode figures [1]. The April 2025 version gave 41.77%, 36.94% and 21.30% [4].
Step repetition is the "unnecessary reiteration of previously completed steps in a process" [1]. In one specification failure, a framework asked for a Wordle game without a fixed word bank "still produces code with a fixed list and new errors" [1].
Design matters apart from the model. The authors found that "a well-designed MAS can result in performance gain when using the same underlying model," and they conjecture that gains in base-model capability alone are "insufficient to address the full MAST" [1].
Verification is often too shallow. Systems with explicit verifiers showed fewer failures, yet many verifiers performed "only superficial checks", such as "checking if the code compiles or if there are leftover TODO comments" [1]. Incorrect and incomplete verification also appeared often in runs that succeeded [1]. A model developer described the same pattern in January 2026: a verifier "runs one or two tests, observes them pass, and declares success" [31]. A check of claims against their sources is set out in how to check LLM citations against their sources.
When agents talk each other out of the right answer
Pitre et al., a preprint of 23 October 2026, built a failure taxonomy from 3,211 failed multi-round trajectories across six task families [7]. Failures to recover from or correct an error appeared in 94.9% of the failed trajectories and failures in reaching a group decision in 83.4% [7]. Many failures emerged in round 2, after agents first saw their peers' answers, and correct minority signals were "often suppressed rather than amplified, especially in larger groups" [7]. Going from three agents to seven, rescues by a single agent fell from 7.87% to 2.50% and suppression rose from 11.37% to 17.70% [7].
Successful runs had errors too: 91.2% of 500 successful trajectories contained at least one [7]. Persistent wrong framing after a correction had a prevalence of 0.08 in successful trajectories and 0.60 in failed ones [7]. In the authors' reading, what separated the two groups was recovery from errors [7].
The debate studies point the same way. Wynn et al. found that agents "frequently shift from correct to incorrect answers in response to peer reasoning," and that on CommonSenseQA debate always lowered accuracy [8]. Choi et al. found that majority voting alone "accounts for most of the performance gains typically attributed to" multi-agent debate [9].
How one error spreads through a team
Kim et al. ran 260 configurations across six benchmarks, five architectures and three model families [11]. Independent agents, with no coordination between them, amplified trace-level errors 17.2 times, against 4.4 times under a central orchestrator that validates work before combining it [11]. Two caveats come with those figures. They are estimated from token analysis of execution traces, and the task-level factor is about 1.1 to 1.3 [11]. Once other coordination measures are controlled, error amplification does not significantly predict performance (p = 0.658) [11].
Placement matters. Xie et al. injected errors into teams arranged as chains, meshes and stars [12]. An error injected at the hub reached an infection rate of 100.0% in both star frameworks, against 15.9% and 9.7% when injected at a leaf [12]. In 307 failures from two agentic workflow platforms, Ma et al. found the root cause in a different node from the symptom 32% of the time, and in over 10% of cases the distance exceeded 40% of the workflow's length [14].
Outside content can spread the same way. Triedman et al. found that, with the agents running on one model, web content made a multi-agent system run arbitrary malicious code in 58% to 90% of trials, depending on the orchestrator, "even if individual agents are not susceptible to direct or indirect prompt injection" [23]. The OWASP Top 10 for Agentic Applications for 2026 lists insecure inter-agent communication as ASI07 and cascading failures as ASI08 [25].
Finding the agent and step that failed
Who&When, an ICML 2025 benchmark, collected failure logs from 127 multi-agent systems [16]. The top method identified the responsible agent 53.5% of the time and the decisive step 14.2% of the time, and some methods scored below random [16]. Labelling by hand is costly too: three annotators spent 30.9, 30.2 and 23.2 hours [16].
Logs that hold more help. TraceElephant, accepted at ACL 2026, found that full traces raised accuracy to 65.9% for agents and 30.3% for steps, gains of 22% and 76% over traces that keep only agent outputs [17]. MP-Bench, a March 2026 preprint, found that of the steps its three expert annotators marked as failure-inducing, only 16.2% were marked by all three and 56.1% by just one, and argues that earlier low scores largely reflect benchmark design [18]. A model developer noted in June 2025 that agents "are non-deterministic between runs, even with identical prompts," which "makes debugging harder" [30]. The measures that catch these failures in testing are compared in agent evaluation metrics.
What the measured fixes changed
MAST's own interventions helped a little. On a simulated software company of role agents, improved prompts raised task accuracy on 32 tasks from 25.0% to 34.4%, and a new topology with a final confirmation step and an iteration cap raised it to 40.6% [1]. The authors judged that "they do not constitute substantial improvements" [1].
Other fixes moved more. Retrieval cut the failure rate of multi-agent discussions from 74.6% to 36.4% on two multi-hop question sets, while growing a team from three agents to seven did not significantly reduce failures [7]. An inspector agent that reviews and corrects messages, used together with a challenger that lets each agent question the others' outputs, recovered 96.4% of the performance that faulty agents had cost one code-generation system [13]. A governance plug-in at the message layer kept final outputs free of infection in 89% to 94% of runs on average, depending on its mode, though one framework fell to 58.3% in one attack setting [12]. An agent-software company wrote in April 2026 that the setups that work have several agents contributing "while writes stay single-threaded" [33].
Each of those three fixes gives agents evidence or checks the messages they pass [7, 12, 13]. Rillor's agentic systems have the same parts in every build: a planner and specialist agents in the orchestrator-worker pattern, with an audit step before any answer, and every step logged so a run can be traced and replayed.
Read the full report
The full report adds all 14 MAST modes with their shares [1], the communication-failure taxonomy, the propagation and attribution studies in detail and where the sources disagree.