Evaluating Multi-Agent Systems: Failures, Handoffs, and Attribution

Individually competent agents can still fail as a system. A practical way to evaluate routers, specialists, handoffs, and orchestration, grounded in recent failure research.

By Vaibhav Khamesra · October 31, 2026 · 7 min read

Why multi-agent evaluation is its own problem

A multi-agent system splits work across several LLM-driven agents: a router that classifies intent, specialists that handle billing or search, an orchestrator that delegates, and often a human team as the final fallback. Each agent can be individually competent while the system as a whole fails.

Anthropic's write-up of its multi-agent Research feature is unusually candid about this. Early versions spawned 50 subagents for simple queries, searched endlessly for sources that did not exist, and distracted each other with excessive updates. Small changes to the lead agent changed subagent behaviour in ways that were hard to predict. Their conclusion: success requires understanding interaction patterns, not just individual agent behaviour.

Cost behaves differently too. In Anthropic's data, agents typically used about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. Their multi-agent configuration, with Claude Opus 4 leading Claude Sonnet 4 subagents, outperformed single-agent Claude Opus 4 by 90.2% on an internal research eval. On the BrowseComp benchmark, token usage alone explained 80% of performance variance. Part of the multi-agent gain is simply spending more compute, which is why a budget-matched baseline matters.

How multi-agent systems fail

The most useful starting point is MAST, the Multi-Agent System Failure Taxonomy from Cemri and colleagues at UC Berkeley. They built it from expert analysis of 150 traces with high inter-annotator agreement (Cohen's kappa of 0.88), then applied it to MAST-Data, a dataset of over 1,600 annotated traces across seven popular multi-agent frameworks. The taxonomy identifies 14 failure modes in three categories:

The authors also built an LLM-as-a-judge annotator that agrees closely with human labels, which makes the taxonomy usable at scale. In practice, tag every failed trace with a MAST category during review. After a few dozen traces, the distribution tells you whether to fix prompts, the handoff protocol, or the verification step.

Which agent broke it, and when?

When a multi-agent run fails, the obvious question is which agent caused it. Zhang and colleagues studied this as "automated failure attribution" and released the Who&When dataset: failure logs from 127 multi-agent systems, annotated with the responsible agent and the decisive error step. The best automated method identified the responsible agent 53.5% of the time but the decisive step only 14.2% of the time. Some methods did worse than random, and even reasoning models such as OpenAI o1 and DeepSeek R1 did not reach practical usability.

The lesson is not to wait for a better blame model. Design the system so attribution is cheap:

• Typed handoffs. Every message between agents follows a schema: objective, inputs, constraints, expected output format, and a reason for the handoff. Schema violations fail in code, immediately.
• Explicit state. Keep conversation state, customer context, and task status in a store that every agent reads and writes through defined operations, rather than only in prompts.
• Trace everything. Record each agent invocation, tool call, and handoff as a span with its parent. The OpenTelemetry GenAI semantic conventions define spans for model calls, agents, and tool execution, so traces stay portable across tools.
• Checkpoints. For long tasks, define the state that should exist after each phase and check it. Anthropic recommends discrete checkpoints over validating every intermediate step.

Evaluate at four levels

1. Each agent on its own

Test every agent in isolation with fixed inputs, exactly like a unit. A router is a classifier: build a labelled set of messages and report a confusion matrix, not just accuracy, because some confusions are far more expensive than others. Sending a refund request to the FAQ agent is worse than sending an FAQ question to the refund agent. Specialist agents get task-specific evals: correct tool, correct arguments, correct outcome.

Bounded classifications like these are a good fit for System One judges, which return a probability for each label and can be run on every trace cheaply. The article on judging agents covers that in detail.

2. Each handoff

Handoffs are where MAST's inter-agent failures live. For each handoff type, check:

• Completeness: does the receiving agent get everything it needs? Anthropic found that vague delegation such as "research the semiconductor shortage" led subagents to duplicate each other's work. Their fix was to give every subagent an objective, an output format, guidance on tools and sources, and clear task boundaries.
• Fidelity: is information lost or distorted when passed along? Anthropic calls this the "game of telephone" and reduced it by having subagents write artifacts to external storage and pass lightweight references.
• Human handoffs: did the system escalate when it should, and only when it should? Build balanced test sets with both cases. Anthropic's advice on avoiding one-sided evals applies directly: if you only test that escalation happens, you will optimise towards an agent that escalates everything.

3. The orchestration

These are process metrics, read from traces rather than graded as pass or fail:

• Number of agents and tool calls per task, compared against the effort the task deserves. Anthropic encoded effort rules in its prompts: one agent with 3 to 10 tool calls for simple fact-finding, 2 to 4 subagents for comparisons, more than 10 for complex research.
• Duplicated work across agents, loops, and repeated steps.
• Termination: did the system stop when the task was done, and not before?
• Tokens, latency, and cost per task.

4. The end-to-end outcome

Grade the final state, not the conversation. For a support system: is the ticket resolved, the refund processed, the customer record updated, and was the reply grounded in the tool results? Agents can reach the right outcome by different valid paths, so avoid asserting an exact sequence of agents and tools unless a policy requires it, such as identity verification before a refund.

Run each task several times. Multi-agent systems are more non-deterministic than single agents, and customer-facing systems need consistency. The pass^k metric from τ-bench, the probability that all k trials succeed, captures this. The article on testing agents explains how to use it.

Always keep a single-agent baseline

Cemri and colleagues open their paper by noting that multi-agent performance gains on popular benchmarks are often minimal. Before adding agents, run the same evaluation suite against a strong single agent with the same tools and a comparable token budget. Keep the multi-agent design if it wins on outcomes per unit of cost, or on something the single agent cannot do at all, such as exceeding one context window or working in parallel.

A starter scorecard