Agent Failure Modes: A Taxonomy Worth Memorising

When an agent produces a bad result, the instinct is to blame the model and reach for a better one. Sometimes that is right. More often the trace shows a specific, nameable failure that a stronger model would have committed slightly more fluently.

Agents fail in a small number of recognisable ways. Learning to identify them from a trace is the highest-leverage debugging skill in this area, because the fix differs completely between them and none of the fixes is "try a bigger model".

Perception failures

The agent misreads its input. A tool returns paginated output and it treats page one as the whole result. A search returns nothing and it interprets the empty result as confirmation rather than absence. A file is truncated and it reasons about the visible half.

These are almost always tool design problems. A tool that returns silently truncated output invites this failure on every run. Make truncation explicit in the payload, make empty results say so in words, and include totals so the agent can tell forty of forty from forty of four hundred.

The tell in a trace is a confident conclusion immediately after a tool result that did not actually support it. If you see that pattern twice, fix the tool rather than the prompt — tool schema design is where this class of bug is cheapest to eliminate.

Planning failures

The plan is wrong before any step executes. The agent solves an adjacent problem, skips a prerequisite, or produces a plan whose steps do not compose.

The characteristic symptom is that every individual step succeeds and the outcome is still wrong. Nothing errored, so no retry logic triggers, and monitoring based on error rates sees a perfectly healthy run.

Fixes live upstream: sharpen the objective, make the agent state its plan before executing, and check the plan against the requirements before spending anything on it. Agent planning strategies covers the trade-offs between planning up front and replanning as you go.

Loops and thrash

The agent repeats a step, alternates between two approaches, or reformulates the same failing call indefinitely. Token spend rises with no state change.

This one is mechanically detectable, which makes it the cheapest failure to defend against. Hash the tool call and arguments, count repeats, and intervene after two or three. The intervention matters more than the detection: telling the agent explicitly that it has already tried this and it failed, with the error, tends to break the cycle where a bare retry does not. Detecting agent loops goes into the detection patterns.

Note the subtler variant: an agent that alternates between two files, each time convinced the other holds the answer. Step counts look normal and no single call repeats, but the run makes no progress.

Context failures

The relevant fact was in the context and the agent did not use it. Early instructions get dropped in favour of recent tool output, or a constraint stated at turn two is violated at turn thirty.

Long contexts degrade unevenly — material in the middle is recalled less reliably than material at either end, the effect described in the lost-in-the-middle problem. Loading more context is therefore not automatically an improvement.

The practical fixes are structural: restate hard constraints near the end of the prompt, compact aggressively, and keep tool output out of the window once it has been used. Agent memory and context management covers the mechanics.

Tool-use failures

The agent calls the right tool with wrong arguments, or calls the wrong tool for the job, or invents a tool that does not exist.

Malformed arguments are usually a schema problem. Vague parameter names, optional fields with unclear semantics and free-text arguments that should be enums all invite it. Tightening the schema fixes more of this than any prompt instruction.

Wrong-tool selection is usually a description problem, and specifically an overlap problem: two tools whose descriptions could both plausibly cover the request. Make descriptions say when not to use the tool, not just what it does.

Verification failures

The agent completes the work, declares success, and is wrong. Tests were not run, or were run and their failure was rationalised, or success was inferred from the absence of an error message.

This is the most dangerous class, because it produces confident output that flows downstream into other agents and other systems. It is also the one prompting fixes least well — an agent asked to be careful will report being careful.

The fix is external verification. Run the tests yourself and feed the real result back. Check the file actually changed. Where correctness matters, a separate reviewer with a fresh context beats any amount of self-assessment, for the same reason a second pair of eyes works on human code.

Environment failures

Rate limits, timeouts, transient upstream errors, a tool endpoint that is down. Ordinary distributed-systems failure, arriving in the middle of a stateful multi-step run.

These are well-understood in isolation, and the agent-specific part is what happens to the half-finished work. A run that dies after three of five mutations has left the world in a state nobody designed, which is why partial failure recovery is a design concern rather than an afterthought.

Cascade failures in multi-agent systems

One agent's flawed output becomes another's premise. The second agent reasons impeccably from a false start, and by the third stage the original error is unrecoverable and invisible.

The useful question after a cascade is not which agent erred but which handoff was ambiguous. That means logging every brief and every result verbatim, so the chain can be reconstructed — the failure tree is the artefact you debug, not any individual run.

Using the taxonomy

Label failures as they occur rather than reasoning about them in the abstract. Sample twenty bad runs, tag each with one of these classes, and count. Teams that do this almost always find one class accounts for over half the failures, and it is rarely the one they were about to fix.

Then match the fix to the class: perception failures to tool output, planning failures to objectives and plan review, loops to detection and intervention, context failures to compaction, tool-use failures to schemas, verification failures to external checks, environment failures to recovery design, cascades to handoff logging. Changing the model is what you do after that, not instead of it.