LangGraph Learns to Survive Failures: Retries, Timeouts and Error Handlers for Production Agents

LangChain has published a detailed guide to the three resilience primitives built into LangGraph. Without them, any production agent inevitably breaks in places where the prototype ran like clockwork.

Why prototypes break in production

In the lab, a LangGraph agent looks reliable: inputs are fixed, external APIs respond quickly, and the user is always available. Real-world operation looks different. External services hang or return 503 under load. LLM providers delay responses by minutes at peak demand. In human-in-the-loop scenarios, a person may not reply for hours. Without dedicated handling, each of these cases turns into a hung or crashed agent.

The classic solution is to wrap every call in try/except, write timers and add retry logic by hand. That works, but the defensive code grows, gets tangled up with business logic and becomes a source of bugs itself. LangGraph takes a different approach: three primitives built into the engine that work declaratively.

RetryPolicy: automatic retries

RetryPolicy configures automatic retries with exponential backoff. The adjustable parameters are the maximum number of attempts, the initial delay, the maximum delay and the factor by which the delay grows between attempts.

You can set the policy for a specific node that calls an unstable external API, or apply it to the whole graph as a global default. The second option is convenient when all interaction with external services should follow a single set of recovery rules.

TimeoutPolicy: time limits

TimeoutPolicy solves a different problem: it limits how long a node is allowed to run. Two types of limits are supported:

• `wall_clock_timeout`: the maximum wall-clock time a node can run, from start to finish
• `idle_timeout`: the maximum idle time. This matters most in human-in-the-loop scenarios: if the user has not replied within N minutes, the agent must continue down an alternative branch or finish with an error
• Both limits can be combined in one policy, and whichever is reached first triggers
• When a limit is exceeded, the engine raises an exception automatically
• The policy can be applied to a node, a subgraph or the whole graph

The key advantage of both primitives is that they live inside the engine and see the full context of the graph state. External decorators and wrappers cannot do that.

error_handler and the SAGA pattern

error_handler is the third primitive, and it fires after all retries are exhausted. It is the final recovery point: rolling back actions already performed, sending notifications, saving diagnostics, and moving the agent into a safe state.

For multi-step agents with real side effects, such as reserving resources, charging payments or creating records in external systems, LangChain recommends the SAGA pattern. The idea is that each agent step is paired with a compensating operation that undoes its effect. If step N fails after steps 1 through N-1 have completed successfully, the compensating operations run in reverse order, returning the system to a consistent state. LangGraph lets you build SAGA directly into the graph: compensations are stored next to the nodes, and error_handler runs their chain on failure.

"Having resilience policies inside the engine rather than outside it is a fundamental difference: recovery logic gets the full context of the graph state," the

LangChain blog says.

What this means

LangGraph offers mature tooling for moving AI agents from prototype to real-world operation. Retries, timeouts and compensating transactions are built into the engine and do not require wrapping every node by hand. For teams building agents for production workloads, this reduces the amount of defensive code and makes failure behavior predictable and controllable.