13.02 · Concept
The failure modes a user actually sees
Handle the loop that stalls, the tool that 500s and the answer that is confidently wrong.
Agent failures should be designed as visible product failures: stalled loops, broken tool calls and confident false answers. Robust agents need bounded execution, retry and fallback behaviour, evidence checks, uncertainty handling and traceable state, so users get a useful recovery path instead of latency, dead ends or misleading prose.
What this lesson answers
- how to stop an agent infinite loop
- what should agents do when tools 500
- how to prevent confidently wrong agent answers
Notes
An agent fails in ways that look different from ordinary software bugs because the control flow is partly produced at runtime. A user may see the agent repeat itself forever, call the same tool again and again, stop making progress, crash because a dependency returned a 500, or produce a fluent answer that is simply false. Treat these as product failure modes, not model mysteries: the user experiences latency, dead ends, broken promises, and misplaced confidence.
A useful mental model is an agent loop with four checkpoints: decide, act, observe, and answer.
Common questions
- Why do agents get stuck repeating the same action?
- An agent can stall when its decision step keeps choosing actions that do not reduce uncertainty or move the task towards completion. Because the next step is produced at runtime, normal control flow assumptions do not fully apply. Use iteration caps, repeated-state detection and progress checks, then return a clear interruption rather than letting the loop continue.
- How should an agent handle a tool returning 500?
- Treat the tool failure as a dependency failure, not as a model problem. Classify whether the error is retryable, apply a retry budget and timeout, and avoid repeating unsafe side effects unless the call is idempotent. If recovery fails, tell the user which part could not be completed and preserve enough trace data to debug it.
- How do you reduce confident hallucinations in agent answers?
- Require the answer step to be grounded in available evidence, especially when a tool was supposed to provide the facts. Prefer citations, retrieved data or explicit tool results for claims that matter. When evidence is weak or a dependency failed, the agent should say so, ask for clarification or present uncertainty instead of smoothing over the gap.
Short definition: what is failure modes a user actually sees?