What are agent failure modes?

Summary slides

Why naming distinct failure modes matters more for agents than for single model calls

A single, isolated model call has a comparatively narrow space of things that can go wrong with it: the response is factually incorrect, poorly grounded in what it was given, or simply not what was asked for in the first place, and while those are problems, they all show up in roughly the same place, the final output, and can be caught by roughly the same kind of evaluation. An agent executing a multi-step task introduces an entirely different structure of risk, because failure can originate at any one of several distinct stages, planning, tool selection, tool execution, interpretation of a tool’s result, decision-making about what to do next, and a failure introduced early in that sequence often doesn’t look like a failure at all at the moment it first occurs, it looks like a reasonable step that only turns out to have been wrong once its consequences surface several steps later.

This is exactly, precisely why treating “the agent simply failed” as a single, undifferentiated category is such a limiting way to think about agent reliability as a whole, since two agentic failures that look identical from the outside, a wrong final answer, a task left incomplete, can trace back to entirely different root causes that call for entirely different fixes. An agent that looped unproductively without ever converging needs better loop detection and retry logic; an agent that misused a tool along the way needs meaningfully better tool descriptions or better parameter validation; an agent that planned around a false premise needs meaningfully better upstream verification of its working assumptions before it ever commits to acting on them; and a team that doesn’t distinguish between these separate cases ends up either applying the wrong fix to the wrong actual problem, or, more commonly still applying a vague, generic fix that only partially, incompletely addresses whichever failure happened to be observed most recently.

Building a taxonomy of agent failure modes, then, isn’t merely an academic exercise conducted purely for its sake, it’s the practical foundation that makes targeted detection, targeted recovery, and targeted evaluation possible at all, since a team can’t build a detector for a failure mode it hasn’t named and distinguished from its neighbors, and can’t measure whether a fix worked without first knowing precisely which failure mode that fix was meant to address.

How planning failures differ from execution failures

The single most fundamental distinction in agent failure modes cleanly separates failures in the plan itself from failures in executing an otherwise entirely sound plan, and conflating the two is one of the most common ways teams misdiagnose what went wrong with a failed task.

A planning failure occurs specifically when the agent’s overall approach to a task, the sequence of subgoals it decides to pursue and the order it pursues them in, is flawed from the start, whether because it misunderstood what the task required, made a false assumption about the state of the world it was operating in, or chose a subgoal that doesn’t serve the task’s objective. An agent asked to find a document and summarize it might, for instance, plan around the assumption that the document exists in a particular location without ever verifying that assumption first, and everything that follows from that plan, however well-executed, inherits the flaw baked into its very first premise. An execution failure, by clear contrast, occurs specifically when the underlying plan itself was sound but something instead went wrong in the actual process of carrying it out, a tool call with a malformed parameter, a misread of a tool’s returned result, a step performed out of the order the plan called for.

This distinction matters directly for how a failure should be diagnosed and fixed, since retrying or correcting an execution failure at the step level can resolve it, but applying that same step-level correction to a planning failure will simply reproduce the same eventual problem in a slightly different form, because the actual defect lives upstream of the step where it finally became visible. Recognizing which category an observed failure belongs to, rather than reflexively treating every failure as an execution problem simply because that’s where it was first noticed, is the single most consequential diagnostic judgment call in understanding agent failure modes at all.

How tool-use failures break down into their distinct subtypes

Tool use is specifically the point where an agent’s internal reasoning meets the actual external world it’s operating in, and it’s consequently one of the richest sources of distinct, nameable failure modes, since a tool call can go wrong in several different ways that each call for a different response.

Tool selection failure, choosing the wrong tool for a subgoal even in cases where a better-suited tool was available the whole time, often stems from ambiguous or incomplete tool descriptions that don’t clearly differentiate when one tool should be used over a similar one, and it’s detectable specifically by checking whether the tool invoked matches what the subgoal, described independently, would call for. Parameter construction failure, choosing the right tool but supplying it with malformed, incomplete, or incorrectly formatted arguments, is usually the most mechanically detectable of the tool-use failure modes, since the tool’s validation or error response typically identifies the problem directly, which is exactly the kind of failure the parameter-correction retry strategy discussed elsewhere in agent reliability design is well suited to address.

Result misinterpretation, where a tool call succeeded and returned a perfectly correct result, but the agent’s subsequent reasoning misreads or misuses that result, treating a null or empty result as though it meant something other than “found nothing,” missing a qualifying detail buried within a larger returned payload, is considerably harder to catch than the two failure modes above precisely because nothing about the tool call itself looks wrong, the defect lives entirely in how the agent’s reasoning processed a result that was, in fact, delivered correctly. Overreliance and underreliance on tools round out this whole category: an agent that reaches for a tool call when its reasoning could have answered a simple question directly wastes cost and latency on unnecessary tool invocations, while an agent that reasons its way to an answer it should have verified with an available tool risks confidently stating something that a simple, available check would have caught as wrong.

How reasoning failures differ from failures in the world the agent is operating in

A further important distinction cleanly separates failures that originate directly in the agent’s reasoning from failures that instead originate in the actual state of the world the agent happens to be operating in at the time, since these look similar from the outside, a task that didn’t complete successfully, but call for entirely different responses.

A reasoning failure means the agent had accurate, correct information available to it and still somehow drew an incorrect conclusion from that very same information, misapplying a rule, making an invalid inference, or contradicting itself across the course of a longer sequence, and this is a failure that traces back entirely to the model’s processing rather than to anything wrong with the task’s underlying environment. An environmental or informational failure means the agent reasoned correctly what it knew, but what it knew was itself incomplete, outdated, or simply unavailable, a piece of information the task required that wasn’t accessible through any tool the agent had, a precondition for success that simply didn’t hold in the world regardless of how well the agent reasoned about it.

Distinguishing these two matters enormously for what a reasonable response looks like, since a reasoning failure is something the agent itself, or the surrounding system’s evaluation and correction mechanisms, can address through better prompting, better verification steps, or a more careful review of its intermediate conclusions, while an environmental failure isn’t something better reasoning can fix at all, no amount of additional thinking produces information that simply isn’t accessible, and the only honest response to an environmental failure is acknowledging the actual limitation rather than continuing to reason harder about a gap that reasoning alone was never going to close.

How goal drift causes an agent to succeed at the wrong thing

A distinctive failure mode specific to longer, more open-ended agentic sequences is goal drift, where an agent’s actions remain individually coherent and well-reasoned at every step, yet the sequence as a whole gradually moves away from the task’s actual original objective, ending in a result that’s internally consistent and even successfully achieved on its own narrower terms, but isn’t what was originally asked for.

Goal drift is particularly insidious and hard to catch precisely because it doesn’t look like a failure at any single individual step along the way, an agent that drifts doesn’t make an obviously wrong decision at any single point, it makes a series of individually reasonable decisions that each subtly reinterpret or narrow the original task in a way that compounds across the sequence, until the final result reflects a task that’s related to, but meaningfully different from, what was requested. A common, quite concrete pattern here is subgoal substitution, where an agent, faced with difficulty accomplishing the actual, original goal, gradually redirects its effort toward a related but easier subgoal it can more readily complete, eventually delivering well-executed work on the substitute goal while never returning to the original, harder one.

Catching goal drift requires an altogether different kind of check than simply catching an ordinary execution error, since no single step in a drifting sequence looks wrong in isolation, which means detection has to periodically compare the agent’s current trajectory against the original task specification directly, rather than only checking whether each individual step was executed correctly whatever the agent currently believes it’s trying to accomplish. This is exactly the kind of check that benefits from being performed by a process with visibility into the original task alongside the current state, rather than one embedded entirely within the agent’s ongoing, potentially already-drifted reasoning, since an agent that has already drifted has no particular reason to notice its drift from purely within its current frame of reference.

How overconfidence and premature action cause a distinct category of harm

A failure mode that deserves its separate, dedicated treatment, distinct from the accuracy-focused failures already discussed at length so far, is an agent acting with more confidence, and often more consequential real-world effect, than its actual underlying certainty warranted, taking a sometimes hard-to-reverse action based on an inference or an assumption it should have verified first.

This particular failure mode is especially consequential in tool-using agentic systems specifically because tools capable of taking real-world action, sending a message, modifying a record, executing a transaction, turn an overconfident inference into an external consequence rather than merely a wrong sentence in a generated response that a reader might catch and discount. An agent that infers a user’s likely intent and acts directly on that inference, rather than confirming it first when the action in question is consequential, is exhibiting exactly this failure mode even when the underlying inference itself happens to be reasonable, since the actual problem isn’t that the inference was unreasonable, it’s that the agent treated an inference as sufficiently certain to justify action without any explicit step checking whether that certainty was warranted given what was at stake.

Addressing this particular failure mode well means building an explicit, deliberate distinction directly into an agent’s decision logic between actions that are safe to take on inference alone and actions that warrant a verification or confirmation step first, calibrated to how consequential and how reversible the action in question is, rather than treating every action an agent might take as equally appropriate to execute purely on the basis of the agent’s internal confidence, however that confidence happens to have been arrived at.

How failure modes compound across a multi-step sequence

Individual failure modes rarely occur in complete, clean isolation within a longer agentic sequence, and understanding how they compound across several steps is often more practically useful than understanding any single failure mode in isolation, since the compounding pattern itself is frequently what turns an individually minor issue into a significant final failure.

An early reasoning failure left uncorrected doesn’t just affect the one step where it originally occurred, it becomes a false premise that every subsequent step then plans and executes around, which means a single early mistake can produce an entire sequence of individually well-executed but ultimately misdirected later steps, none of which are themselves the actual root cause of the eventual bad outcome. A tool-use failure that produces a misleading rather than an obviously erroneous result compounds in a related but distinct way, since the agent has no signal that anything went wrong and continues reasoning confidently from a subtly incorrect foundation, which is considerably more dangerous than a tool failure that produces an obvious error, precisely because an obvious error at least gives the agent, and any downstream detection, something concrete to notice and respond to.

This compounding dynamic is exactly, precisely why catching a failure as close as possible to where it originated matters disproportionately more than catching it only once its consequences have already propagated through several further, dependent steps, and it’s why the stage-evaluation discussed elsewhere in AI system design, checking planning quality, checking individual tool calls, checking intermediate reasoning, each independently rather than only checking a sequence’s final output, is what makes it possible to trace a compounded, multi-step failure back to the single point where it began, rather than only ever observing the tangled, downstream result several steps later.

How to build detection tuned to each distinct failure mode

Because these various failure modes differ in both their underlying cause and their observable character, effective detection simply can’t rely on one single, generic check applied uniformly across every one of them, and building detection coverage requires a distinct, purpose-built signal for each category rather than hoping one broad evaluation mechanism will happen to catch everything.

Planning failures are best, most reliably caught by explicitly validating a plan’s premises before execution ever begins, checking whether the assumptions a plan is built on are verified or merely assumed, rather than only discovering a flawed premise once its downstream consequences have already surfaced several steps into execution. Tool-use failures benefit from validation applied directly and specifically at the tool-call boundary itself, checking selected-tool-against-subgoal fit, checking parameter validity against what the tool accepts, and, for the harder case of result misinterpretation, checking whether the agent’s stated understanding of a tool’s result matches what that result literally contained.

Goal drift, as discussed, requires a periodic trajectory-level comparison against the original task rather than any step-level check, and reasoning failures specifically benefit from an explicit self-consistency check, comparing an agent’s current conclusion against its earlier stated reasoning within the same sequence to catch the case where a later step quietly contradicts an earlier one without either the agent or a purely step-level check ever directly noticing the contradiction. Building this differentiated detection well means actively resisting the temptation to fold everything into one broad “does this look right” evaluation applied only to a sequence’s final output, since that kind of evaluation, however thorough, structurally can’t distinguish which failure mode produced a bad outcome, and a team that can’t distinguish the failure mode has no basis for knowing which of the very different fixes discussed throughout this article is the right one to apply.

How failure modes shift when multiple agents coordinate on a shared task

Every single failure mode discussed at length so far has quite reasonably assumed a single agent operating entirely on its own, but multi-agent systems, where several agents delegate subtasks, exchange intermediate results, or coordinate toward a shared objective, introduce a further category of failure that doesn’t reduce cleanly to any single agent’s individual mistakes, since the actual defect lives in the interaction between agents rather than within any one of their local reasoning processes.

Miscommunication failure, where one agent’s output is technically, entirely correct but nonetheless gets misinterpreted by the agent receiving it, whether because the sending agent’s phrasing was ambiguous, because it omitted context the receiving agent needed, or because the receiving agent made an unwarranted assumption about what the sender meant, is a distinct failure mode from anything a single agent working alone could exhibit, since it requires two independently reasonable agents whose reasonable behaviors simply don’t compose cleanly together. Coordination failure, where two or more separate agents each pursue their locally sensible strategies that end up actively conflicting or needlessly duplicating effort, one agent repeating work another has already completed, two agents each waiting on the other to proceed first, wastes resources and can stall a shared task indefinitely even though no individual agent involved ever made an obviously wrong decision on its own terms.

Responsibility diffusion is a considerably subtler multi-agent failure mode that deserves naming specifically and explicitly, where a task that requires ongoing attention or an action falls into a gap between two or more agents, each of which reasonably assumed another agent in the system was already handling it, producing a failure that traces back not to any single wrong decision but to an absence of any single agent ever having clearly owned the relevant responsibility in the first place. Detecting these particular interaction-level failures requires monitoring scoped specifically to the overall multi-agent exchange rather than to any single individual participant’s internal reasoning, tracking whether messages between agents are being interpreted as intended, whether agents’ respective actions are converging toward the shared task rather than conflicting or duplicating, and whether every part of the task has some agent that has explicitly taken ownership of it, since none of these properties are visible from within any single agent’s local, necessarily partial view of the overall interaction.

How failure mode taxonomy should inform how an agentic system is designed, not just how it’s debugged

Everything discussed at length throughout this article so far has treated failure mode taxonomy primarily and mainly as a diagnostic tool, useful after the fact for understanding what went wrong and why, but a mature use of this taxonomy feeds back into how an agentic system is architected from the start, since knowing in advance which failure modes a kind of task is prone to lets a team design structural defenses rather than relying entirely on after-the-fact detection and recovery.

A task type already known, from prior experience, to be particularly prone to planning failures, one involving significant upfront uncertainty about the actual state of the world the agent will be operating in, benefits from an architecture that builds explicit premise verification directly into the planning stage itself, rather than only checking for flawed premises reactively once their downstream consequences have already surfaced during execution. A task type already known, again from prior experience, to be particularly prone to goal drift, a long, open-ended task with many plausible intermediate subgoals along the way, benefits from architecture that builds periodic, explicit re-grounding against the original task specification directly into the execution loop, rather than treating that re-grounding as an optional check that might or might not get applied consistently.

This forward-looking use of failure mode taxonomy is what separates an agentic system that merely recovers reasonably well from failures it happens to encounter from one that was designed, from the start, around the failure modes its particular class of tasks is most prone to exhibiting. A team that goes and builds a new agentic capability without first, deliberately asking which of the failure modes discussed throughout this article that capability is most likely to encounter is leaving available design leverage on the table, effectively choosing to discover those failure modes reactively out in production rather than anticipating and specifically designing against the most likely ones from the very start.

How to build an evaluation dataset around observed failure modes

A failure mode taxonomy only earns its actual keep once it’s actively connected to an evaluation practice built specifically, deliberately around it, since a taxonomy that exists purely as a conceptual framework, with no corresponding set of test cases designed to exercise each named failure mode directly, provides diagnostic vocabulary without providing any ongoing mechanism for verifying whether a failure mode has been addressed or merely discussed.

Building this kind of evaluation set well starts with deliberately, carefully constructing scenarios that isolate each named failure mode as cleanly and as precisely as possible, a task specifically designed to tempt an agent into a flawed planning premise, a task whose correct completion specifically depends on correctly interpreting an ambiguous tool result, a long, open-ended task with a checkable subgoal substitution an agent might plausibly drift toward, so that a test failing or passing on a case tells a team something about that one failure mode rather than only providing an undifferentiated pass or fail signal that could trace back to any number of underlying causes. This deliberate isolation is what turns evaluation from a blunt, aggregate quality signal into a diagnostic tool, one that can tell a team not just that something is currently going wrong but specifically which of the failure modes discussed throughout this article is responsible for an observed regression.

Production failures, once observed and correctly diagnosed against the existing taxonomy, deserve to feed directly back into this evaluation set as new, concrete test cases, since a taxonomy built only from anticipated failure modes, however thoughtfully constructed in advance, will inevitably miss failure patterns that only become visible once a system meets the variety of tasks and edge cases production traffic presents. Treating this evaluation set as a living, continuously expanding artifact rather than a fixed collection finalized once during initial development is what keeps the taxonomy itself honest and current, rather than gradually drifting out of touch with the actual failure modes a system’s evolving traffic continues to surface over time.

Common mistakes teams make around agent failure modes

A first mistake, and the foundational one nearly every other mistake on this list traces back to in some form, is treating every agentic failure as a single, undifferentiated category, applying the exact same generic fix regardless of whether the actual root cause was a planning failure, a tool-use failure, a reasoning failure, or an environmental limitation no amount of reasoning could ever have closed.

A second mistake is diagnosing every failure as an execution problem simply because that’s the point where it happened to first become visible, missing the common case where the underlying defect originated upstream in a flawed plan that no amount of step-level correction could ever fix.

A third mistake is writing ambiguous or meaningfully overlapping tool descriptions that fail to clearly differentiate when one tool should be used over a similar, nearby one, directly inviting exactly the tool-selection failures that clear, deliberately well-differentiated descriptions would otherwise have straightforwardly prevented.

A fourth mistake is only ever checking whether a tool call itself technically succeeded, without ever separately checking whether the agent’s subsequent interpretation of that tool’s returned result was correct, missing the considerably harder-to-catch case of a tool call that succeeded but whose perfectly good result was then simply misread.

A fifth mistake is failing to distinguish reasoning failures from environmental or informational failures, applying better prompting or additional reasoning steps to a gap that no amount of further reasoning could ever close, since the missing piece of information was unavailable rather than merely unreasoned-about by an insufficiently careful agent.

A sixth mistake is evaluating a completed agentic sequence only by whether its final output happens to look reasonable on the surface, missing goal drift entirely, since a drifted sequence can quite easily produce an internally coherent well-executed result that simply, quietly isn’t what was originally requested at all.

A seventh mistake is checking each individual step of a longer sequence only against the agent’s current, quite possibly already-drifted understanding of the task, rather than periodically, deliberately comparing the ongoing trajectory back against the original, unaltered task specification directly and explicitly.

An eighth mistake is letting an agent take consequential, hard-to-reverse action purely on the basis of its internal, self-reported confidence, with no explicit verification step calibrated to how consequential and how reversible the action in question is.

A ninth mistake is treating every single possible agent action as equally appropriate to execute purely on inference alone, failing to distinguish actions that are safe to take from inference from those that specifically, clearly warrant confirmation first given their concrete stakes in the world.

A tenth mistake is catching a failure only once its consequences have already propagated through several further, dependent downstream steps, rather than deliberately investing in detection specifically designed to catch each named failure mode as close as possible to wherever it originally began.

An eleventh mistake is relying entirely on one broad, generic evaluation of a sequence’s final output alone to catch every single failure mode, when that kind of coarse, single-point evaluation structurally can never distinguish which failure mode produced a bad outcome in the first place.

A twelfth mistake is building detection and recovery logic without first constructing a named taxonomy of the failure modes an agentic system is prone to, leaving a team unable to measure whether a fix addressed the failure it was intended to address.

A thirteenth mistake is treating multi-agent failures as fully reducible to individual agents’ separate mistakes, missing miscommunication, active coordination conflicts, and responsibility diffusion, failure modes that live specifically and only in the interaction between agents rather than within any single agent’s necessarily local reasoning.

A fourteenth mistake is using failure mode taxonomy purely as a reactive diagnostic tool applied only after something has already, visibly gone wrong, rather than actively feeding it forward into how a new agentic capability gets architected around the failure modes its particular task type is most likely to encounter.

A fifteenth and truly final mistake is building an evaluation set purely from anticipated failure modes and never feeding correctly diagnosed production failures back into it, leaving the whole taxonomy and its corresponding tests to gradually drift out of honest touch with the actual failure patterns a system’s evolving traffic keeps continuing to surface over time.

What connects all fifteen of these mistakes is treating agent failure as a single, generic phenomenon rather than as a family of distinct failure modes, each with its cause, its detectable signature, and its appropriate response. Teams that build a named taxonomy of the failure modes their agentic systems are prone to, and build detection and recovery specifically tuned to each one, tend to develop agentic systems whose failures become increasingly rare and increasingly well-understood over time, while teams that skip this deliberate differentiation tend to keep rediscovering the same underlying problems repeatedly, each time under a slightly different surface appearance that a more careful taxonomy would have already recognized and already had a targeted answer for.

The broader value of thinking this way is that it turns agent reliability from a vague, anxiety-inducing worry, “will the agent do the right thing,” into a tractable engineering problem, an enumerable list of the ways things can go wrong, each with its detectable signature and its appropriate response. That shift in framing matters practically, because a vague worry produces vague, scattershot mitigation, while a named list of failure modes produces targeted defenses that can be built, tested, and verified one at a time rather than hoped for all at once through some single, undifferentiated notion of “making the agent more reliable.”

Teams that build and continually refine this kind of taxonomy, connecting it to detection, recovery, and evaluation rather than treating it as a one-time conceptual exercise, tend to end up with agentic systems whose failures become increasingly rare, increasingly well-understood, and increasingly cheap to fix as the system matures, precisely because each new failure encountered adds one more well-characterized entry to an already substantial and already actionable body of institutional knowledge about exactly how, and exactly why, this particular kind of system tends to go wrong.