failure modes a user actually sees
Failure modes a user actually sees are the externally visible ways an AI agent breaks: looping without progress, failing when a tool or service errors, or returning a polished but false answer. They matter because agent control flow is generated at runtime, so reliability must be designed around behaviour, not just exceptions.
These failures are necessary to name because users do not experience “agent architecture”. They experience waiting, repetition, missing results, broken integrations, and confident nonsense. Unlike a conventional request handler, an agent may choose its next step dynamically, so the bad path is not always a single thrown exception. A loop can look like activity while doing no useful work, and a hallucinated answer can look more successful than a crash.
A practical way to picture the mechanism is a loop: decide what to do, call a tool or take an action, observe the result, then either continue or answer. Stalls happen when decisions keep selecting actions that do not change the state. Tool failures happen when action or observation receives an error, timeout, malformed payload, or partial data. Wrong answers happen when the final response turns weak or absent evidence into fluent certainty.
The trade-off is that robust agents need explicit limits and recovery paths, not just a better prompt or a larger model. Timeouts, retry budgets, circuit breakers, idempotent tool calls, structured traces, and fallback responses add engineering work and can make the agent less free-form. Agent-specific controls, such as iteration caps, repeated-state detection, tool-call validation, evidence requirements, and uncertainty rules, may occasionally stop a recoverable run, but they prevent invisible runaway behaviour.
Engineers meet these failures when moving from demo to production: support tickets about endless runs, traces showing the same tool call repeated, dashboards full of 500s from dependencies, or eval cases where the answer sounds plausible but contradicts the source. The right response is to design unhappy paths before launch: interrupt loops usefully, classify tool errors, tell the user what was not completed, and log enough state to reproduce the run.
Common questions
- Is this just another name for hallucination?
- No. Hallucination is only one visible failure mode, usually at the answer stage. A user may also see an agent spin in a loop, retry a broken tool, lose track of progress, or stop after a dependency fails. Treating all of these as hallucination hides the control-flow and systems problems that need separate fixes.
- Can a stronger model eliminate these failures?
- Not by itself. A stronger model may plan better and recover from more cases, but production failures also come from network errors, bad tool schemas, stale state, ambiguous user requests, and missing evidence. The honest answer is that reliability depends on model behaviour plus defensive system design, observability, and evaluation against realistic failure cases.
- What should the user see when an agent fails?
- The user should see a bounded, truthful recovery, not an endless wait or invented success. For a loop, stop and explain what could not be resolved. For a tool failure, say which operation did not complete and whether retrying may help. For weak evidence, show uncertainty, ask for clarification, or provide only the supported parts.