Why Multi-Agent Systems Fail: How Errors Compound at Every Hand-Off

Adding an agent to a system adds a hand-off. Every hand-off turns one agent's output into another agent's premise, usually with nothing checking it in between.

That is the quiet cost of multi-agent design. A single agent that makes a mistake produces one wrong answer. A pipeline of agents can take that mistake, build on it, and deliver something confidently wrong several steps later, with the original error buried in a trace nobody reads.

What research says about why multi-agent LLM systems fail

A useful map of the problem is Cemri et al., "Why Do Multi-Agent LLM Systems Fail?", from a team based mainly at UC Berkeley and published in the NeurIPS 2025 Datasets and Benchmarks track. The authors built a failure taxonomy, MAST, from close analysis of 150 traces, then used it to label 1,642 execution traces from seven open-source multi-agent frameworks. On their benchmarks, the systems they ran failed between 41% and 86.7% of the time.

MAST has fourteen failure modes in three categories:

The authors' central finding is that many failures come from how the system is organised, not only from the limits of the underlying model. They conjecture that better base models alone will not close the gap, and compare it to human organisations: capable people can still fail together if the structure around them is wrong.

How errors compound across agents

Unverified intermediate outputs become facts

Suppose each agent in a five-step pipeline gets its part right 95% of the time, and the errors are independent. The chance that all five are right is about 77%. Real pipelines can do worse than that arithmetic, because a downstream agent does not just inherit a wrong premise. It elaborates on it.

The paper found that the checks meant to catch this were often shallow. Many verifiers, even when prompted to be thorough, performed only superficial checks, such as whether code compiled or whether TODO comments were left behind. One ChatDev-generated chess program passed those checks and still contained runtime bugs, because nothing checked it against the actual rules of the game. Adding a step that verified the high-level task objective improved ChatDev's task success by 15.6% in the authors' case study.

Information is lost at the hand-off

In one trace the paper illustrates, a phone agent knew its login API expected a phone number as the username and did not pass that on. The supervisor agent never asked. The result was repeated failed logins and a failed task: information withholding on one side, a failure to ask for clarification on the other.

Standard protocols help with format, not content. The authors note that protocols such as MCP and A2A standardise message formats, yet the misalignment failures they observed happened even between agents in the same framework talking in plain language.

Roles blur

A role defined only in a prompt is a suggestion. In ChatDev, the paper describes a chief product officer agent that can end the conversation without the chief executive agent's agreement. A workflow change that gave the CEO agent the final say contributed to a 9.4% increase in task success.

Role confusion also has a security edge. Suppose a research agent reads a poisoned web page and passes a summary to an agent that can send email. The injected instruction now arrives from a colleague. OWASP's entry on prompt injection (LLM01:2025) covers instructions hidden in external content the model takes in, and its entry on excessive agency (LLM06:2025) names "a malicious/compromised peer agent" among the triggers in multi-agent systems. Another agent's output is external content too.

Nobody owns "finished"

Agents that do not recognise when to stop, and agents that stop before the objective is met, both appear in MAST. They are two symptoms of one gap: no component with the authority to decide when the job is done.

How to stop errors compounding at the hand-off

The hand-off is the natural place for controls, because it is the one point where an agent's output can be inspected before it becomes another agent's input.

1. Make the hand-off a contract. Define what every hand-off must carry: the task, the constraints, the evidence behind each claim, the assumptions made and the open questions. Reject a hand-off with a missing field rather than letting the next agent guess. This targets information withholding and lost history directly.

2. Verify before you forward. Check intermediate outputs at the hand-off, not only the final answer, and check at more than one level: low-level correctness, and whether the output still serves the original objective. The checker should be independent of the agent that produced the work, because a trace shows what happened, not whether it should have.

3. Treat upstream output as evidence, never as instructions. Content from another agent carries no authority of its own. Enforce each role's limits outside the prompt, through tool scopes and per-call authorisation, so that a confused or hijacked agent cannot act outside its role.

4. Give every agent a way to say "I don't know". An agent that cannot ask for clarification will proceed on a guess. The paper's authors suggest agents act only when their confidence clears a threshold, and pause to gather information when it does not. Build that third state into the protocol, and make the orchestrator handle it.

5. Let the orchestrator own termination. Define done criteria per task, set step limits, and do not let any single agent declare the whole job finished. A subagent finishing its part is not the system finishing the task.

What to record at each hand-off

For every hand-off, record the sender, the receiver, the payload, which checks ran and what they returned. When a pipeline produces a bad result, that record lets you find the first hand-off where it went wrong, instead of blaming the agent that happened to speak last. MAST's fourteen modes give the team a shared vocabulary for labelling what it finds, and for spotting which ones keep recurring.

Where Syntrox fits

Syntrox sits outside the agents, which is where a check on their work has to sit to be independent of them. Nucleus evaluates an output against a domain rubric and returns pass, fail or uncertain, with a reason that quotes the fragment that drove the verdict. It returns uncertain rather than guessing when a grounded check has no context to check against, and it treats any instruction inside the material it evaluates as evidence, never as a command.