compare

LangGraph memory, explained, and the layer it leaves open

Checkpointers and the Store API handle execution state and app-scoped memory. A file layer makes that knowledge portable.

How LangGraph handles memory

A checkpointer saves the full graph state after every node execution. LangGraph ships MemorySaver for development, SqliteSaver for local persistence, and PostgresSaver for production. Each checkpoint is scoped to a thread. The checkpointer records every superstep, so you can rewind, replay, or resume from any point.

The Store gives your graph cross-thread key-value memory. Three core methods cover most use cases: store.put(namespace, key, value) to write, store.get(namespace, key) to read, and store.search(namespace) to list or query.

You wire both primitives at compile time: graph = builder.compile(checkpointer=checkpointer, store=store). The checkpointer tracks execution history. The Store holds durable facts. Conversation history is structural and automatic. Long-term memory is a product decision, coded explicitly with put and get calls in your nodes.

What this design does well

Resumable graphs. A crashed or paused graph resumes from its last checkpoint.
Time travel. Rewind to any previous superstep. Replay from a specific checkpoint to debug or branch.
Per-thread isolation. Each conversation thread has its own checkpoint stream.
Production backends. Postgres, Redis, MongoDB, and SQLite are all supported.

For execution state and app-scoped memory, this design is solid. LangGraph agents can remember user preferences, resume after failures, and accumulate knowledge across threads through the Store.

The gap

Both checkpointers and the Store live inside the LangGraph runtime. Only code that runs inside your LangGraph app can access them.

Your coding assistant (Claude Code, Cursor, Copilot) cannot read what the LangGraph agent learned.
Scripts in other frameworks cannot query the Store without importing LangGraph.
Inspection means querying checkpoint blobs or Store keys through the SDK.
The memory is tied to the LangGraph runtime. If you move to a different framework, the knowledge does not follow.

This is not a flaw. Checkpointers and the Store are designed for the LangGraph execution model. The gap is at the boundary: when knowledge needs to travel beyond a single app.

Plain-file state as the cross-tool layer

The pattern: keep checkpointers for execution state. Put durable knowledge in files served over MCP. Learnings, decisions, project context, runbooks. Things that matter beyond a single thread or a single app.

separation of concerns

Checkpointers own execution state: "where is this graph run right now?" The Store owns app-scoped memory: "what has this app learned?" Files own shared knowledge: "what does the team (human and AI) know?"

Each layer does one thing. They compose without replacing each other.

Comparison

	LangGraph checkpointer	LangGraph Store	gcontext files
Scope	Per-thread	Cross-thread	Cross-tool
Write path	Automatic	SDK call	File write
Inspection	Query API	Query API	Open in editor
Cross-framework	No	No	Yes, any MCP client
Search	By thread ID	By namespace + key	`grep` or `list_dir`
Best for	Execution state	App-scoped memory	Shared knowledge

Using them together

A LangGraph node can read and write files in the gcontext folder directly (if co-located) or through MCP tool calls. The checkpointer still tracks execution state. The Store still holds app-scoped data. The file layer adds a place for knowledge that other tools need too.

The node reads accumulated learnings before it acts. It writes new learnings back after it finishes. The next session (LangGraph, Claude Code, or any other tool) starts with everything the previous sessions discovered.

langgraph node

# conceptual -- a LangGraph node that reads gcontext state

from pathlib import Path

STATE_DIR = Path("./my-agent-state/modules/project")

def review_with_context(state):
    """Read learnings before acting, write new ones back."""
    learnings = (STATE_DIR / "learnings.md").read_text()
    # ... use learnings in the prompt ...
    result = call_llm(state["messages"], context=learnings)
    if result.new_learnings:
        with open(STATE_DIR / "learnings.md", "a") as f:
            f.write(result.new_learnings)
    return {"messages": [result.response]}

Questions

Does LangGraph have long-term memory?

Yes. The Store API provides cross-thread key-value memory. Checkpointers persist per-thread execution state. Both require a LangGraph app to access.

What is the difference between a checkpointer and the Store?

Checkpointers save graph execution state per thread. They enable resume and time travel. The Store holds arbitrary key-value data across threads, like user preferences or learned facts.