Failure taxonomy

Multi-Agent Failure Patterns: A Taxonomy of Coordination Breakdowns

/Truvyx Engineering/15 min read

Multi-agent systems fail at boundaries that do not exist in a single prompt. Work is divided, context moves between roles, tools change shared state, and decisions arrive at different times. A useful fault taxonomy gives teams stable names for those behaviors.

The seven categories below turn "the agents got confused" into evidence that can be counted, traced, and assigned to a control. They support the diagnostic method in root-cause analysis for AI agents.

Why multi-agent systems fail in unique ways

A single model receives one context and produces one response. A multi-agent system creates intermediate contexts. Every delegation and tool result can remove, reinterpret, or delay information. Local correctness does not guarantee system correctness.

The architecture also distributes responsibility. A planning agent may decide what should happen, while an execution agent decides how. A policy agent may approve an action based on a summary rather than the full record. Evaluation must preserve enough trace evidence to distinguish these roles.

The system-level evaluation guide treats the trajectory as the unit under test. The taxonomy classifies the points where that trajectory can become unreliable.

The seven fault types

1. Decomposition fault. The system assigns the wrong unit of work, omits a necessary task, or gives one role responsibilities that require unavailable information. The observable signal is a gap or overlap in the task graph.

2. Constraint blindness. An agent acts without a rule that applies to its decision. The rule may exist elsewhere in the system, but it is absent from the agent's context or verifier. The agent can follow its prompt perfectly and still violate the system requirement.

3. Coordination breakdown. Agents exchange incomplete, inconsistent, or ambiguous context. Look for summaries that drop qualifiers, duplicated ownership, unresolved conflicts, or downstream decisions based on superseded values.

4. Optimization failure. The system reaches an acceptable result through an operationally unacceptable path. Repeated retrieval, circular verification, excessive model calls, and avoidable latency belong here.

5. Hallucinated dependency. An agent invents a prerequisite, resource, approval, API capability, or relationship that the environment does not provide. This differs from factual hallucination because the invented item changes the workflow graph.

6. Information boundary violation. A role accesses, infers, or exposes data outside its permitted purpose. Correct output does not excuse an invalid information path.

7. Temporal misalignment. Actions use stale state, occur before prerequisites, miss deadlines, or arrive in an order that changes their meaning. Every individual action may be valid while the sequence is not.

How to identify and prevent each

Map decomposition faults with an explicit task graph and role ownership table. Prevent them with scenario coverage, dependency checks, and review of information available to each role. Map constraint blindness with a rule-attribution matrix that shows which agent and verifier own every hard requirement.

Detect coordination breakdown with trace correlation and handoff validation. Prevent schema drift with agent contract tests. Detect optimization failures with call counts, repeated-input fingerprints, latency budgets, and cost per decision.

Validate every dependency against the actual tool registry and current state. Enforce information boundaries with field-level permissions and purpose restrictions. Detect temporal misalignment by recording timestamps, versions, prerequisites, and event order rather than keeping an unordered transcript.

Controls should be attached to fault types, not to anecdotes. If the team cannot name the preventive control for a category, the taxonomy is only documentation.

Real-world examples of each failure type

In procurement, decomposition is visible when vendor-risk review has no owner. Constraint blindness appears when a sourcing agent never receives the approved-vendor rule. Coordination breakdown appears when lead time loses its units during handoff. Optimization failure appears when two agents repeatedly request the same catalog.

A hallucinated dependency appears when planning assumes an unavailable expedited-shipping service. An information boundary violation appears when supplier selection receives confidential employee data unrelated to purchasing. Temporal misalignment appears when approval uses a quote that expired before the order was issued.

These examples are diagnostic patterns, not prevalence claims. The planned aggregated failure-mode study remains blocked until enough platform runs can be anonymized and analyzed. No ranking should be published before that dataset exists.

Related evaluation guides