Companion code: 08-failure-injection

TL;DR

• The MAST study analysed more than 1,600 traces from seven multi-agent frameworks and sorted their failures into 14 modes in three categories: system design, inter-agent misalignment, and verification.
• Most failures are organizational, not intellectual: vague specifications, lossy hand-offs, no stopping rule, superficial checking. Changing the design, with the same model, measurably improved success rates.
• We tried to reproduce three of them against a current model. Two crude versions mostly didn’t happen, because the model compensated, and one turned into a different failure. The fixes (acceptance criteria, structured hand-offs, verifiers that recompute from the source) passed every run: guarantees, not averages.

From “should we?” to “why did it break?”

Post #7 asked when several agents beat one. This post asks the follow-up every team eventually faces: when a multi-agent system gives a wrong answer, what actually went wrong?

Until 2025 the honest answer was usually anecdote. Early surveys such as LLM Multi-Agent Systems: Challenges and Open Problems (Han et al., 2024) listed the open issues (task allocation, coordination, memory), but there was little systematic data on how real systems actually fail.

Then came Why Do Multi-Agent LLM Systems Fail? (Cemri, Pan, Yang et al.). The authors collected execution traces from seven popular multi-agent frameworks, had experts annotate where and why each run went wrong, and checked their categories for consistency. Annotator agreement reached a Cohen’s kappa of 0.88, which is high for this kind of judgement. The result is MAST, the Multi-Agent System failure Taxonomy, along with a dataset of more than 1,600 annotated traces and an LLM-based pipeline that labels new traces automatically.

The taxonomy

System design issues come from how the system was set up: the task and role specifications, and the rules for when to stop. Agents ignore constraints they were given (1.1), drift out of their role (1.2), repeat finished steps (1.3), lose track of the conversation (1.4), or don’t know when the job is done (1.5).

Inter-agent misalignment is agents talking past each other. They restart conversations (2.1), don’t ask when something is unclear (2.2), drift off the task (2.3), fail to pass on information another agent needs (2.4), ignore another agent’s input (2.5), or say one thing and do another (2.6). The paper’s illustration of information withholding is painfully ordinary: a phone-service agent knows the required username format, never tells the supervisor agent, and the supervisor never asks.

Task verification is about checking the result, or not checking it. Runs stop before the work is done (3.1), nobody checks the output, or the check is incomplete (3.2), or the check itself is wrong (3.3). The paper notes that verifiers often stopped at shallow checks, such as confirming that generated code compiles, rather than testing it against what was actually asked.

Not every failure is equally serious. The authors observed that some modes, notably being unaware of termination conditions and information withholding, appeared almost only in runs that failed outright. When they happen, they usually sink the task. Others show up in successful runs too, and are closer to inefficiency than catastrophe.

It’s mostly not the model

The most useful finding for practitioners is in the paper’s intervention studies. Using the same underlying model, the authors changed only the system design of ChatDev, a multi-agent software-development framework:

• Clarifying roles and the workflow (making sure one agent, the “CEO”, had the final say) raised the task success rate by 9.4%.
• Adding a verification step against the high-level objective (checking that the output actually does what was requested, not just that it runs) raised it by 15.6%.

Neither fix needed a better model. The authors’ conclusion is that improvements to base models alone won’t remove these failures. Reliability comes from organization: who decides, what gets passed on, and who checks.

Three failures, attempted

The companion code (08-failure-injection) tries to reproduce one failure from each category in a minimal two-agent setup, with a broken and a fixed variant graded by plain code. We ran every variant six times against Claude Opus 5.5. The results were not what the scenarios were designed to show, and they’re more useful for it.

Scenario	Broken variant failed	Fixed variant failed
1. Vague reviewer	3 of 6	0 of 6
2. One-line hand-off	0 of 6	0 of 6
3. Answer-only verifier	1 of 6	0 of 6

1. The vague reviewer

A writer drafts a 40-word product blurb, and a reviewer checks it. In the broken version, the reviewer is asked to suggest improvements, with no criteria for “done”:

review = ask(f"Review this blurb and suggest improvements:

{text}", schema=Review)

We designed this to produce FM-1.5, unaware of termination: a reviewer that always finds something to improve, so the loop runs until the round limit. That never happened. The reviewer always approved within three rounds. What happened instead, in half the runs, was worse. The vague “make it stronger” feedback led the writer to produce rewrites of 164 to 176 words, the blurb plus its own notes, against a 40-word specification, and the reviewer approved them anyway. One approval even said “The word count (39) checks out”: it counted the blurb and ignored everything around it. That’s two other MAST modes at once: FM-1.1, disobey task specification, and FM-3.3, incorrect verification.

The fix is the same either way: give the reviewer acceptance criteria and a duty to approve once, and only once, they’re met:

review = ask(f"Acceptance criteria:
{criteria}

Blurb:
{text}

Approve if and only if every "
             "criterion is met. Do not ask for stylistic changes beyond the criteria.", schema=Review)

With criteria, it passed six runs out of six. A round limit is still worth keeping as a backstop, but on its own it only stops a loop. It doesn’t make the result good. This is the same lesson as the evaluator-optimizer pattern in post #2: a judge needs a rubric.

2. The one-line hand-off

A lead agent receives a request containing an easy-to-miss rule: the username must be the email address in lowercase. It delegates to a worker that owns the create_account tool. In the broken version, the hand-off is a terse one-line brief, a common “keep briefs short” convention. We expected the rule to be compressed away, as in the paper’s example of FM-2.4, information withholding.

It wasn’t, in any of six runs. The lead kept the constraint by applying it itself, inside the brief:

hand-off: 'Create account for Ana Costa; username and email: ana.costa@example.org'

That’s a capable model compensating for a weak design, and it’s worth being honest about: with today’s frontier models, this crude version of the failure is rare. The structured hand-off (a constraints field plus the original request verbatim) is still the better design, but its value here is as a guarantee, not a fix for a failure we could observe. A weaker or cheaper model in the lead role (post #16), a subtler constraint, or a longer chain of hand-offs would all erode that safety margin. You don’t want a correctness rule that depends on one model call happening to notice it.

class FullBrief(BaseModel):
    task: str
    constraints: list[str]
    original_request: str

3. The check that didn’t check

Here the worker is injected: plain code that sums twelve invoices but silently skips one. Deliberately injecting a known fault is the only reliable way to test a checker, because you can’t wait for a model to make a mistake on cue. The broken verifier sees only the answer and judges whether it looks right:

v = ask(f"Check this answer before it is sent to the user. Is it clear, well-formatted and plausible?

"
        f"{work['answer']}", schema=Verdict)

In five of six runs, the model did something sensible we hadn’t asked for: it refused to approve a total it couldn’t confirm. In the sixth, it approved the wrong number because it was clear and well-formatted. One in six is the kind of failure rate that never shows up in a demo and always shows up in production.

The fixed verifier gets the source data and has to recompute the total independently. It caught the fault in all six runs. Better still, and suggested as an experiment in the README: when a check can be done in code, such as re-summing twelve numbers, do it in code. Model verifiers are for what code can’t check.

What the runs teach

Current models often paper over weak designs: they apply constraints nobody passed on, and refuse to approve what they can’t check. That’s real progress, and it’s also the trap. A design that works only when the model happens to do the right thing will pass your demo and fail in production, at one run in two, or one in six, or one in a thousand. The fixed variants didn’t fail once in eighteen runs. That’s the difference between relying on a model’s judgment and relying on the system’s structure.

A design review checklist

MAST works well as a checklist before you ship, and as a labelling scheme for failed traces afterwards.

System design

• Does every agent have a written task specification with explicit acceptance criteria?
• Is there a stopping rule that a model judges against criteria, plus a hard limit as a backstop?
• Are roles distinct, and does one agent have the final say?

Inter-agent communication

• Do hand-offs have a structure with room for constraints, rather than a free-text summary?
• Can an agent ask for clarification, and does anything ever answer it?
• Does the receiving agent get the original request, or only someone’s paraphrase of it?

Verification

• Does the checker see the source or only the answer?
• Is anything that can be checked in code (counts, sums, formats, tests) actually checked in code?
• Is the result checked against the original objective, not just against “it runs”?

When something does fail, label the trace with a MAST mode before fixing it. A dozen labelled failures usually show a pattern, and the pattern tells you which part of the design to change.

Trade-offs

• Structure costs tokens. Full hand-offs and recomputing verifiers make every step bigger. That’s the right trade where an error is expensive, and overkill for a throwaway draft.
• Verifiers can be wrong too. “Incorrect verification” is itself one of the 14 modes. Prefer checks in code, and when you must use a model as a checker, give it the evidence, not just the claim.
• Taxonomies age. MAST was built from 2024–25 frameworks and models. The categories (specification, communication, verification) are likely to outlast the individual percentages.

Next in the series: Memory that learns: from CLIN to ReasoningBank.

Sources & further reading

• Cemri, Pan, Yang et al., Why Do Multi-Agent LLM Systems Fail? (2025): the MAST taxonomy, dataset and intervention studies.
• Han et al., LLM Multi-Agent Systems: Challenges and Open Problems (2024).
• Walden Yan (Cognition), Don’t Build Multi-Agents (Jun 2025): the “share context” principle.
• Anthropic, How we built our multi-agent research system (Jun 2025): delegation and evaluation in practice.

#multi-agent #reliability #evals