Skip to main content
In this lesson we demonstrate how to implement persistent conversational memory with LangGraph. Real-world assistants must often resume conversations across sessions: users close an app and return hours or days later expecting the assistant to remember earlier context. LangGraph addresses this with checkpointing — saving the graph state after each interaction so a conversation can be resumed later by loading that saved state. What you’ll learn
  • How to model a minimal conversation state for LangGraph
  • How to implement a simple chatbot node that updates state
  • How to attach a checkpointer (here: InMemorySaver) to persist state per conversation thread
  • How to resume a conversation using the same thread_id
Keywords: LangGraph, persistent memory, checkpointing, stateful workflows, resume conversation, chat history

Overview of the approach

  1. Define a TypedDict for the shared conversation state.
  2. Create a node that reads the latest message, produces a reply, and updates state.
  3. Build and compile a StateGraph, attaching a checkpointer.
  4. Invoke the graph with a thread_id to save state.
  5. Re-invoke with the same thread_id to resume the conversation.
  6. Inspect saved state via get_state.

Step 0 — Required packages and imports

Step 1 — Define the conversation state

The graph’s state is the shared memory between nodes. Keep it minimal for this demo: a messages list holding HumanMessage and AIMessage objects.

Step 2 — Create the chatbot node

This node inspects the latest message in state["messages"], forms a reply (simulated here), appends the reply to the history, and returns the updated state.

Step 3 — Build and compile the graph with a checkpointer

Create a StateGraph, register the node, set entry/finish points, and compile the graph while attaching an InMemorySaver checkpointer. The checkpointer persists the graph state after each invocation under a thread identifier.

Step 4 — Start the first session (create a thread)

Use a config including a thread_id to uniquely identify this conversation. Invoke the graph with an initial HumanMessage. The graph processes input, appends a reply, and the checkpointer saves the resulting state under thread_id.

Step 5 — Simulate the user returning later (resume the thread)

When the user returns, invoke the graph again with the same thread_id. LangGraph will load the previously saved state automatically so the assistant “remembers” the prior conversation history.
Expected console output (example):

Step 6 — Inspect the saved state

You can verify persistence by calling get_state with the same config (same thread_id). The saved state will include the full conversation history.
This confirms the system stored and restored the conversation memory.
Avoid using InMemorySaver for production: in-memory checkpointers do not survive process restarts or multi-instance deployments. Always choose a durable backing store (see examples below).
In this lesson we used an in-memory checkpointer for simplicity. For production deployments, replace InMemorySaver with a durable checkpoint implementation so conversations persist across restarts and multiple instances.

Checkpointer options and recommendations

Use a durable store for production — here are common choices: For links and references:

Wrap-up

Persistent memory is essential for realistic conversational AI. LangGraph implements this via stateful workflows plus checkpointing:
  • Nodes read and update a shared state,
  • The checkpointer persists that state under a conversation identifier (e.g., thread_id),
  • Later invocations with the same identifier restore the saved state so the assistant resumes the conversation seamlessly.
This pattern — shared state, checkpoint after each invocation, and restore by conversation identifier — forms the foundation for assistants that maintain continuity across sessions.

Watch Video

Practice Lab