- 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
Overview of the approach
- Define a TypedDict for the shared conversation state.
- Create a node that reads the latest message, produces a reply, and updates state.
- Build and compile a
StateGraph, attaching a checkpointer. - Invoke the graph with a
thread_idto save state. - Re-invoke with the same
thread_idto resume the conversation. - 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: amessages list holding HumanMessage and AIMessage objects.
Step 2 — Create the chatbot node
This node inspects the latest message instate["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 aStateGraph, 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 aconfig 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 samethread_id. LangGraph will load the previously saved state automatically so the assistant “remembers” the prior conversation history.
Step 6 — Inspect the saved state
You can verify persistence by callingget_state with the same config (same thread_id). The saved state will include the full conversation history.
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.