Initial input state
AI Models & Assistants / Knowledge library
Agent Checkpointing
Saves a recoverable snapshot of workflow state at controlled boundaries
Why learn Agent Checkpointing?
It enables resumption, time travel for debugging, human review, and fault recovery.
The problem it solves
It creates reliable restart points in workflows whose state changes across many steps.
Where it came from
A checkpoint can preserve messages, current node, pending actions, application state, and metadata. Checkpoint frequency trades storage and write overhead against the amount of work repeated after failure.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Agent Checkpointing and identify its place in an agent architecture.
- Choose a task where Agent Checkpointing improves an agent system.
- Diagnose one failure caused by misusing Agent Checkpointing.
- Interpret a trace or state transition involving Agent Checkpointing.
- Explain one operational tradeoff of Agent Checkpointing.
Documentation and sources
- LangGraph persistence documentation (docs.langchain.com)
Connect the ideas
Explore next
Real World Example
Resilient Automated Underwriting Pipeline
A financial services firm processing high-volume loan applications through multi-step AI agents.
The business problem
Long-running underwriting workflows frequently fail due to transient network issues or external API timeouts, forcing the entire multi-hour process to restart from the beginning, which wastes compute resources and delays applicant decisions.
How this topic solves it
By implementing LangGraph checkpointers, the system saves a recoverable snapshot of the workflow state at controlled boundaries. If a node fails, the agent can resume execution from the last successful checkpoint rather than re-processing previous steps, ensuring fault tolerance and continuity.
- Initialize a persistent checkpointer, such as PostgresSaver, to store state snapshots outside of volatile memory.
- Compile the underwriting graph by passing the checkpointer instance to the builder.compile method.
- Define logical checkpoints at high-risk transition points, such as after document verification or credit score retrieval.
- Configure the execution environment to pass a unique thread_id for each loan application to track its specific state.
- Implement a recovery mechanism that queries the checkpointer for the latest state when a process interruption is detected.
This diagram illustrates how the agent saves state at critical milestones to allow for fault recovery.
First processing node
State saved to database
Second processing node
Workflow completion
- Application Received → initiates → Doc Verification
- Doc Verification → persists state → Checkpoint A
- Checkpoint A → resumes from → Credit Analysis
- Credit Analysis → completes → Final Decision
Implementation example
This code demonstrates initializing a persistent Postgres checkpointer and compiling the graph to ensure that the underwriting state is saved and recoverable via a unique thread_id.
from langgraph.checkpoint.postgres import PostgresSaver
# Initialize the persistent checkpointer for production
checkpointer = PostgresSaver.from_conn_string("postgresql://...")
# Compile the graph with the checkpointer to enable state persistence
graph = builder.compile(checkpointer=checkpointer)
# Invoke with a unique thread_id to track this specific loan application
result = graph.invoke({"loan_id": "123"}, {"configurable": {"thread_id": "loan-123"}})Expected business outcome
The underwriting pipeline achieves greater reliability, allowing for seamless resumption of interrupted tasks and a reduction in redundant processing cycles.
Limitations and checks
Checkpoints can grow unboundedly over long-running processes, potentially increasing storage overhead; this is checked by monitoring database size and implementing a retention policy or periodic pruning of old checkpoints.