The Seven Multi-Agent Failure Modes: A Practical Taxonomy

“The AI made a mistake” is true but not useful. It does not tell you whether to change the prompt, the handoff schema, the tool permission, the data, or the evaluator.

A taxonomy gives a team shared language. It lets you compare incidents, search for patterns, and ask a better first question: where did the workflow stop behaving according to its contract?

The seven categories below are decomposition failure, constraint blindness, coordination breakdown, optimisation failure, hallucinated dependency, information-boundary violation, and temporal misalignment. They overlap sometimes. That is fine. Use the category that points most directly to the next investigation.

A multi-agent workflow usually begins by splitting a large task into smaller tasks. Decomposition failure occurs when that plan is incomplete, contradictory, or impossible to execute. The downstream agents may do their individual jobs correctly and still produce a bad result because the original plan omitted something essential.

Imagine an insurance-claims workflow. The intake agent identifies the claim and routes it to a payout agent, but it never creates a coverage-validation step. The payout agent calculates the amount perfectly. The mistake is not the calculation. The system failed before execution began.

To test for decomposition failure, ask whether every required outcome has an owner, every dependency is explicit, and the order of work makes sense. If a plan says “check eligibility” but does not identify the source or the responsible agent, it is not complete enough to trust.

Constraint blindness means an agent has access to a rule yet behaves as if the rule is not there. This is common when policies live only in a long system prompt. The agent may even quote the policy correctly and then choose the prohibited action.

Suppose a finance agent is told never to approve a payment above a manager’s threshold. The user asks it to “make an exception because the supplier is waiting.” If the agent approves the payment without a recorded approval, the problem is not that the policy was absent. The problem is that nothing enforced it at the point of action.

Convert important rules into explicit checks. Verify the amount, the approver, the role, and the order of events. Treat the policy text as an explanation of the rule, not the rule’s only enforcement mechanism.

Coordination breakdown happens when agents disagree about state, authority, ownership, or what has already happened. Each message may look reasonable in isolation. Together, the messages produce a contradiction.

A diagnosis agent tells a remediation agent that a backup is available. The remediation agent restarts the service. Later, you discover the diagnosis agent inferred the backup from an old note rather than checking the backup system. The agents did not share the same meaning of “available.”

The cure is usually a stronger handoff contract: structured fields, provenance, state versions, and explicit ownership. Test both sides of the handoff. What did Agent A send, and what did Agent B believe it received?

An agent can become very good at a metric that does not represent the real goal. A support system can minimise response time by escalating every request. A route planner can minimise cost by choosing a supplier that misses the delivery deadline. A summariser can maximise brevity by removing the caveat a decision depends on.

This failure is dangerous because the system may look efficient. The remedy is to separate feasibility from optimisation. First determine what must be true for a result to be acceptable. Then compare the acceptable options on cost, speed, length, or another preference.

Write the trade-off into the evaluation. If the weights change, preserve them in the run record so people understand why a score changed.

A hallucinated dependency is an invented document, approval, API result, customer preference, or relationship that later agents treat as real. Multi-agent systems magnify this problem because one confident sentence can be copied into several handoffs.

For example, a procurement agent says, “The vendor has already passed compliance review.” A planner trusts that sentence. A payout agent acts on it. The system now has multiple correct-looking steps built on a fact nobody verified.

Require provenance for consequential claims. Every important value should say where it came from: a tool, a retrieved record, the user, or an inference. In scenarios, remove the source occasionally and see whether the workflow pauses, asks a question, or invents a replacement.

An information-boundary violation occurs when a system sends data to an agent, tool, user, or external service that should not receive it. It includes more than obvious secrets. A customer identifier, internal risk score, restricted document, or hidden policy can be sensitive in context.

A final answer may look clean while the trace reveals that restricted data was sent to an external tool. That is why boundary tests should inspect tool arguments, retrieved context, recipients, and handoffs—not just the last response.

Use field classification and recipient-aware checks. Ask not only “is this data sensitive?” but also “is this actor allowed to receive it for this purpose?”

Many business workflows are order-sensitive. An agent approves before validation, tells a customer that a refund is complete before the transaction commits, or reads memory from an older version of a case.

These failures hide in demos because tools respond instantly and messages arrive in the expected order. Production introduces retries, delays, duplicated callbacks, and stale caches.

Test event order directly. Record timestamps and state versions. Delay a tool response, replay a callback, or deliver two messages out of order. A reliable workflow should wait, reconcile, or refuse rather than quietly continue with an outdated view of reality.

Start with the final symptom, then walk backwards through the trace. Find the first event that made the outcome unavoidable. Do not label every downstream consequence as a separate root cause.

Next, change one thing in a replay. Restore the missing field. Enforce the permission. Delay the tool. Add the approval. If the result changes, you have evidence about the control that matters.

This approach is more productive than rewriting the system prompt after every incident. The smallest successful intervention is often the most durable fix.

Tag every evaluation scenario with its likely failure mode. Over time, look at the distribution. Rising coordination failures may point to architecture or handoff design. Rising constraint failures may point to missing enforcement. Rising temporal failures may point to queues, retries, or state management.

A taxonomy is useful when it changes what you build next. It should help a new engineer understand an incident, help an evaluator choose the right assertion, and help a product team decide whether a failure blocks release.

The objective is not to make agents incapable of surprising you. It is to make important surprises detectable, understandable, and recoverable.