LangGraph Guide: Persistence, Checkpoints, and Durable Agent Recovery

InYourLeague Research · 2026-08-27

Answer in brief

LangGraph checkpointers persist thread-scoped graph-state checkpoints for conversation continuity, interruption recovery, human-in-the-loop workflows, time travel, and fault tolerance. Continuing the same logical workflow requires the same thread_id, while cross-thread information belongs in a store. The supplied official sources do not define exact checkpoint commit boundaries or pending-write replay semantics.

Key facts at a glance

Failure modes and verification

FAQ

What identifies a recoverable LangGraph thread?

A graph call passes configurable.thread_id, and the checkpointer associates graph-state checkpoints with that thread. Reuse the same ID only when addressing the same logical conversation or workflow.

Exactly when is a checkpoint committed, and what happens to pending writes?

The supplied official excerpts do not define the exact checkpoint boundary or the storage, lifetime, and replay treatment of pending writes. Do not infer node-level atomicity or replay guarantees from these sources.

Does resume mean LangGraph always reruns from a particular node?

The documentation establishes continuation after interruption and recovery from failure, but it does not specify an exact replay point or state-merging algorithm. Test those details with the selected checkpointer and failure modes.

How do human-in-the-loop and time travel depend on persistence?

Checkpointers retain the thread state used for human review, state inspection or modification, and time-travel workflows. Authorization, approval policy, conflict handling, and history selection remain application concerns.

Which checkpointer should I choose?

Use an in-memory saver only when losing checkpoints on process restart is acceptable. The supplied troubleshooting excerpt names PostgresSaver as a persistent PostgreSQL example and SqliteSaver as a local development example; it does not present them as an exhaustive catalog.

Sources and freshness

• Official source
• Official source
• Last verified: 2026-08-27

Extended guide

Direct answer

LangGraph uses a checkpointer to persist graph-state checkpoints for a thread. Each graph call supplies configurable.thread_id, which identifies the thread whose state should be read or updated. Reusing that ID addresses the same logical conversation or workflow; using a different ID creates a separate thread context. A store has a different scope: it holds application-defined data that must remain available across threads. These roles are documented in the official LangGraph overview and persistence guide.

Evidence-backed persistence model

Safe implementation sequence

1. Compile the graph with a checkpointer. Add a store only when the application also needs durable information outside one thread: builder.compile(checkpointer=checkpointer, store=store).
2. Assign one stable ID to each logical conversation or workflow and invoke the graph with {"configurable": {"thread_id": "thread-1"}}.
3. Reuse that thread_id when addressing the same persisted thread. Do not reuse it for unrelated users or workflows, because their state would share the same thread identity.
4. Treat resume as continuation from persisted thread state, not as proof of a specific node-level replay rule. Test failure and interruption scenarios against the chosen checkpointer before relying on finer guarantees.
5. Use persisted state for human review or time-travel workflows, but define application-level authorization, approval, conflict handling, and history-selection rules separately.
6. Use a store when information must survive beyond one thread. For subgraphs, note that separate checkpoint namespaces can delay visibility in the parent graph; the guide suggests shared store data or writing to the parent checkpoint.

Checkpointer choice and maintenance

MemorySaver and InMemorySaver keep checkpoints in RAM, so their data is lost on process restart. In the supplied troubleshooting guidance, PostgresSaver is named as a persistent PostgreSQL option with asynchronous support, while SqliteSaver is named as a local file-based option for development. These are documented examples, not an exhaustive catalog. Agent Server manages persistence infrastructure automatically.

For PostgresSaver, keep thread_id values under 255 characters. A random UUID is compact but is not deterministic; if the same source identity must always map to the same thread ID, use an appropriate hash or an application-managed mapping. Long-running threads also need checkpoint pruning or a retention policy to control storage growth.

Publication boundary

The official sources establish the persistence roles, scopes, and listed use cases above. They do not establish exact checkpoint commit timing, pending-write lifecycle, replay order, merge behavior, or transaction guarantees. Those details should be verified in more specific documentation or with deployment-representative tests before they are stated as guarantees.

Model availability note: The official source does not specify a selectable model ID.