How do you attribute one failed multi-agent run to the specific agent that caused it?

## Why attribution is the hard part An end-to-end failure in a multi-agent system yields one bit: the task did not succeed. That bit does not name an owner, a mitigation, or a next action. Attribution — deciding which agent's behaviour caused this particular failure — is what converts a pile of failed runs into a ranked work list. It is also genuinely hard: the observable symptom is usually far downstream of the cause, several agents have touched the state in between, and the run is not reproducible by re-executing it. ## Step one: define the failure crisply Before attributing anything, write down what "failed" means for this task in checkable terms: the wrong applicant was rejected, the summary contradicted the source, the pipeline terminated without an answer, the run exceeded budget. Vague failure definitions produce vague attribution and make aggregation across runs meaningless. If a run fails several ways at once, attribute each failure separately rather than picking one. ## Step two: find the first divergence, not the last error Walk the trace from the start and compare each step's output against what a correct run would have held at that point — either from a reference run, from ground-truth labels on the task, or from a human reading the artifact. The first step whose output is already wrong is the primary suspect. This matters because the loudest signal is almost always the last one: an agent that crashes on a malformed input, or a final summariser that produces a confidently wrong answer, is frequently an innocent consumer of an artifact that went wrong three handoffs earlier. Blaming the last error produces a mitigation (better error handling in the summariser) that leaves the actual defect untouched. In practice the first divergence is often not a wrong fact at all but a **misalignment**: two agents holding different interpretations of what the task is, or a handoff payload that is well-formed but carries less than the receiving agent assumed. Those show up in the trace as an output that looks locally plausible and only becomes wrong in light of the receiver's expectations. ## Step three: separate producing from failing to catch Every failing run has at least a producer and, if the design includes any verification, one or more agents that had a chance to stop it. These are different defects with different fixes. If the reviewer agent approved a wrong artifact, the reviewer is not innocent — its rubric, its context, or its incentive to agree is the defect, and improving the producer alone will not raise the system's reliability. Record both: primary attribution (who produced the divergence) and secondary (who should have caught it). ## Step four: classify against a taxonomy One-off narratives do not aggregate. Score each failing run against a shared taxonomy so you can count and rank. MAST is the reference taxonomy for multi-agent failures: fourteen modes in three clusters — specification and system-design problems, inter-agent misalignment, and verification failures — with published distributions putting roughly 42%, 37% and 21% of observed failures in those clusters respectively. The exact percentages matter less than the shape of the finding: most multi-agent failures are not "the model was dumb", they are design and communication defects that a better prompt on one agent will not fix. ## Step five: confirm with counterfactual replay Attribution from reading a trace is a hypothesis. Test it: pin the recorded trace, replace the suspect step's output with a corrected one, and re-execute everything downstream. If the run now succeeds, the attribution holds. If it still fails, the real cause is elsewhere or there are two independent defects. This is the closest thing to a controlled experiment available in a nondeterministic system, and it is cheap because upstream steps are replayed from the record rather than re-executed. ## Automating it, and its limits Attribution can be automated with a judge model reading the trace, and there are dedicated benchmarks for exactly this task — Who&When, AgenTracer, MP-Bench and TraceElephant among them. Be honest about the current state: even with full traces available, step-level attribution accuracy for automated attributors remains around 30%. That is well above chance on a long trace and useful for triage and for ranking, but not reliable enough to close a bug on its own. The practical posture in 2026 is to use an automated attributor to cluster and prioritise, and to have a human adjudicate a sample — typically the highest-frequency clusters — before committing engineering effort. ## What you do with the result Aggregate attributions across a batch of failing runs — forty is enough to see structure — and act on the mode, not the anecdote. A cluster of inter-agent misalignment failures points at the handoff contract and the task specification, not at any single agent's prompt. A cluster of verification failures points at giving the reviewer a clean, independent context rather than the producer's own reasoning. A cluster of specification failures usually means the orchestrator's decomposition is wrong and no amount of per-agent tuning will help.