Failure Recovery

What is failure recovery?

Failure recovery is the process of restoring safe, useful execution after an agent step, tool, model call, dependency, or workflow fails. Recovery aims to preserve completed work, contain side effects, and choose an appropriate next action.

It is broader than trying the same call again. Depending on the failure, recovery may retry, switch tools, restore state, resume from a checkpoint, compensate for a partial action, request human help, or stop safely.

How it works

Reliable recovery begins with error classification. The system needs to distinguish temporary faults, invalid input, permission denial, missing data, policy blocks, partial success, and permanent unavailability.

It then applies a suitable strategy:

• retry a transient read;
• refresh expired credentials;
• use a fallback provider;
• replan around an unavailable capability;
• roll back or compensate for completed side effects;
• resume from durable [agent state](/glossary/agent-state/);
• escalate to a person when automation cannot continue safely.

Simple example

An agent books a hotel and then fails while reserving a flight. A full-workflow retry could duplicate the hotel booking. Recovery checks recorded state, confirms the hotel reservation, retries only the failed flight step with an idempotency key, and offers alternatives if inventory changed.

Failure recovery versus retry

A [retry](/glossary/retry/) repeats an operation. Failure recovery is the broader response to failure. A retry is useful only when the error is temporary and the operation can be repeated safely.

Failure recovery versus replanning

[Replanning](/glossary/replanning/) changes the route to the goal when assumptions or available actions change. It is one recovery technique. Recovery also covers technical concerns such as restoring checkpoints, deduplicating requests, compensating side effects, and surfacing terminal errors.

Why it matters

Agents coordinate probabilistic models and external systems, so partial failures are normal production events. Without explicit recovery, an agent may lose progress, repeat costly work, or leave real systems in inconsistent states.

Good recovery depends on durable state, clear operation identifiers, bounded retries, idempotency, observability, and honest user communication. See [Reflection in AI Agents](/reflection-in-ai-agents/) for how an agent can evaluate results before choosing a revised action.