Why multi-agent systems fail

At 3:07 a.m., a support system receives this request:

Refund the customer’s second charge. It was a duplicate.

A manager agent asks a policy agent whether duplicate charges qualify. A ledger agent checks the payment history. A finance agent issues the refund. The final answer says, “Refund completed.”

At 9 a.m., finance discovers that the second charge was not a duplicate. It was the customer’s renewal on a different plan. The policy agent quoted the right rule, but the ledger agent compared the wrong account. The finance agent trusted the word “eligible” and had permission to move money.

Every individual message looked reasonable. The system still made a costly mistake.

That is the distinctive difficulty of a multi-agent system: several language-model agents coordinate through messages, tools, and shared state to complete one task. Coordination can add capability, but it also adds boundaries. At each boundary, context can be dropped, meaning can shift, authority can be misunderstood, and an unverified guess can become someone else’s “fact.”

A stronger model may make each local answer better. It does not automatically repair the organisation around those answers.

The MAST taxonomy: three places it breaks

The Multi-Agent System Failure Taxonomy, or MAST, is the name used by Mert Cemri and co-authors in their empirical paper, Why Do Multi-Agent LLM Systems Fail? A Taxonomy of Failure Modes in Multi-Agent Systems. The authors derived 14 failure modes from 1,600 execution traces across seven multi-agent LLM systems. MAST describes failures observed in that corpus; it is not a claim that every system fails in only these ways.

Its three diagnostic categories are:

1. System Design Issues — the system was set up incorrectly.
2. Inter-Agent Misalignment — agents failed to communicate or coordinate.
3. Task Verification and Termination — the system failed to check its work or stop correctly.

One trace can contain all three. In the refund example, the finance agent had unsafe authority, the ledger result was badly handed off, and no gate checked the account before the side effect. Find the first point where the system’s state stopped representing the task correctly rather than simply asking whether the final model “reasoned badly.”

1. System Design Issues

This failure exists before the first model call. A role such as “payment specialist” is incomplete until its permissions, inputs, outputs, policy version, and tools are explicit. May it inspect transactions, decide eligibility, or call the refund API?

For example:

Duplicate charges are refundable within 30 days.

That is a policy statement, not a decision. A safer contract says:

Return eligible, ineligible, or needs_evidence.
Include the policy version, matching transaction IDs, and the reason.
Never authorise or execute a payment.

Models produce plausible answers to underspecified tasks; they do not reliably notice when two reasonable interpretations lead to different actions. Common design failures include overlapping roles, poor decomposition, missing tool constraints, and local prompts that omit the global objective.

2. Inter-Agent Misalignment

A message is an interface. If the interface is a paragraph of prose, the receiving agent must reconstruct structure from language.

Consider eligible. To the policy agent it might mean “the charge meets the written rule.” To finance it might mean “approved and ready to execute.” Both interpretations are natural; only one is safe. Long transcripts add another risk: summarisation can silently drop the transaction ID or original customer.

A robust hand-off separates the result, evidence, uncertainty, and permitted action:

{
  "task_id": "refund-4821",
  "decision": "needs_evidence",
  "policy_version": "refund-policy-2026-04",
  "matching_transaction_ids": ["txn-91"],
  "amount_cents": 1299,
  "missing": ["account-level payment history"],
  "next_action": "ledger_agent_must_check_account_scope",
  "can_execute": false
}

The receiving agent can now distinguish a conclusion from a partial result or request for evidence.

3. Task Verification and Termination

A system can perform ten competent steps and still fail because nobody checks the final premise. A language-model critic is not automatically a verifier: with the same incomplete evidence, it may produce a more confident version of the same mistake.

For a refund workflow, gates should check that:

• the authenticated customer owns both transaction IDs;
• the transactions match the product and amount;
• the policy version is current;
• the proposed amount equals the approved amount and has not already been executed.

These checks belong in code and database queries where possible. Termination also needs typed states such as executed, rejected, needs_human_review, or failed, plus limits on turns, retries, elapsed time, and spend. “Stop when complete” is not a termination condition.

Why errors cascade

Imagine each agent in a serial workflow succeeds with probability p, and every step must succeed. With n agents, the simple model for end-to-end reliability is p^n.

Here is the arithmetic for agents that are individually correct 95 percent of the time:

# End-to-end reliability of n agents in series, each correct with probability p.
per_agent = 0.95
for n in [1, 3, 5, 10, 20]:
    print(f"{n:>2} agents in series (each 95% reliable): end-to-end = {per_agent**n:.1%}")

 1 agents in series (each 95% reliable): end-to-end = 95.0%
 3 agents in series (each 95% reliable): end-to-end = 85.7%
 5 agents in series (each 95% reliable): end-to-end = 77.4%
10 agents in series (each 95% reliable): end-to-end = 59.9%
20 agents in series (each 95% reliable): end-to-end = 35.8%

Why multiplication? The first agent must be right and the second must be right and the third must be right. Under independence, the probability of all those events is their product.

This is a warning, not a production forecast. Agents are often not independent. If they all see the same stale policy document, they can share one mistake. That is a correlated error: components fail together because they depend on the same input, prompt, model tendency, or tool result. Three agents researching the same pages are not three independent experts; consensus can simply amplify a shared error. This is the conformity failure discussed in multi-agent debate.

Serial agents also add time and cost. Five sequential calls taking 1.2 seconds each need about 6 seconds before network delays, retries, and queueing. Parallelism can reduce wall-clock time, but not the calls or their failure surfaces.

What actually reduces the failures

The fixes are mostly software engineering applied to components that speak natural language.

Make the hand-off a contract

A contract explicitly defines the shape and meaning of data crossing a boundary. It should identify the task, state the result, cite evidence, represent uncertainty, and specify the next permitted action.

Use a small structured object rather than a transcript. Validate it before the next agent sees it, reject missing fields instead of guessing, and include a schema version. Do not treat a model’s confidence: 0.92 as proof unless it is calibrated; evidence references and a needs_evidence state are safer.

Separate decisions from side effects

An agent that recommends a refund should not automatically execute it:

research complete
    -> decision proposed
    -> policy and identity checks passed
    -> approval recorded
    -> payment executed
    -> execution verified

These are state transitions, not suggestions in a prompt. The payment tool should refuse calls unless approval and evidence exist in durable state. This is least privilege: a research agent with refund permissions is not more capable, only more dangerous.

Verify before acting, then bound execution

Put deterministic gates before irreversible actions and after important transformations. Verify the ledger output before granting execution authority, check the amount immediately before the API call, and query the payment system after execution. “The API returned 200” is not always “the refund settled.”

Verification may be deterministic, independent, or human. A verifier must be able to return a failure state; if it can only say “looks good,” it is decoration.

Set maximum turns and retries, a deadline, and an idempotency key: a stable request identifier that lets a tool recognise a repeated request. Persist intermediate state and record why the workflow stopped.

If a timeout may have reached the provider, the outcome is unknown. Reconcile with a status lookup using the idempotency key before retrying; do not return success or issue a second refund. Use outcome_unknown, needs_reconciliation, or needs_human_review as appropriate. Retry only errors known to be retryable.

When fewer agents win

Choose the topology with the fewest unsafe boundaries:

• Use one agent with tools for one goal and a few tools in shared context.
• Use ordinary code or a workflow for a fixed sequence with deterministic rules.
• Use parallel specialists for genuinely independent research with a clear merge rule.
• Use narrow agents behind typed contracts when different tools, expertise, or permissions provide isolation.

Use multiple agents only when the separation buys independent evidence, parallel work, isolated context, different tools, or a meaningful permission boundary. Dense shared-context work often gets worse as each summary creates another chance to lose the plot.

A production debugging order

When a run fails:

1. Reproduce the exact run. Save model versions, prompts, tool responses, policy versions, and relevant random settings.
2. Find the first invalid state. Look for the first missing evidence, changed identifier, schema violation, or false claim of completed work.
3. Classify it with MAST. Was the design wrong, did the hand-off misalign agents, or did verification or termination fail?
4. Add the narrowest guard. Fix the contract, permission, deterministic check, or terminal-state rule that would have stopped it.
5. Add the case to an end-to-end evaluation set. Confirm the original case passes without regressing nearby cases.

Log each invocation, contract, tool call, state transition, retry, verification result, and termination reason. A final transcript cannot answer which component first introduced the wrong transaction ID. End-to-end tracing is the job of agent observability, while workflow-level success belongs in agent evaluation.

Quick check

Next

The conformity problem is examined in multi-agent debate. For choosing a topology, read multi-agent orchestration. For measuring whether the complete system works, see evaluating agents.