Agent Error Handling and Recovery

Production agents fail in the same three ways over and over: a tool call errors out, the model returns malformed output, or a multi-step task gets interrupted mid-flight — and each failure needs a different recovery mechanism, not one generic try/except wrapped around the whole run. This topic is the recovery tier of agent reliability and operations, sitting after evaluation has told you something is wrong and guardrails have decided what the agent was allowed to attempt in the first place. Get it wrong and the agent does not fail loudly — it quietly duplicates a side effect or degrades in a way nobody notices until the invoice or the complaint arrives.

How to read this topic: from failure modes to durable frameworks

Start with how resilient agents recover from tool and LLM failures — it maps the detection, retry, and recovery patterns that keep one bad step from poisoning the rest of the run. Read the failure-mode and idempotency prerequisites right after: it is where the real constraints live — retries duplicate side effects unless you design against it, and a crash erases progress unless something outside the agent remembers.

When you are ready to build, the retry, fallback, and self-correction loops guide turns the theory into a spec: retry budgets, checkpointers, and validators. For where the tooling is heading, the 2026 durable-execution framework roundup tracks how LangGraph, Temporal, and Pydantic AI converged on state persistence as the real fix. Close with the ethics of graceful degradation — recovery that nobody can see is not resilience, it is a different kind of failure.

How agent error handling differs from evaluation, observability, and cost control

Three neighbouring concerns get folded into “error handling” when they are really separate jobs.

• Error handling is not evaluation. Agent evaluation and testing is how you discover a failure mode exists in the first place — trajectory scoring surfaces the wrong tool call or the silently degraded answer. Error handling only starts once that failure mode is known; you cannot design a retry budget for a class of failure nobody has measured.
• Error handling is not observability. Recovering from a failure and knowing one happened are different capabilities. A retry loop can run for weeks without a single trace proving it fired, which is exactly how agent observability earns its place next to error handling rather than inside it — the recovery mechanism and the record of the recovery are two separate builds.
• Error handling is not cost control. Every retry re-runs the LLM call it is retrying, and re-bills it. Agent cost optimization is the discipline that caps how many times a self-correction loop is allowed to spin before someone reads the invoice — without it, resilience and runaway spend look identical from the outside.

Common questions about agent error handling

Q: Is self-correction the same thing as a retry? A: Not quite — a self-correction loop is a retry that hands the model a specific error message instead of repeating the same call, so it can fix what actually went wrong rather than hoping for a different roll. The retry, fallback, and self-correction guide treats the two as one contract: retry first, self-correct when the failure is about output shape.

Q: Why does my agent duplicate a side effect after a retry succeeds? A: Because the retry re-ran the whole step, including the part that already worked — an email already sent, a charge already placed. The idempotency and durable execution prerequisites explain why a retry needs an idempotency key before it needs a backoff schedule.

Q: Does adopting a durable execution framework replace my retry logic? A: It replaces where the retry logic lives, not the need for it — engines like Temporal and LangGraph persist state between steps so a crash resumes instead of restarting, but you still define what counts as a retryable failure. How 2026 frameworks are solving agent resilience covers the composition patterns.

Q: Is graceful degradation always the safer choice over a hard failure? A: Only when it is paired with a visible record of what was skipped — an agent that quietly substitutes a fallback and logs nothing has just moved the failure somewhere nobody is looking. The ethics of graceful degradation works through where recovery quietly becomes concealment.

Part of agent reliability and operations · closest neighbour: agent cost optimization. New to this from a software background? Start with the story: Agent Reliability for Engineers: What SRE Habits Map and Break.