LangGraph Agent Memory: Short-Term State, Long-Term Knowledge, and a Production Test

LangGraph agent memory is really two persistence problems. A checkpointer saves the state of one conversation thread; a store keeps application-defined knowledge available across threads. Treating both as “chat history” creates expensive prompts, stale facts, and memory that nobody can safely correct.

For project decisions and operational knowledge, there is a useful third layer: files your agents and humans can read, edit, diff, and self-host—not only embeddings behind a retrieval API. Meshnote exposes a markdown wiki through MCP, so a LangGraph application and other MCP-compatible tools can share the same durable knowledge without making one agent framework the owner of it.

The LangGraph memory model in one minute

LangGraph’s current documentation draws a clean boundary. Checkpointers persist graph-state snapshots under a thread_id. They support conversation continuity, fault recovery, human approval, and time travel. Stores hold key-value documents under custom namespaces. They support preferences, facts, and shared knowledge across threads.

That distinction matters operationally. A transcript belongs in thread state. “Customer prefers email” belongs in a user namespace. “Production deploys require a database-ready health check” is team knowledge and should have a canonical, reviewable home. The MCP memory server guide explains how a protocol boundary lets several agents use that final layer.

Layer	Scope	Good examples	Common mistake
LangGraph checkpointer	One thread	Messages, pending tool calls, workflow state	Keeping unbounded transcripts
LangGraph store	User, agent, or application namespace	Preferences, compact facts, learned examples	Using weak tenant keys or never deleting conflicts
Readable shared memory	Project or team	Decisions, runbooks, architecture, source-backed research	Writing every conversational detail

A runnable cross-thread memory example

This minimal program uses no model or API key. It proves the property developers often assume but do not test: a LangGraph store can return a value in a different thread because the namespace—not thread_id—defines its long-term scope.

uv run --with langgraph python langgraph_memory.py

from dataclasses import dataclass
from typing import TypedDict

from langgraph.graph import START, StateGraph
from langgraph.runtime import Runtime
from langgraph.store.memory import InMemoryStore

class State(TypedDict):
    action: str
    key: str
    value: str
    result: str

@dataclass
class Context:
    user_id: str

def memory_node(state: State, runtime: Runtime[Context]):
    namespace = ("users", runtime.context.user_id, "preferences")
    if state["action"] == "put":
        runtime.store.put(namespace, state["key"], {"text": state["value"]})
        return {"result": "saved"}

    item = runtime.store.get(namespace, state["key"])
    return {"result": item.value["text"] if item else "missing"}

builder = StateGraph(State, context_schema=Context)
builder.add_node("memory", memory_node)
builder.add_edge(START, "memory")
graph = builder.compile(store=InMemoryStore())

base = {"key": "editor", "value": "Neovim", "result": ""}
graph.invoke(
    {**base, "action": "put"},
    {"configurable": {"thread_id": "thread-a"}},
    context=Context(user_id="u-42"),
)
result = graph.invoke(
    {**base, "action": "get"},
    {"configurable": {"thread_id": "thread-b"}},
    context=Context(user_id="u-42"),
)
assert result["result"] == "Neovim"
print(result["result"])

The output is Neovim. InMemoryStore disappears on restart, so it is only appropriate for tests. LangGraph’s production guide recommends a database-backed store and checkpointer; its Postgres examples also require running setup() once. Keep thread_id under 255 characters for PostgresSaver, and define retention because checkpoints otherwise accumulate.

Where retrieval belongs

LangGraph’s store can index documents for semantic search, but not every memory needs embeddings. Exact identifiers, typed profiles, and current configuration are often safer as structured reads. Semantic retrieval is valuable when wording varies and the corpus is large. A readable wiki is valuable when the answer must be inspectable, linked to sources, and deliberately revised.

The practical architecture is hybrid: retrieve a small set of candidate facts, then load the canonical page for consequential work. This separates finding from authority. It also gives a human somewhere obvious to repair a false memory. See the self-hosted agent memory comparison for privacy, portability, and operational trade-offs.

LangGraph memory versus Mem0, Zep, Letta, and native memory

Option	Best fit	Real trade-off
LangGraph store + checkpointer	Custom workflows already built in LangGraph	Flexible primitives, but your application owns extraction, conflicts, retention, and evaluation
Mem0	Pluggable personalized memory with broad integrations	Convenient extraction and retrieval; canonical facts are usually managed through memory APIs
Zep / Graphiti	Relationships and facts that change over time	Temporal graphs answer rich “what was true when?” questions, with more infrastructure and modeling
Letta	Stateful agents that actively manage their context	Memory is integrated with the agent runtime rather than just added as a passive store
ChatGPT or Claude native memory	Personal assistant continuity with minimal setup	Easy for one product, less suitable as shared application infrastructure across tools
Markdown over MCP	Reviewed project knowledge shared by agents and humans	Portable and auditable, but not a substitute for high-volume automatic personalization

These choices are composable. Mem0’s LangGraph guide, for example, retrieves user memories before a model call and stores the interaction afterward. Letta reported in August 2025 that a filesystem-based agent using GPT-4o mini reached 74.0% on LoCoMo. That is one vendor’s experiment—not a universal product ranking—but it supports an important point: tool-use strategy and context management can matter as much as the storage mechanism. The Mem0 vs Zep comparison goes deeper on extracted memories versus temporal graphs.

The production acceptance test the tutorials omit

A demo that remembers a favorite color is not a memory evaluation. Before shipping, run these six cases against the complete agent, prompt, tools, and storage:

Cross-thread recall: write in thread A and retrieve in thread B for the same user.
Tenant isolation: repeat the query as a second user and require zero leakage.
Conflict: change “deploy Friday” to “deploy Thursday” and verify the current answer wins without erasing history.
Provenance: ask where a consequential fact came from; require a source or an explicit “unknown.”
Deletion: remove a preference, then confirm exact, semantic, cached, and backup behavior matches your policy.
Restart and restore: restart the process, corrupt one test memory, and prove an operator can recover it.

Also record latency, tokens added to the prompt, false recalls, and operator repair time. Public retrieval benchmarks such as LoCoMo measure useful capabilities, but they do not prove your namespace isolation, deletion semantics, or recovery procedure.

A sensible default architecture

Use a persistent LangGraph checkpointer for resumable execution. Put compact user-specific facts in a store with explicit namespace rules. Keep authoritative team knowledge in source control, issue trackers, and a readable memory layer. Retrieve only what the current step needs, and never let an old conversational summary silently overrule a current runbook.

Meshnote is designed for that shared readable layer: a markdown wiki agents maintain through MCP while humans retain direct access to the files. Start syncing — $8/mo, or choose Self-hosted for teams from $10/seat/month with a five-seat minimum.

Teams deciding whether to keep LangGraph and add a memory layer or adopt a stateful runtime can use the Mem0 vs Letta architecture and exit drill.