Pillar guide · Failure analysis

The Seven Multi-Agent Failure Modes: A Practical Taxonomy

/Truvyx Engineering/16 min read

Multi-agent AI failures rarely look like one model making one obvious mistake. They emerge at the seams: a planner misunderstands the objective, a specialist receives incomplete context, a tool changes state too early, or a verifier approves a result it cannot actually prove.

A useful taxonomy turns vague incidents into searchable engineering objects. The seven failure modes below help teams classify what happened, identify the earliest invalid event, and choose a remedy that is narrower than “rewrite the prompt.”

1. Decomposition failure: the plan is wrong before execution begins

A planner decomposes a task into steps that are incomplete, contradictory, or impossible to execute. The downstream agents may perform their assignments perfectly and still produce a bad result because the plan omitted a dependency.

Test decomposition with coverage assertions: does every required outcome have an owner, is every dependency explicit, and can the plan be executed in the stated order? A plan that says “check eligibility” without naming the data source is not a complete plan.

2. Constraint blindness: rules exist but do not shape behaviour

Constraint blindness occurs when an agent has access to a rule yet acts as though the rule is absent. Prompt reminders are especially fragile here: the model can repeat the policy in prose and then select a prohibited action.

Represent high-severity constraints as explicit assertions and evaluate them independently. A rule such as “never disclose a patient identifier to a scheduling vendor” should be checked against the actual data flow, not inferred from the final explanation.

3. Coordination breakdown: locally sensible agents produce a globally bad result

Coordination failures happen when agents disagree about state, authority, ownership, or timing. Each agent’s output can look reasonable in isolation while the composed workflow contradicts itself.

Contract tests, shared state versions, and handoff-specific scenarios expose this class. Record what Agent B believed Agent A had completed; that comparison often reveals the missing message or stale assumption.

4. Optimization failure: the system pursues the wrong objective

An agent can satisfy a visible target while damaging the real objective. A support workflow may minimize response time by escalating every case. A supply-chain planner may minimize cost by selecting a vendor that misses the delivery window.

Make trade-offs measurable. Score feasibility first, then completeness and optimality, and preserve the objective weights in the evaluation record. If priorities change, the score should explain why rather than silently shifting.

5. Hallucinated dependency: invented facts enter the workflow

A hallucinated dependency is an invented document, approval, API result, customer preference, or relationship that later agents treat as real. Multi-agent systems amplify the problem because one confident invention can become several agents’ shared context.

Require provenance for consequential claims. A handoff should identify whether a value came from a tool, a retrieved source, a user, or an inference. Evaluate what happens when the source is missing; the correct behaviour may be to ask, pause, or escalate.

6. Information-boundary violation: the system crosses a permission line

Information-boundary failures include sending restricted fields to the wrong role, using data outside its permitted purpose, and exposing internal reasoning or credentials through a tool call. These failures can occur even when the final answer contains no obvious secret.

Test boundaries as trajectories. Log access decisions, tool arguments, and recipient identity, then assert that sensitive fields are redacted or blocked before transmission. This is stronger than scanning the final response alone.

7. Temporal misalignment: the right action happens at the wrong time

Many workflows are order-sensitive. An agent may approve before validation, notify a customer before a transaction commits, or read memory from a previous version of the case. The result can be logically plausible but operationally invalid.

Use event-time assertions and versioned state. Test retries, delayed tools, duplicated messages, and out-of-order callbacks. Temporal bugs often hide in happy-path tests because everything returns instantly.

How to use the taxonomy during an incident

Start with the earliest event that made the final outcome inevitable. Classify that event, then list downstream symptoms separately. This prevents teams from labeling every consequence as a new root cause.

Next, design one discriminating replay. Change one variable—restore a missing field, delay a tool, enforce a constraint, or swap the handoff schema—and observe whether the fault disappears. The smallest successful replay tells you where the control belongs.

From taxonomy to reliability practice

A taxonomy matters only when it changes how systems are tested. Tag scenarios by failure mode, report trends across model releases, and assign a remediation owner. Over time, the distribution of failures becomes a quality signal: rising coordination faults may point to architecture, while rising constraint blindness may point to missing verification.

The goal is not to eliminate every surprising model output. It is to make important surprises detectable, attributable, and recoverable before they become production incidents.

Related evaluation guides