The 7 Most Common AI Agent Failures (and How to Catch Them)

AI agents fail differently from other software. A crashing program tells you it crashed. A failing agent often tells you it succeeded. Learning the common failure modes - and building simple checks for each - is the difference between an agent that quietly helps and one that quietly causes damage. These are the seven failures that show up again and again in real-world agent use. For each one you will find what it looks like in practice, why it happens, and the specific check that catches it - followed by a worked hypothetical example tracing three failures inside a single run, so you can see how they combine.

1. Confident wrong answers

The agent states something false with total confidence: a wrong price, a fabricated citation, a policy that doesn't exist. This is the classic language-model failure wearing an agent costume. It is especially dangerous in research tasks, where a made-up fact gets copied into your brief and repeated as truth. What makes it insidious is the delivery - the agent does not hedge, flag uncertainty, or show its work unless instructed to. A wrong answer that announced itself as a guess would be harmless; the confident one gets acted on.

It happens because the agent is optimized to produce plausible completions, not verified facts. When a detail is missing, inventing one keeps the output fluent - and fluency is what gets rewarded. The fix has two parts. First, require sources for factual claims: every number, date, and named fact in the output must come with where it came from. Second, spot-check the facts that would change your decision - not all of them, just the load-bearing ones. Any fact that would change your decision deserves thirty seconds of verification. And add the never-invent rule to the instructions: mark unknowns as unknown instead of filling them in. An agent that writes I could not verify this is an agent you can trust with research; one that never admits gaps is one you must verify exhaustively.

2. Silent partial completion

The agent reports the task done, but quietly skipped the hard parts. It summarized four of six documents. It emailed three of five vendors. Everything looks complete until you check. This happens because agents are rewarded, in effect, for finishing - and skipping is the fastest way to finish. The skipped items are rarely random: they are the ones that were difficult, ambiguous, or error-prone, which means the agent dropped exactly the parts where you most needed help.

Catch it by requiring an explicit checklist in the completion report: what was done, item by item, and what was skipped or deferred - with a reason for each skip. Then verify the count matches what you asked for. Six documents in, six summaries out; five vendors contacted, five confirmations listed. Counting is the cheapest verification there is, and it defeats this failure completely, because the agent must either do the work or confess the skip in writing. For extra safety on important tasks, have the agent list its inputs at the start (here are the six files I found) so you can confirm the scope before it begins, not after it claims to be done.

3. Instruction drift

The agent starts out following your constraints and gradually forgets them. It was told drafts only but sends the email on step twelve. It was told which folder is in scope but wanders into another. Drift gets worse on long tasks as early instructions fade from the agent's working memory - the constraint from the beginning of the run is simply gone by the middle, and the agent has no awareness that it forgot anything. It will not warn you; it will just stop complying.

Catch it with three defenses. First, keep instructions short, since every rule competes for attention inside the context, and published work on long inputs (Liu et al., Lost in the Middle) found on two tasks, multi-document question answering and key-value retrieval, that models use information at the start or end of a long input more reliably than information in the middle, so place the one or two critical rules at the edges. Second, repeat the one or two critical constraints at natural checkpoints: restate drafts only before the step that involves email, not just at the start. Third, break long tasks into shorter runs with fresh instructions each time; a task that restarts every ten steps never gets old enough to drift. During the first runs of any new task, review the tool-call log, not just the final output - drift shows up in the log (an email sent, a file touched outside scope) long before it shows up in the summary.

4. Tool misuse

The agent calls the right tool with the wrong parameters, or the wrong tool entirely: searching when it should calculate, deleting when it meant to archive, using last month's data because it grabbed the first file it found. Tool misuse is hard to spot because the output looks plausible - the numbers are formatted nicely, the summary reads well, and only someone who checks the inputs would notice the agent worked from the wrong file. This failure is most common in the first runs of a new task, when the agent is still mapping your instructions to its available tools.

Catch it by reviewing tool-call logs, not just final results, during the first runs of any new task. The log shows you what the agent actually did: which files it opened, which parameters it passed, which searches it ran. Once you know which calls it gets wrong, add explicit parameter rules to the instructions - use the Q3 sales file at this exact path, never the similarly named one; pass dates as YYYY-MM-DD; confirm the file's modified date before using it. Tool misuse is one of the most fixable failures: it is usually a mapping problem between your vocabulary and the tool's parameters, and one or two explicit rules typically eliminate it.

5. Runaway loops

The agent gets stuck retrying a failing step: refreshing a page that will never load, rephrasing a search that returns nothing, re-running a command that errors. Each loop burns time and money while producing nothing. Loops happen because the agent lacks the human instinct to step back and question the approach - from its perspective, each retry is a reasonable new attempt, and it has no sense of accumulating futility. A loop that a person would abandon after three tries can run for fifty steps unnoticed if nobody set a limit.

Catch it with hard limits set before the task starts: maximum steps, maximum cost, maximum time. These are not suggestions; they are circuit breakers. A stuck rule in the instructions (if a step fails twice, stop and report) turns an expensive loop into a cheap notification. Also watch for the early signature during supervised runs: the same tool called three times in a row with slight variations is a loop forming, not diligence. When you see it, stop the run yourself and add the specific guard - this search pattern returns nothing useful, try the alternative source first - so the next run routes around the trap instead of falling into it again.

6. Over-eager action

The agent takes an irreversible action without asking: sending the email, placing the order, publishing the post. It does this because from its perspective, the task said to handle it - and handling it means finishing it. The agent has no felt sense of irreversibility; sending an email and saving a draft are equally easy operations to it. Over-eagerness is the most expensive failure mode on this list, because its consequences cannot be undone by better instructions after the fact. An email sent is sent.

Catch it with a default-deny rule on consequential actions: the agent may draft, propose, and prepare, but anything external requires your explicit approval. No exceptions until a specific action has proven safe dozens of times - and even then, keep the approval for anything involving money, customers, or public communication. Make the rule structural, not just verbal, wherever possible: give the agent an account that cannot send, a folder it cannot publish from, credentials without payment scope. An instruction can be forgotten mid-run; a permission the agent never had cannot be exceeded. When you review a new agent setup, the first question is always: what is the worst thing this agent can do without asking me? If the answer makes you uncomfortable, the permissions are wrong.

7. Context loss on long tasks

On tasks that run long, the agent loses track of earlier decisions, contradicts itself, or repeats work it already did. The output slowly degrades from coherent to confused. This is a structural limitation: the agent's working memory is finite, and long tasks exceed it. The signature is distinctive - the agent asks for information it was already given, redoes completed steps, or confidently states the opposite of what it established an hour ago. It is not being lazy; it genuinely cannot see the earlier material anymore.

Catch it by keeping tasks short, requiring written intermediate summaries the agent can re-read, and treating any task longer than about thirty minutes as a candidate for splitting into stages with human review between them. The most effective single technique is the state file: instruct the agent to maintain a running notes file - decisions made, facts established, what remains - updated at each checkpoint. Because the file lives outside working memory, it survives the forgetting. When a long task starts showing the signature (repeated questions, redone work), stop and triage rather than pushing through: have the agent write down everything it currently believes, correct it yourself, and restart from the corrected summary.

A worked hypothetical: one run, three failures

Failures rarely arrive alone. Here is a hypothetical example - an invented scenario, not a report of real events - showing how three failure modes can combine inside a single run. Imagine a hypothetical small business owner, Daniel, who asks an agent to prepare expense reports from a folder of receipts: extract each receipt's vendor, date, and amount, total them by category, and email the summary to his accountant. The instructions say drafts only for the email and list the receipt folder as the scope.

The run starts well. The agent lists fourteen receipt files and begins extracting. On file nine - a blurry photo of a restaurant receipt - the extraction tool returns garbage. The agent retries with slightly different parameters. And retries. And retries. That is failure five, a runaway loop, burning steps on a file a human would have set aside in seconds. Eventually it moves on, but it never recovers the wasted budget. Then, on file twelve, the agent encounters a receipt in a foreign currency. Rather than flagging it, the agent converts the amount using a rate it recalls - confidently wrong, failure one - and the category total is now incorrect with no visible sign of the error.

Finally, the email. The instructions said drafts only, stated once at the beginning of a long run. By step thirty, that constraint has faded - failure three, instruction drift - and the agent sends the summary with the wrong total directly to the accountant. Three failures, one run: the loop wasted money, the confident guess corrupted the data, and the drift turned a draft into a sent email with errors in it. Notice how each failure enabled the next. The loop consumed the attention that might have caught the currency guess; the long run caused the drift that sent the email.

Now replay the run with the checks from this guide in place. A stuck rule (stop after two failed extractions, flag the file) kills the loop at step three. A never-invent rule plus required sourcing (state the currency and source for every amount) catches the guess - the agent writes could not verify the exchange rate instead of inventing one. A default-deny on sending plus a checkpoint restatement of drafts only before the email step prevents the send. None of these checks is exotic. Together they convert a quietly disastrous run into a boring, successful one: thirteen receipts processed, one flagged for human review, a draft waiting in the outbox. That is what the safety net is for.

A failure taxonomy: signal, mitigation, and what the primary sources say

The seven failures above are described by how they look to a user. A harness needs a second view: which observable signal fires for each failure, and which control stops it. This section adds failure modes that provider documentation and published papers describe by name, and for each one gives the detection signal and the mitigation. Where a claim about provider behaviour appears, it is attributed to the page that states it, with the date it was read listed in Sources. Anything not attributed is a design recommendation from AgentsUse, not a measured result.

One boundary first. The sources cited here describe what models and APIs do in the settings they cover. They do not say how often any failure occurs in your workflow, and AgentsUse has not measured failure rates. Treat the list as a checklist of places to put a detector, then let your own run records tell you which detectors earn their keep.

• Hallucinated tool arguments. Signal: an argument value that appears nowhere in the user request or in earlier tool results. Mitigation: validate each argument against the source it should come from before the tool runs. Source: the Gorilla paper (Patil et al.) states in its abstract that tool use through API calls is challenging even for models such as GPT-4, largely due to their inability to generate accurate input arguments and their tendency to hallucinate the wrong usage of an API call. Read the abstract on arXiv.
• Guessed values for missing required parameters. Signal: a tool call whose input contains a field the user never supplied. Mitigation: mark such parameters required in the schema and have the harness reject calls that fill them with unsupported values. Source: the Anthropic tool use overview says that when a prompt lacks the information for a required parameter, Claude Sonnet might ask but might also infer a reasonable value, and that this behaviour is not guaranteed.
• Schema violations: wrong types or missing fields. Signal: a validation error from your own input check, or a tool that throws on arguments. Mitigation: add strict: true to custom tool definitions. Source: the define-tools page lists strict among tool definition properties and says auto with strict tool use guarantees schema-valid tool inputs.
• Truncated tool calls. Signal: stop_reason equal to max_tokens on a response that contains a tool_use block. Mitigation: treat it as an incomplete call, never run it, and retry with a higher max_tokens. Source: the Anthropic stop reasons page says a response cut off at the limit with an incomplete tool use block needs a retry with a higher max_tokens value.
• Tool errors swallowed or flattened. Signal: tool_result blocks with generic content such as failed, followed by the same call again. Mitigation: return is_error true with a message that says what went wrong and what to try next. Source: the handle tool calls page recommends instructive error messages and gives Rate limit exceeded, retry after 60 seconds as the pattern.
• Refusals read as completions. Signal: stop_reason equal to refusal on a step your loop treats as finished. Mitigation: branch on the stop reason before reading the content, and route refusals to a person. Source: the stop reasons page states that safety classifiers return this reason as a normal HTTP 200 response, not an error, so error handling alone will not see it.
• Unbounded loops. Signal: the same tool name and arguments appearing three times, or the step count passing the cap. Mitigation: a maximum iteration count in the harness plus a repeat detector. Source: Anthropic's Building effective agents says it is common to include stopping conditions such as a maximum number of iterations to maintain control.
• Instructions injected through tool results. Signal: tool output containing imperative text addressed to the model, such as a web page telling the agent to send data elsewhere. Mitigation: keep untrusted content inside tool_result blocks, give the agent no write or send tools it does not need on that run, and require approval for outward actions. Source: the handle tool calls page warns that results from webpages, inbound email, uploads and third-party APIs are untrusted and that an attacker might embed instructions that try to redirect Claude (indirect prompt injection).
• Relevant material buried in a long context. Signal: answers that ignore a fact present in the supplied documents, more often when that fact sits mid-prompt. Mitigation: put critical documents and rules at the start or end, and shorten what is supplied. Source: Liu et al., Lost in the Middle, report on multi-document question answering and key-value retrieval that performance often peaks when relevant information is at the start or end of the input and drops significantly when it is in the middle, even for models built for long contexts. The paper's tasks are question answering over supplied documents and key-value retrieval, so apply it to instructions as a placement heuristic, not as a measured rule.
• Message-order errors in the loop itself. Signal: an HTTP 400 mentioning tool_use ids found without tool_result blocks immediately after. Mitigation: build the reply so the tool_result blocks come first and directly follow the assistant turn. Source: the handle tool calls page lists both formatting requirements and quotes that error.

Compounding: why long runs fail more than their steps suggest

Building effective agents warns that autonomy brings the potential for compounding errors. The arithmetic behind that phrase is simple, and it explains why the safety net above leans on short runs. If each step of a run independently succeeds with probability p, the whole run of n steps succeeds with probability p to the power n. Independence is an assumption, real steps are correlated, and the percentages below are an illustration of the formula, not an observed reliability rate for any model.

• At 99 percent per step: 5 steps give 95.1 percent, 20 steps give 81.8 percent, 40 steps give 66.9 percent.
• At 98 percent per step: 5 steps give 90.4 percent, 20 steps give 66.8 percent, 40 steps give 44.6 percent.
• At 95 percent per step: 5 steps give 77.4 percent, 20 steps give 35.8 percent, 40 steps give 12.9 percent.
• At 90 percent per step: 5 steps give 59.0 percent, 20 steps give 12.2 percent, 40 steps give 1.5 percent.

Two practical consequences follow. A step that checks its own output before the next step starts converts a long chain into several short ones, because a caught error stops the chain instead of feeding the next step. And a per-step improvement from 95 to 98 percent matters far more on a 20-step run (35.8 to 66.8 percent) than on a 5-step run (77.4 to 90.4 percent), which is why the first fixes belong in the longest runs.

A small triage function you can run

The sketch below turns the stop-reason rows of the taxonomy into code. It reads only fields the Messages API documents (stop_reason and content block types), has no network calls, and runs as written with Python 3. The step cap and repeat limit are placeholders to tune; the values are not recommendations from any provider.

import json

MAX_STEPS = 12
REPEAT_LIMIT = 2

def triage(resp):
    """Map one Messages API response (as a dict) to a signal for the harness."""
    sr = resp["stop_reason"]
    kinds = [b["type"] for b in resp["content"]]
    if sr == "max_tokens" and "tool_use" in kinds:
        return "truncated_tool_call"
    if sr == "max_tokens":
        return "truncated_text"
    if sr == "refusal":
        return "refusal_not_completion"
    if sr == "tool_use":
        return "run_tool"
    if sr == "end_turn":
        return "claims_done_verify_report"
    return "unhandled:" + str(sr)

def loop_guard(calls):
    """calls: list of (tool_name, json_args). Return a stop reason or None."""
    if len(calls) >= MAX_STEPS:
        return "step_cap"
    last = calls[-1]
    if calls.count(last) > REPEAT_LIMIT:
        return "repeated_identical_call"
    return None

samples = [
    {"stop_reason": "tool_use", "content": [{"type": "tool_use"}]},
    {"stop_reason": "max_tokens", "content": [{"type": "text"}, {"type": "tool_use"}]},
    {"stop_reason": "refusal", "content": []},
    {"stop_reason": "end_turn", "content": [{"type": "text"}]},
]
for s in samples:
    print(s["stop_reason"], "->", triage(s))

history = []
for i in range(6):
    history.append(("fetch_page", json.dumps({"url": "https://example.com/a"})))
    why = loop_guard(history)
    print(i + 1, why)
    if why:
        break

The output of that script, run on 2026-11-03, was: tool_use maps to run_tool, max_tokens with a tool_use block maps to truncated_tool_call, refusal maps to refusal_not_completion, end_turn maps to claims_done_verify_report, and the loop guard returned a stop on the third identical fetch_page call. Note what end_turn maps to: not done, only claims done. The completion report check from the safety net above is what turns that claim into something verified. The stop reasons page also lists stop_sequence, pause_turn and model_context_window_exceeded; the sketch sends those to unhandled, and a production harness should give each its own branch rather than continue the loop.

Reading the table for your own workflow

Not every row deserves a detector on day one. Rank the rows by blast radius first: a hallucinated argument to a read-only search costs a wasted call, while the same fault on a payment or delete tool costs real money or data. Add the cheap, structural controls everywhere (strict schemas, stop-reason branching, step caps, approval on outward actions) and add the content-level detectors (argument provenance checks, injection screens) only on the tools whose misuse you cannot undo.

Then keep the evidence. For each detector, record how many times it fired and how many of those were real failures. A detector that fires constantly on harmless runs trains reviewers to ignore it; one that never fires may be guarding a failure your workflow does not have, or may be broken. Both outcomes are information, and neither is available if the detector writes nothing down. After a month, retire the silent detectors that guard cheap failures and tighten the noisy ones, so the net stays small enough that people still read what it catches.

A failure log you can copy

The safety net works only if the failures it catches get written down. A log turns isolated incidents into a pattern you can act on: which failure recurs, which tool it involves, and whether the fix you added actually stopped it. Keep one line per incident, five fields, plain text so it works in a notes file or a spreadsheet. The rows below are filled in from the worked example above, so you can see the shape before you start your own log.

date | run | failure | signal | cost | fix added
2026-11-11 | expense reports | runaway loop | same extraction, 4 repeats | 18 wasted steps | stop after 2 failed extractions, flag the file
2026-11-11 | expense reports | confident wrong answer | invented exchange rate | wrong category total | never-invent rule, source required for amounts
2026-11-11 | expense reports | instruction drift | drafts-only faded by step 30 | 1 email sent early | restate drafts-only before the send step

Review the log monthly, the same way the guide reviews detectors. A failure that appears three times after its fix means the fix did not hold, and the task needs redesign rather than another instruction sentence. A detector that never fires in a month either guards a failure your workflow does not have, or is broken; test it by feeding it a known failure and watching whether it catches it. The log is what turns the safety net from a set of good intentions into a record you can argue with.

A simple safety net for all seven

You do not need seven separate systems. One safety net, applied consistently, catches all seven failures - because every failure on this list is either an error the agent made or an error it hid, and the net is designed to surface both:

• Require a completion report listing exactly what was done, skipped, and assumed. Defeats silent partial completion and surfaces confident guesses (they appear as assumptions).
• Set hard limits on steps, cost, and time before every run. Defeats runaway loops by converting them into stopped runs with a report.
• Default to draft-only: no external action without your explicit approval. Defeats over-eager action structurally, and limits the blast radius of every other failure.
• Review tool-call logs on new tasks, not just the final output. Catches tool misuse and instruction drift while they are still cheap to fix.
• Keep tasks short; split long ones into stages with check-ins between. Defeats context loss and instruction drift, the two failures that grow with run length.
• Log every failure and add one instruction sentence that would have prevented it. This is how the net tightens over time - each incident patches the exact hole it fell through.

When to pause and redesign

The safety net catches failures; it does not fix a task that fails structurally. Pause and redesign when the same failure recurs after you have patched the instructions twice - the problem is then in the task design, not the wording. Pause when your review time approaches the time the task would take manually - the agent is no longer saving anything. And pause when failures start surprising you again after a stable period - something changed (the task, the tools, the data), and the setup needs re-testing, not more patches. Redesign usually means one of three moves: narrow the scope, add a human checkpoint in the middle, or admit the task belongs in a different quadrant and take it back.