Agent failure modes are the recurring ways agents break in production: wrong tool selection, invalid tool arguments, missing context, bad planning, retrieval failure, policy violation, loops, unsafe actions, and a weak final answer.
The list matters because agent failures are multi-step, and the final output is the worst evidence about which step broke. A user reporting “it gave me the wrong number” could be looking at a retriever that returned nothing, a 429 never retried, a plan that omitted the step they asked about, or a constraint honored for nine turns and dropped on the tenth. Same complaint, four different fixes.
These categories exist because an agent is a loop around a model, with tools, state, and control flow. Every failure mode of a single model call applies at each step, and the loop adds its own.
Key takeaways
- Agent failures are trajectory failures. The span that surfaces the error is usually downstream of the span that caused it.
- The recurring categories: no-progress loops, wrong tool, right tool with malformed arguments, ignored context, false completion, dropped constraints, bad handoffs.
- The most expensive category is the one that reports success: nothing errors and nothing pages you.
- Classifying a failure before fixing it stops a team from rewriting a system prompt to solve a rate limit.
The categories worth naming
The agent loops without making progress
The agent calls search_docs, gets nothing useful, rephrases slightly, calls it again, and repeats until it hits a step cap or a token budget. Nothing errors. Every span has status OK.
Two variants. If the arguments are nearly identical across calls, the agent has no strategy for a failed search and is retrying by reflex. If the arguments change but the results are never used, each iteration restarts from the same premise. Detection is cheap: count repeated calls with the same normalized arguments. The fix is a stopping condition and an instruction for the empty-result case, not a smarter model.
It calls the wrong tool
The agent picks create_ticket when the user asked for status, or refund_order when they asked whether a refund is possible. With 40 tools registered, accuracy degrades unevenly: overlapping descriptions get confused with each other, and a catch-all description absorbs calls that belong elsewhere. This is usually a documentation bug rather than a reasoning bug, and stating when *not* to use a tool fixes more cases than any instruction to think carefully.
It calls the right tool with malformed arguments
Correct tool, unusable input. A date passed as next Tuesday into a field that wants ISO 8601. A required filter left null. An account ID invented in exactly the right format. An enum value that is plausible and not in the schema.
If the tool validates and returns a clear error, the agent often recovers next turn and the only residue is latency and spend. If the tool accepts it, you get a confident answer built from the wrong query. Record arguments on every tool span and validate them offline: failure rate per tool, per argument, is one of the highest-yield numbers you can compute.
It ignores the context it retrieved
The right document came back and the answer contradicts it. Both suspects behaved, which is what makes it confusing. Usual causes are the passage sitting mid-context, two conflicting passages where the model picked the wrong one, and a system prompt whose instructions outrank the evidence. Catching it means comparing the answer against the context actually sent, which requires recording retrieved chunks as span attributes.
It stops early and reports success
The agent was asked to update three records, updated one, and wrote “I have updated the records.” Or it was asked to verify a fix, ran nothing, and said the tests pass. This category reaches users most often, because every automated check is happy: no errors, no timeout, a complete-looking message, a session that ended normally. The reliable detection is checking the claim against the trace. An agent claiming it wrote a file, in a trace with no write span, is a false completion.
It drops a constraint from earlier in the session
On turn 2 the user said to keep everything in EUR and never contact the customer directly. On turn 14 the agent quotes dollars and drafts an email. The instruction is still inside the context window and has still lost influence, which is why a larger window does not fix it. Session-long constraints belong in structured state that gets re-injected each turn, not in conversational history competing with 40 turns of tool output.
It hands off without what the receiver needs
In multi-agent setups the orchestrator delegates “handle the billing question” and omits the account tier, the currency, and the fact that the customer already tried the self-serve path. The subagent does competent work on an underspecified task and returns something confidently wrong. Nothing in its own trace looks broken, because the failure was in what the parent passed down.
Why the failing span is rarely the guilty span
Later steps trust earlier steps, so a plausible wrong value becomes the premise of everything after it and the error surfaces where an assertion finally fails. Reading backwards from that error finds the messenger; reading forwards finds the first step whose output was wrong, which is the step to fix. It is also why scoring the final answer is a weak instrument: agent testing catches classes of failure that conventional unit tests miss because the interesting ones live in a sequence of decisions, not one function’s return value.
Telling them apart
- No error, high step count, repeated arguments. No-progress loop.
- Error at the tool boundary with a validation or schema message. Malformed arguments.
- A call that succeeded and was not the one the task needed. Wrong tool.
- Correct evidence in context, answer that contradicts it. Ignored context.
- Confident completion message, no spans for the work claimed. False completion.
- A rule satisfied early in the session and violated late. Dropped constraint.
- Subagent output that is internally coherent and wrong for the real task. Bad handoff.
Each call needs the trajectory in order, which is why agent evaluation operates on the trace rather than the response. Reliability work comes after this. You cannot set an error budget for a failure you cannot name.
FAQ
What is the most common agent failure mode?
The distribution differs enough between agents that a general answer is not useful. The pattern worth expecting is that tool-layer failures, wrong tool and malformed arguments, outnumber the reasoning failures that get more attention. Sample 50 of your own failures and count.
How are agent failure modes different from LLM failure modes?
A single-call failure is a property of one input and output pair: hallucination, refusal, format violation, wrong tone. An agent failure is a property of a sequence. Those modes still apply at every step, and the agent adds control flow, tool use, state, and delegation, each of which breaks in ways one call cannot.
Can evals detect these automatically?
Some cleanly. Argument validity, repetition thresholds, and missing-span checks for claimed work are deterministic. Others need a judge reading the trajectory: whether the plan matched the request, whether a step followed from prior context, whether the answer honored the constraints. A few need ground truth you supply, such as whether a tool’s return value was correct.
Does a better model make these go away?
It moves the mix. Stronger models pick tools more accurately and produce fewer malformed arguments. Dropped constraints, false completions, and bad handoffs are structural, coming from how state is carried and how completion is verified, and they survive a model upgrade.
