Multi-Agent Systems Fail in the Handoffs, Not the Agents

Every agent passes; the system fails

The intuition behind multi-agent systems is sound: decompose a hard task into roles, a researcher, a planner, a coder, a critic, and let specialists collaborate. The intuition behind testing them is where teams go wrong. They unit-test each agent, confirm each does its job well in isolation, and assume a system of good agents is a good system. It isn’t. The errors don’t live in the agents; they live in the seams between them.

This isn’t a hunch, it’s the central finding of the first empirically-grounded taxonomy of multi-agent failures, a UC Berkeley Sky Computing Lab project published as a NeurIPS 2025 spotlight. The MAST study analyzed 1,600+ annotated execution traces across seven popular multi-agent frameworks (with inter-annotator agreement of Cohen’s Kappa 0.88) and identified 14 distinct failure modes in three categories, with a striking distribution: roughly 41.8% are specification and system-design failures (disobeying role specs, step repetition, losing conversation history), 36.9% are inter-agent misalignment (the communication failures), and 21.3% are task verification and termination problems (Why Do Multi-Agent LLM Systems Fail?, 2025). Only a sliver of failures are the individual agent simply being incapable.

The handoff failure modes you have to test for

The MAST inter-agent-misalignment category reads like a checklist of exactly what to evaluate, because each mode is a specific, reproducible way a handoff goes wrong:

• Ignored input, an agent receives output from another and proceeds as if it didn’t, discarding the handoff entirely.
• Information withholding, an agent has a fact a downstream agent needs but doesn’t pass it, so the next agent works blind.
• Failure to ask for clarification, an agent receives ambiguous input and guesses instead of querying back, baking in an error.
• Reasoning-action mismatch, the agent says one thing in its reasoning and hands off something inconsistent.
• Derailment, the conversation between agents drifts off the task and never recovers.

And in the verification category, premature termination and incomplete or incorrect verification, the system declaring success before the task is actually done, or accepting a flawed result because no agent properly checked it.

Why errors compound across handoffs

The math of multi-stage systems is unforgiving. If each handoff preserves correctness with probability p, then a chain of n handoffs preserves it with roughly pⁿ. At a per-handoff fidelity of 90%, which sounds healthy, a five-stage pipeline lands at 0.9⁵ ≈ 59%. Each agent is “90% good” and the system is a coin flip. Worse, errors don’t just drop information; they propagate and amplify, a small misunderstanding at the planning stage becomes a wrong assumption the coder builds on, which the critic then validates against the wrong spec. By the time the system terminates, the original error is woven through everything.

Evaluate the system, and evaluate the seams

The fix is to make handoffs first-class eval targets. Capture the full multi-agent trace and assert properties on the messages between agents, not just the final output. The MAST authors themselves built an LLM-as-judge pipeline to scale exactly this kind of trace analysis.

# Evaluate the handoffs, not just the final answer
def eval_handoffs(trace, expected):
    issues = []
    for h in trace.handoffs:                      # each message agent_i -> agent_j
        # Ignored input: did the receiver actually use what it was given?
        if not references(h.receiver_action, h.payload):
            issues.append(('ignored_input', h.sender, h.receiver))
        # Information withholding: did the sender drop a fact it held and j needs?
        missing = required_facts(h.receiver) - facts_in(h.payload)
        if missing & facts_known_to(h.sender):
            issues.append(('withheld_info', h.sender, list(missing)))
        # Clarification: ambiguous payload that was acted on instead of queried
        if is_ambiguous(h.payload) and not h.receiver_asked_clarification:
            issues.append(('no_clarification', h.receiver))

    # Termination: did the system stop before the task was actually complete?
    if trace.terminated and not task_complete(trace.final, expected):
        issues.append(('premature_termination', trace.last_agent))
    return issues

# Gate on system-level correctness AND handoff health
def multi_agent_gate(system, eval_set):
    sys_correct, handoff_fail = [], Counter()
    for case in eval_set:
        trace = system.run(case.input)
        sys_correct.append(task_complete(trace.final, case.expected))
        for kind, *_ in eval_handoffs(trace, case.expected):
            handoff_fail[kind] += 1

    system_accuracy = sum(sys_correct) / len(sys_correct)
    assert system_accuracy >= 0.85, (
        f"system accuracy {system_accuracy:.1%}; "
        f"top handoff failures: {handoff_fail.most_common(3)}"
    )
    return {'system_accuracy': system_accuracy, 'handoffs': dict(handoff_fail)}

Design for fewer, cleaner handoffs

The eval tells you where the seams fail; the design fixes reduce how much can go wrong at each seam. Because 41.8% of failures are specification and design, the highest-leverage interventions are structural: give agents explicit, unambiguous role and output specifications so they can’t silently disobey; pass structured handoff payloads (typed objects, not free-form prose) so information can’t be quietly dropped or misread; require explicit verification before termination so the system can’t declare premature success; and resist the urge to add agents, every additional handoff multiplies the error chain. Often a two-agent system with clean contracts beats a five-agent system with sloppy ones.

The honest question: do you need multiple agents at all?

The MAST data carries an uncomfortable implication that the field is slowly absorbing: the performance gains of multi-agent systems on popular benchmarks are often minimal compared to a well-built single agent, while the failure surface is dramatically larger. Every handoff you add is a place for the 14 failure modes to manifest, and the compounding math means each addition has a multiplicative cost to reliability. The instinct to decompose a task into a committee of specialists feels sophisticated, but it frequently buys you coordination overhead and error propagation in exchange for capability you could have gotten from one agent with good tools and a clear prompt.

This doesn’t mean multi-agent architectures are wrong, some tasks genuinely require parallel specialists or independent verification. It means the decision to go multi-agent should be earned, not assumed, and it should come with the eval infrastructure to manage the seams from day one. Before adding the fifth agent, ask whether a single agent with the fifth agent’s tools would do the job with one fewer handoff to break. Often the answer is yes, and the simpler system is the more reliable one precisely because it has fewer seams to fail in.

The bottom line

Multi-agent systems fail in the handoffs, not the agents, the MAST taxonomy puts 36.9% of failures in inter-agent communication and another 41.8% in specification and design, with only a fraction attributable to an agent simply being incapable. Errors compound geometrically across handoffs, so a system of “90% good” agents can be a coin flip. Unit-testing agents in isolation is blind to all of this. Capture the full trace, evaluate the messages between agents for ignored input, withheld information, missed clarification, and premature termination, and gate on system-level correctness. Then design for fewer, cleaner, structured handoffs. The agents were never the problem. The seams were.