LangGraph state is a typed Python or TypeScript object, a TypedDict with named slots like messages, documents, plan, tool_results, user_profile. Each slot has its own reducer that decides how new values merge in (append for messages, replace for plan, custom for documents). Checkpointing serializes the whole state at every node, enabling pause/resume, time-travel, and human in the loop. A plain conversation buffer is just an ordered list, you cannot ask 'what was the plan three steps ago?' without parsing it. LangGraph state makes context engineering a first-class data-modeling exercise.
A **plain conversation buffer** is an ordered list of messages: user turn, assistant turn, tool call, tool result, repeat. To find anything specific (the agent's plan, a particular tool result, a user profile field), you parse the list and hope the model formatted it consistently.
**LangGraph state** is a typed object instead. The developer defines the shape up front:
```python
class AgentState(TypedDict):
messages: Annotated[list[BaseMessage], add_messages]
plan: str
tool_results: list[ToolResult]
user_profile: UserProfile
summary: str
```
Each slot is named, typed, and has its own **reducer**, a small function that says how a new value merges into the slot. The `messages` slot has an append reducer. The `plan` slot has a replace reducer. A custom slot like `tool_results` might dedupe by ID.
Three things flow from this design.
First, **slot access is direct**. Asking 'what is the current plan' is a dictionary lookup, not a parsing exercise. You always know where each piece of agent memory lives.
Second, **checkpointing is automatic**. Every node execution serializes the whole state to a checkpointer (Postgres, Redis, SQLite). The trajectory can pause, the process can die, and the next run resumes from the last checkpoint with the full state intact.
Third, **human in the loop becomes clean**. The graph can interrupt at any node, surface the typed state to a reviewer, and resume after the reviewer modifies a slot. The interrupt is durable because the state is on disk.
LangChain's older memory classes (`ConversationBufferMemory`, `ConversationSummaryMemory`) operate on flat message lists with limited structure. They work for simple chat but break down when an agent needs more than just the conversation history.
**LangGraph state** is the typed, slot-based, reducer-governed alternative to LangChain's older conversation-buffer pattern, and the difference is structural rather than cosmetic.
A plain conversation buffer is an **ordered list of messages**: user, assistant, tool call, tool result. The buffer is opaque to anything that is not a message. If the agent has a current plan, it lives inside an assistant message as prose. If there is a running summary, it is appended as a system message. To answer 'what was the plan three nodes ago?' you parse the message list and hope the model formatted things consistently.
LangGraph state is a **typed object with named slots**. The developer defines the shape as a `TypedDict` or Pydantic model, naming each piece of state the agent needs to track: `messages`, `plan`, `tool_results`, `user_profile`, `documents`, `summary`. Each slot has its own **reducer**, a function `(old, new) -> merged` that defines how updates flow in. The `messages` slot uses the built-in `add_messages` reducer (append, dedup by ID). The `plan` slot uses replace. A `documents` slot might dedupe by URL or content hash.
Three capabilities flow from this design.
**First, structural access.** The plan is `state['plan']`, not a search through the message list. Nodes that update the plan write `{plan: new_plan}` and the reducer applies the update. The data model is explicit, which means context engineering becomes a data-modeling exercise, what slots does this agent need, what reducer governs each, rather than a prose-prompting exercise.
**Second, checkpointing.** The whole state is serialized after every node to a checkpointer backend. This enables pause and resume across process restarts, durable human in the loop interruption (the human can take minutes or weeks to respond and the state survives), and time-travel debugging (every checkpoint is a stable artifact the engineer can replay or fork).
**Third, parallel and conditional flow.** Because state is
Quick reference
TL;DR
LangGraph state is a typed object with named slots, per-slot reducers, and checkpointing at every node, turning agent memory into a first-class data model instead of an opaque conversation buffer.
Think of two ways to track a long project. The first is one big notebook where you write everything in order, meetings, decisions, todo lists, file references, all jumbled together. To find the latest decision you flip through pages and hope. The second is a binder with labeled tabs: Plan, Decisions, Open Questions, Files. Each tab has its own rule for what gets added. To find the latest decision you flip straight to that tab. The binder is what LangGraph state gives you. The notebook is what a plain conversation buffer gives you. Both work for short projects. Only one scales to long ones.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-turn assistants with no trajectory across calls Typed state, reducers, and checkpointing are overhead when there is no multi-step trajectory to model. A simple function call is enough.
Latency-critical paths where the per-node serialization adds tens of milliseconds Each checkpoint costs real wall-clock to write. For sub-second user-facing assistants this can eat the latency budget. Use an in-memory checkpointer or skip checkpointing for those paths.
Cross-session long-term memory that needs to survive for months or years The checkpointer is sized for trajectory replay, not for years of user history. Use a dedicated long-term memory framework (Mem0, Letta, Zep) for that store and keep LangGraph state focused on the current trajectory.
Quick scan · 2–4 min
Everything important, quickly.
Compare the plain conversation buffer (ordered message list) with the LangGraph state (typed object with named slots and reducers). Walk through the three capabilities that flow from the design: structural access to specific pieces of memory, checkpointing for durability and human in the loop, and safe parallel or conditional node execution. Close with the architectural rule: LangGraph state for the current trajectory, a separate long-term memory framework for cross-session history.
Real-world examples
Real products, models, and research that use this idea.
1LangGraph's MessagesState is the canonical 2026 working-memory shape for chat plus tools agents
2LangGraph Cloud uses checkpointed state as the foundation of its managed agent runtime
3Anthropic's Claude agent SDK exposes a similar typed-state model with thread-level persistence
4CrewAI flows in 2026 borrow the slot plus reducer pattern from LangGraph for their state objects
5LangSmith uses checkpoint IDs as clickable artifacts in its trace UI for time-travel debugging
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you design the state schema for a multi-step research agent?
Sign in or go Pro to see the approach for this follow-up.
QWhat changes when you need to share state across multiple agents in a graph?
Sign in or go Pro to see the approach for this follow-up.
QWhen is the checkpointer cost not worth paying?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating LangGraph state as just a fancier message list, missing that the typed slots and reducers are what enable checkpointing, time-travel debugging, and clean human in the loop interruption.