An AI agent is a model running in a loop: it reads the situation, chooses a tool, observes the result and decides what to do next. That loop is what makes agents useful, and it is also what makes their failures different from a chatbot's. A chatbot that hallucinates produces a wrong paragraph. An agent that hallucinates can book a non-refundable trip, delete a branch or email a customer.
This field guide catalogues the failure modes that show up most often when agents meet real systems, explains how to investigate an incident, and maps each failure to the guardrail that prevents it. It ends with a postmortem template you can copy.
Why agents fail differently
Three properties make agent failures harder than single-call LLM failures:
- Errors compound. A small mistake in step two becomes the premise of steps three through ten. If each step succeeds 95% of the time, a ten-step task with independent steps succeeds only about 60% of the time.
- Actions have side effects. Tool calls change the world. Some changes cannot be undone.
- Success is self-reported. The agent usually decides when it is done and tells you how it went. A model that is wrong about its own success produces silent failures.
Before building an agent at all, it is worth asking whether a fixed workflow would do; our agent-or-workflow decision guide helps with that call.
The eight most common agent failure modes
1. Wrong arguments to the right tool
The agent picks the correct tool but passes a wrong value: the wrong date format, a customer ID from an earlier turn, a currency in the wrong unit. These failures are common because tool schemas are often ambiguous. A parameter called date does not say whether it means check-in or booking date, or which timezone.
2. Plausible but invented inputs
When information is missing, agents tend to fill the gap with a reasonable guess rather than asking. An invented email address, an assumed budget or a guessed file path all look fine in a log until someone notices the guess was wrong.
3. Irreversible actions taken too early
The agent completes a purchase, sends a message or deletes data before it has finished gathering information, often because the task description rewarded "getting it done."
4. Runaway loops
The agent repeats the same failing tool call, oscillates between two plans, or keeps searching for something that does not exist. Without limits, loops burn money and API quotas. See step budgets and stopping rules for the fix.
5. Misread tool results
The tool returns an error, an empty list or a truncated page, and the agent treats it as success. Error messages written for humans ("Something went wrong") are a frequent cause.
6. Goal drift
Over a long run the agent loses track of the original constraint, for example a budget limit stated in the first message, and optimises for a proxy such as "found an available option."
7. Prompt injection through tool outputs
Web pages, emails and documents the agent reads can contain instructions. A model that treats retrieved text as commands can be steered into leaking data or taking actions the user never asked for. This is listed first in the OWASP Top 10 for LLM applications; our guide on red-teaming an LLM chatbot shows how to test for it.
8. False success reports
The agent reports "Done! Your meeting is booked" when the final call failed or never happened. This is the most damaging failure because it hides all the others.
Guardrails mapped to failures
| Failure mode | Primary guardrail | Secondary guardrail |
|---|---|---|
| Wrong arguments | Strict schemas with enums, units and examples | Validate arguments before execution |
| Invented inputs | Require a source for every argument | Ask-the-user tool with clear triggers |
| Irreversible actions too early | Human approval for side-effecting calls | Dry-run or draft mode first |
| Runaway loops | Step, time and cost budgets | Detect repeated identical calls |
| Misread tool results | Structured, machine-readable errors | Post-condition checks in code |
| Goal drift | Restate constraints in each step's context | Final check against original request |
| Prompt injection | Treat tool output as data, not instructions | Least-privilege tool permissions |
| False success | Verify outcomes in code, not by model report | Show evidence (IDs, receipts) to user |
Two principles run through the table. First, move checks out of the model and into code wherever possible: schema validation, budgets and outcome verification do not get tired or persuaded. Second, put a human on the irreversible edge. Patterns for doing that without annoying people are in human-in-the-loop patterns.
Tool design matters as much as the model. Clear names, narrow scopes and explicit error messages prevent the first, fifth and eighth failure modes; see designing tools agents can actually use.
How to investigate an agent incident
When something goes wrong, resist the urge to tweak the prompt immediately. Reconstruct first.
- Collect the full trace: system prompt, user messages, every tool call with arguments, every tool result, and timestamps.
- Find the first wrong step. Not the step where the damage happened, but the earliest decision that was incorrect given what the agent knew.
- Classify the failure using the list above. Most incidents are one primary mode plus a missing guardrail.
- Ask why the guardrail did not catch it. Was there no check, or was the check bypassable?
- Turn the incident into an eval case. Every real failure should become a regression test; see evaluating agents end to end.
Monitoring agents in production
Guardrails prevent known failures; monitoring finds the ones you did not anticipate. A small set of signals catches most problems early:
- Steps per task. A rising average or a long tail usually means a tool has started returning unhelpful errors or a prompt change confused the planner.
- Repeated identical calls. The same tool with the same arguments twice in a row is almost always a loop.
- Approval rejection rate. If humans reject a growing share of proposed actions, the agent's judgement has drifted, even if nothing has broken yet.
- Outcome verification failures. Count every case where the agent reported success and the post-condition check disagreed. This number should be close to zero; when it is not, it is your most important alert.
- Cost per completed task. Spikes often precede a visible incident by hours.
Sample a handful of full traces every week and read them end to end, even when the metrics look healthy. Traces reveal slow problems such as gradually longer plans, unnecessary tool calls and polite but useless clarifying questions that never trigger an alert.
A blameless postmortem template
Title: <one line, what happened, not who>
Impact: <users affected, money, data, time to detect, time to resolve>
Timeline: <timestamps of key steps from the trace>
First wrong step: <step number, what the agent did, what it should have done>
Failure mode(s): <from the field guide>
Why guardrails missed it: <missing check / bypassed check / wrong threshold>
Fixes:
- Prevent: <code-level guardrail>
- Detect: <alert or post-condition>
- Test: <new eval case ID>
Open questions: <what we still do not understand>Write postmortems about the system, not the model's "personality." "The model was overconfident" is not actionable. "The booking tool accepted a non-refundable fare without an approval step" is.
Frequently asked questions
What are the most common AI agent failure modes?
The most frequent are wrong tool arguments, invented inputs when information is missing, irreversible actions taken too early, runaway loops, misreading errors as success, losing track of constraints, prompt injection through retrieved content, and false reports of success.
How do I stop an AI agent from taking dangerous actions?
Give it least-privilege tools, require human approval for anything irreversible or expensive, validate arguments in code before execution, and verify outcomes independently instead of trusting the agent's own report.
Why do agents get stuck in loops?
Usually because a tool keeps returning an error the model cannot interpret, or because the stopping condition is vague. Set hard budgets on steps, time and cost, detect repeated identical calls, and return structured errors that say what to do next.
Should every agent failure become a test case?
Yes. Converting real incidents into regression tests is the fastest way to build an agent eval suite that reflects how your system actually breaks.
