Reliability Overview: The Seven Failure Scenarios
Production agents fail in a small number of recurring ways; each has a known mitigation, and a reliable system is one that has a planned response for all seven before launch.
Reliability for probabilistic systems
Classic reliability engineering assumes a deterministic core surrounded by unreliable dependencies. An agent inverts that: the core is a probabilistic model that may choose a different tool on the same input, plus the usual unreliable network, plus a control loop that can run forever. The goal is not to make the model deterministic; it is to make the system’s behaviour bounded and observable when the model or a dependency misbehaves.
The good news is that agent failures cluster. Across incident reviews the same seven scenarios keep appearing. Each one maps to a specific control, and most controls are ten to fifty lines of ordinary code. Failure Scenarios: Detection and Runbooks treats each in depth with its detection signal and runbook.
The seven scenarios and their mitigations
Read the list as a pre-launch checklist. If any row has no implemented mitigation, you do not yet have a production system.
- 1. A tool fails (timeout, 5xx, malformed response) → retry with exponential backoff and jitter for transient errors, fallback tool or cached value for persistent ones, and return the error to the model so it can adapt (Tool Errors, Retries and Timeouts).
- 2. The LLM chooses the wrong tool or wrong arguments → improve tool names and descriptions, tighten schemas, add a router for ambiguous cases, and build evals that catch the regression (Tool Schemas, Router Architecture).
- 3. Retrieval returns bad context (irrelevant, stale, poisoned) → fix the pipeline: chunking, hybrid retrieval, reranking, metadata filters; measure with retrieval evals (RAG Evaluation).
- 4. The provider is unavailable (outage, rate limit, degraded latency) → provider and model fallback chain with equivalent prompts, and a degraded mode that still answers something (Fallbacks, Caching and Model Routing).
- 5. The agent loops (repeats the same tool call, oscillates between two plans) → hard step limit, loop detection on
(tool, args)hashes, and a termination message (Budgets, Limits and Termination). - 6. Execution is expensive (context grows every step, retries multiply cost) → per-request token and cost budgets, context compression, cheaper models for sub-tasks (Token Budgets).
- 7. Latency is too high (serial tool calls, large contexts, slow models) → parallelise independent calls, cache prompts and results, route easy requests to smaller models, stream partial output (Parallel vs Sequential Tool Calls).
Where the controls sit
The diagram shows the loop with its reliability controls attached. Budgets and loop detection wrap the whole loop; retries and fallbacks wrap each external call; the provider chain wraps the model call. Nothing here needs a framework; it is the same control loop from The Agent Loop with guards at each edge.
Measure before you mitigate
Every scenario has a metric: tool error rate, wrong-tool rate on the eval set, retrieval precision, provider error rate, steps per task (p50 and p99), cost per task, latency p95. Without traces (Tracing Agents) and dashboards (Logging, Metrics and Alerts) you cannot tell which scenario is hurting you and whether a mitigation helped. “It felt faster after the change” is not a reliability improvement.
The philosophy from What Is Agentic AI? applies here too: the most reliable agent is often a workflow with fewer decisions in it. Before adding a mitigation, ask whether the step that fails needs to be a model decision at all.
Key points
- Agent failures cluster into seven scenarios: tool failure, wrong tool, bad retrieval, provider outage, loops, cost blow-up, high latency.
- Each scenario has a specific, mostly deterministic mitigation that can be implemented without a framework.
- Budgets and loop detection bound the loop; retries and fallbacks bound each external call.
- Every scenario has a metric; instrument first, then mitigate, then verify the metric moved.
- The most reliable fix is often removing a model decision, not guarding it.
Production failure drills
When to use — and when not to
- Pre-launch review of any agent: walk the seven scenarios and name the mitigation for each.
- Incident triage: classify the incident by scenario to find the runbook.
- Capacity planning: budgets and fallbacks determine your worst-case cost and latency.
- A single LLM call with no tools and no loop needs retries and a provider fallback, not the full set.
- Do not add loop detection to a fixed-step workflow that cannot loop.
- Do not over-engineer fallbacks for a prototype that has not yet proven it should exist.
Failure modes
- No step limit; one bad tool description makes the agent retry forever and the bill arrives Monday.
- Retries on a non-idempotent tool double-charge customers.
- Provider outage takes the whole product down because there is no fallback and no degraded mode.
- Latency p95 is 40 seconds because five independent tool calls run serially.
- No metrics per scenario, so a mitigation is shipped and nobody can tell if it worked.
Tradeoffs
The controls are cheap; the expensive part is the observability needed to know they are working.