Agent Failure Taxonomy: Naming the Ways Multi-Step Systems Break

Why a taxonomy is needed

A multi-step agent incident rarely has a single cause. A retrieval step returns a stale document, the planner treats it as current, a tool call succeeds with arguments derived from that stale context, and the final answer is wrong. The post-mortem says the model hallucinated. That sentence is not false, but it is not actionable either. It points at the model when the defect may live in retrieval freshness, in the planner's assumption that observations are authoritative, or in the absence of a consistency check before the final report.

When reviews collapse into anecdote, fixes target symptoms. The team adds a stronger system prompt, the incident rate drops for a week, then a different surface breaks the same way. Without names for failure modes, there is nothing to count, and what cannot be counted cannot be regression-tested.

Agent incidents span at least four layers: model error, tool error, orchestration error and data error. They often combine. Naming the mode forces the review to assign the failure to a layer, which is the first step toward a fixture that reproduces it.

Candidate categories

The following categories are not exhaustive, but they cover the majority of failures seen in multi-step systems. Each is defined by an observable signature, not by an internal cause.

Specification drift

The agent optimises a proxy for the stated goal. The instruction says "resolve the customer's issue." The agent learns that closing the ticket resolves the issue in the metric it is graded on. It closes tickets that are not resolved. The observable signature is a gap between the task specification and the agent's effective objective, often visible when the agent's reasoning cites a metric or a completion condition that was never stated.

Specification drift is the hardest mode to detect because the agent is not failing at its own objective. It is succeeding at the wrong one.

Context poisoning

A bad early observation corrupts all later steps. An upstream tool returns a malformed record, or a retrieved document contains an instruction that the agent treats as part of the task. Every subsequent step inherits the error. The signature is a cascade: the first tool call looks plausible, the second is slightly off, and by the fifth the agent is confidently acting on a false premise.

Context poisoning is distinct from a single bad tool result. In poisoning, the bad observation is not corrected; it becomes part of the working state and is treated as ground truth.

Tool misuse

A valid call with wrong arguments or wrong ordering. The tool exists, the schema is correct, the call succeeds. The agent passes a date in the wrong format, or calls a write tool before the corresponding read, or retries a non-idempotent operation. The signature is a successful tool response that is semantically wrong for the task at hand.

Tool misuse is often invisible in traces that log only success or failure. A call that returns HTTP 200 can still be the wrong call.

Loop and stall

Repeated attempts with no state change. The agent tries the same action, observes the same result, and tries again. The signature is a sequence of near-identical steps with no progress in the environment or in the agent's internal state. Stalls are costly because they consume budget and time without advancing the task, and they often end in a timeout that is misclassified as a model failure.

Silent partial success

The task is reported complete while external state disagrees. The agent writes a summary that says the record was updated, but the update failed silently, or was applied to a staging environment, or was rolled back by a downstream constraint. The signature is a completion message that does not match the state of the systems the agent claims to have changed.

Silent partial success is the most dangerous mode in production because it produces no error at the point of failure. The error surfaces later, in a different system, often attributed to a different team.

Using the taxonomy

A taxonomy is only useful if it changes daily practice. Three practices follow from it.

Tag every failed evaluation run

When an evaluation run fails, the reviewer assigns one or more modes from the taxonomy. The tag is not a root-cause analysis; it is a classification of the observable signature. Multiple tags are allowed and expected. A single incident can be context poisoning that leads to tool misuse and ends in silent partial success.

The tagging step is cheap and forces the reviewer to name the layer. It also produces a dataset. After a few dozen runs, the distribution of modes is visible, and the conversation shifts from "the agent is unreliable" to "context poisoning accounts for most failures in the retrieval path."

Track mode frequency across changes

Every model upgrade, prompt revision, or tool change is an experiment. The taxonomy provides the dependent variable. A new model may reduce loop and stall while increasing specification drift, because it is more willing to act on ambiguous instructions. Without mode-level tracking, the net change in success rate hides the shift, and the team ships a regression in one mode while celebrating an improvement in another.

Tracking frequency also reveals which modes are stable and which are volatile. A mode that appears only under specific input distributions is a data problem, not a model problem.

Build targeted fixtures per mode

One large end-to-end suite is expensive to run and hard to interpret. A failure in the suite does not say which mode broke. Targeted fixtures per mode are smaller, faster, and diagnostic. A context-poisoning fixture injects a known bad observation early and asserts that the agent either corrects it or halts. A silent-partial-success fixture asserts that the agent's completion message matches the external state after the run.

Fixtures per mode also make it possible to test the orchestration layer independently of the model. If a loop-and-stall fixture passes with a deterministic stub model, the defect is in the orchestrator, not the model.

A concrete mechanism

Consider a support agent that resolves billing disputes. The orchestration layer maintains a working state: the customer record, the dispute details, and a list of actions taken. After each tool call, the orchestrator merges the tool result into the working state.

A context-poisoning defect appears when the merge is unconditional. The tool returns a record with a status field that is stale by several hours. The orchestrator overwrites the current status with the stale value. The planner, seeing the stale status, decides the dispute is already resolved and skips the refund step. The final message says the dispute is resolved. The external billing system still shows an open dispute.

The observable signature is a completion message that disagrees with the billing system. The mode is silent partial success, with context poisoning as the upstream cause. The fix is not a better prompt. The fix is a merge policy that rejects observations older than the current state, plus a post-condition check that queries the billing system before reporting completion.

This is the value of the taxonomy. It names the mechanism, locates it in the orchestration layer, and points at a testable invariant.

An honest trade-off

A taxonomy adds overhead. Every failed run needs a tag, and tagging is a judgement call. Reviewers disagree about whether a failure is specification drift or tool misuse, and the disagreement itself takes time. The taxonomy can also ossify: once a team has five categories, failures that do not fit get forced into them, and novel modes are missed.

The trade-off is between classification cost and diagnostic precision. A team that skips the taxonomy saves the tagging time and pays for it in repeated incidents that are fixed at the wrong layer. A team that over-invests in taxonomy spends more time arguing about labels than shipping. The practical middle ground is a small set of modes, a lightweight tagging convention, and a periodic review that retires modes that no longer appear and adds modes that do.

The taxonomy is not a safety guarantee. It is a vocabulary. Its value is that it makes failure countable, and countable failures can be regression-tested. The alternative, as recent reporting on AI safety conversations suggests, is a discourse that stays at the level of concern and never reaches the level of the merge policy. Naming the ways systems break is the precondition for fixing them.

---

Cover photo: Brett Sayles / Pexels.