LangGraph Checkpoints vs cognee Memory: What Each One Actually Stores

You set up a LangGraph agent. You add a checkpointer. You expect it to "remember" things between sessions, and then, mid-demo, the agent asks a user a question it was already answered two conversations ago. The checkpointer did not fail. It did exactly what it was designed to do. The confusion is architectural, not a bug. LangGraph checkpoints and cognee memory solve different problems, store different things, and are not substitutes for each other. This guide explains precisely what each one stores, where each one breaks down if used alone, and how most production stacks end up using both. It also answers the question teams almost always ask too late: do I actually need a separate memory layer if I'm already on LangGraph?

What Is Agent Persistence, and Why Does It Matter in 2026?

A context window is working memory. Persistent memory is a different system. Every LLM call is stateless by design, the model has no awareness of previous sessions unless something external injects that context back in. For single-turn tasks, that is fine. For agents that operate over hours, accumulate decisions, or serve the same user repeatedly, statelessness is a blocker. The 2026 production agent ecosystem has converged on a clear distinction: execution-state persistence (resuming a run) and knowledge persistence (recalling what was learned) are separate concerns that require separate infrastructure. Mixing them up is how teams ship agents that resume correctly but still forget everything meaningful.

What to Look for in a Persistence Layer for AI Agents

Before comparing tools, it is worth being precise about what "persistence" means in practice. Teams evaluating agent memory infrastructure should ask five questions for every candidate solution.

Key Properties of a Production-Grade Persistence Layer

• What does it actually store? Raw execution state (node outputs, message lists, intermediate flags) is not the same as extracted knowledge (entities, relationships, facts).
• How long does it persist, and across what boundary? Thread-scoped persistence dies when the thread ID changes. Cross-session persistence survives restarts, user re-engagement, and new conversation threads.
• How is it queried? Key-value lookup by thread ID is not the same as semantic search or graph traversal over structured knowledge.
• How does it scale, and at what cost? Checkpointing every superstep on a long-running agent generates significant storage volume. Knowledge graphs amortize retrieval cost over repeated queries.
• Is it queryable by any run, or only by the run that wrote it? Execution state is typically private to a thread. A semantic knowledge graph can be searched by any agent or any session that shares the namespace.

Cognee evaluates both its own architecture and the tools compared here against all five of these criteria. The honest answer is that no single tool satisfies all five simultaneously, which is why the architecture answer for most production stacks is "use both."

LangChain: The Orchestration Backbone

LangChain is the most widely adopted general-purpose framework for building LLM applications, with composable abstractions for chains, agents, retrievers, and memory. It provides the foundation on which LangGraph runs and the ecosystem within which LangMem operates. Understanding where LangChain's own memory story ends is important context for why the ecosystem built LangGraph, LangMem, and eventually reached for tools like cognee.

LangChain Key Features

• Broad ecosystem with integrations spanning most LLM providers, vector stores, and data connectors
• Chain-based and graph-based (via LangGraph) orchestration primitives
• LangSmith observability layer for tracing and debugging agent runs
• LangMem SDK for semantic, episodic, and procedural memory layered on top of LangGraph
• create_agent() shortcut that wraps LangGraph's state management, error handling, and streaming automatically

LangChain Use Cases, Best for

• Teams building their first production agent who want broad integrations and a large community
• Projects that need LangSmith observability from day one
• Teams that want a single vendor for orchestration, tracing, and memory (via LangMem) and are willing to accept the ecosystem coupling that comes with it

LangChain Pricing

LangChain OSS (including LangGraph and LangMem) is free and open source under MIT/MIT-adjacent licenses. LangSmith, the hosted observability product, has a free developer tier and paid plans for production usage. LangGraph Platform (the managed deployment layer) is a paid product.

LangChain's real strength is its breadth of integrations and its position as the de facto starting point for new agent projects. Its memory story across LangGraph and LangMem is credible for teams already in the ecosystem. The coupling, however, is real, teams outside the LangChain ecosystem will find LangMem in particular requires more integration work than the documentation implies.

LangMem: LangGraph's Native Long-Term Memory SDK

LangMem is an open-source Python SDK from LangChain that adds long-term memory capabilities to LangGraph agents. It provides tooling to extract important information from conversations, optimize agent behavior through prompt refinement, and maintain long-term memory. It covers three memory types drawn from cognitive science: semantic memory (stored facts and preferences), episodic memory (past interactions distilled into examples), and procedural memory (agents updating their own system prompt instructions based on feedback).

LangMem Key Features

• Three memory types: semantic, episodic, and procedural, each with distinct storage and retrieval semantics
• Background memory extraction that runs after conversations without blocking agent execution
• Memory consolidation to prevent unbounded growth by merging related memories and resolving contradictions
• Namespace scoping by user_id, team_id, or app_id to prevent cross-contamination between sessions
• Pluggable storage: any backend implementing the LangGraph BaseStore interface works, including Postgres and MongoDB

LangMem Use Cases, Best for

• LangGraph shops that want a drop-in memory layer without leaving the LangChain ecosystem
• Agents that need procedural memory, the ability to modify their own system prompt rules based on accumulated user feedback
• Teams that are already on LangGraph Platform, where long-term memory is available by default

LangMem Pricing

LangMem is free and open source. A managed memory service was announced alongside the SDK launch for teams that want hosted persistence without managing their own Postgres store.

LangMem is a credible choice for LangGraph-native teams. The SDK ships the memory type taxonomy well and procedural memory in particular is a genuine differentiator. Teams evaluating it for latency-sensitive production workloads should measure retrieval latency directly before committing, reported p95 figures from third-party evaluations have been high enough to warrant testing in context. LangMem also sits at version 0.0.x as of this writing, and teams should review release cadence before adopting it for regulated or high-availability production systems.

LangGraph Checkpoints: What They Actually Store

LangGraph is the leading standard for production-grade agent orchestration. It replaces implicit chains with explicit state graphs and gives teams strict control over agent workflows. The checkpointing system is one of its most important features, but it is widely misunderstood.

A LangGraph checkpointer serializes the full graph state after every node execution. That state is a TypedDict (or Pydantic model) that includes channel values, message history, intermediate tool outputs, retry counts, and any other fields the developer put in the state schema. Every field in state pays a serialization cost, a storage cost, and, critically, an LLM context budget cost when state fields are injected into prompts.

Checkpoints are organized by thread_id. A thread contains the accumulated state of a sequence of runs for a single conversation or task. When you resume a thread, LangGraph queries the database for the latest checkpoint matching that ID and reconstructs the agent's internal state from it. The agent picks up exactly where it left off. If a node fails mid-execution, LangGraph stores the partial writes from nodes that completed successfully, so on retry it does not re-run those nodes.

This is the right tool for the right job: resuming a run, recovering from a crash, supporting human-in-the-loop approval gates, and debugging via time travel replay. What it is not designed to do is answer the question "what has this agent learned across all its sessions with this user?", because checkpoints are scoped to a thread, and a new session means a new thread_id.

LangGraph Key Features

• Superstep checkpointing: Saves a snapshot of the full graph state after every node execution, keyed by thread_id
• Time travel and replay: checkpointer.list() exposes the full execution history; any prior checkpoint can be restored and re-executed from that point
• Fault-tolerant execution: Pending writes from successful nodes are preserved across failures, preventing redundant re-execution
• Human-in-the-loop support: interrupt_before and interrupt_after primitives pause execution at any node for human review or approval
• Pluggable backends: MemorySaver for local testing; SqliteSaver and PostgresSaver for production; the BaseCheckpointSaver interface allows custom backends
• Serialization protocol: The JsonPlusSerializer handles LangGraph and LangChain primitives, datetimes, enums, and more; state must be JSON-serializable

LangGraph Checkpointer Use Cases, Best for

• Long-running agents that may be interrupted and need to resume exactly where they left off
• Human-in-the-loop workflows where a human must review or approve a step before the agent continues
• Debugging and replaying production failures by restoring the exact state at the point of failure
• Multi-tenant applications where separate users or tasks must maintain isolated state

LangGraph Pricing

LangGraph OSS is free. LangGraph Platform (the managed, hosted version with Agent Server that handles checkpointing infrastructure automatically) is a paid service. Teams running LangGraph OSS in production are responsible for provisioning and maintaining their own checkpointer backend, typically PostgreSQL.

Does LangGraph Have Long-Term Memory?

This is where the terminology gets slippery. LangGraph provides two distinct persistence systems: checkpointers and stores. Checkpointers are thread-scoped, they do not survive a thread_id change. A returning user opening a new conversation has no access to facts stored in a previous thread's checkpoint. LangGraph's BaseStore addresses the cross-thread case: it persists application-defined data outside the graph state, namespaced by user identity rather than thread ID. This gives a returning user access to their stored preferences across sessions.

What neither primitive does natively is extract meaning from conversations, pulling out entities, building typed relationships, or enabling multi-hop reasoning over accumulated knowledge. That is the gap a semantic memory layer fills.

Cognee: The Open-Source Memory Platform for AI Agents

Cognee is the open-source memory platform for AI agents. Where LangGraph checkpoints serialize what a run did, cognee stores what an agent knows, extracted entities, typed relationships, and queryable knowledge organized into a persistent graph. The architectural distinction is precise: a checkpoint answers "what was the state of this execution?" A cognee memory layer answers "what facts, entities, and relationships has this agent accumulated, and what can I retrieve from them right now?"

Cognee's pipeline runs in three stages: Extract, Cognify, and Load. Raw data (text, files, URLs, conversation turns) comes in, gets chunked and entity-extracted via an LLM in the Cognify stage, and loads into a hybrid store combining a graph database, a vector index, and relational metadata. The resulting knowledge graph is not a log of what happened, it is a structured, queryable representation of what was learned. That graph survives session boundaries, process restarts, and thread ID changes. Any agent or any run that shares the namespace can query it.

Cognee's SDK volume has grown to more than 5 million runs per month as of Q3 2026, and the platform is running in production at more than 70 companies, including Bayer for scientific research workflows and Knowunity to connect 40,000 learners by proximity and needs.

Cognee Key Features

• Memory-native API (remember / recall / improve / forget): Four verbs that cover the full memory lifecycle. .remember ingests and Cognifies data into the knowledge graph. .recall queries it in natural language, automatically selecting the best retrieval strategy. .improve enriches existing memory and bridges session context into the permanent graph. .forget removes data at the item, dataset, or user level.
• ECL pipeline (Extract, Cognify, Load): The Cognify stage extracts typed entities and relationships using an LLM and loads them into a hybrid graph-vector-relational store. This is the step that converts flat text into structured knowledge.
• Hybrid retrieval (GraphRAG): Cognee ships 14 retrieval modes, from classic similarity search to chain-of-thought graph traversal. Vector similarity finds candidate nodes; graph traversal extracts relational context around them. Hybrid architectures combining both consistently outperform either alone on multi-hop questions.
• Cross-session persistence: The knowledge graph survives application restarts and accumulates across the full lifetime of a deployment. Any new session for the same user picks up the same graph without re-ingestion.
• Framework portability via MCP: The same cognee knowledge graph is queryable by LangGraph agents, Claude Code, Cursor, OpenAI Agents SDK, and any other MCP-compatible runtime. Teams are not locked into a single agent framework.
• Poly-store backend flexibility: Graph storage via Neo4j, FalkorDB, KuzuDB, or NetworkX; vector storage via Redis, Qdrant, Weaviate, or LanceDB; relational metadata via SQLite or Postgres. Cognee 1.0 also runs the full stack on a single Postgres instance, eliminating the need for separate graph database and vector store deployments.
• Multi-tenant isolation: User and tenant scoping ensures memory from one user does not contaminate retrieval for another. Supported across backends including pgvector, Neo4j, Kuzu, and LanceDB.

Cognee Differentiators

• Memory vs. knowledge distinction: A flat memory store records what was said. Cognee captures what it means, typed entities and relationships, not just similar chunks. This is the structural difference that enables multi-hop reasoning across sources rather than nearest-neighbor retrieval.
• Self-improving memory via .improve: The .improve operation enriches existing memory, bridges session context into the permanent graph, and applies feedback-based weighting. Memory is not a passive log; it evolves.
• Framework-agnostic via MCP: LangMem is designed for the LangGraph ecosystem. Cognee's knowledge graph is reachable from any MCP-compatible framework, so teams are not committed to a single orchestration stack.
• Benchmark-backed correctness on multi-hop queries: Cognee reported 79% on the BEAM memory benchmark at a 100k-token context window (against a reported state of the art of 73.4%) and 67% at 10 million tokens (against 64.1%), using only default open-source features without benchmark-specific architecture. These are cognee's own reported results; gains are consistent but not uniform across all datasets and benchmarks, and teams evaluating the platform should review the benchmark methodology directly.

Benefits of Using Cognee

• Agents recall past work, decisions, and fixes instead of relearning them every run
• Multi-hop questions across sources get structurally correct answers, not just the nearest chunk
• The same knowledge graph can be queried by multiple agent frameworks simultaneously
• Deployment is flexible: run fully locally with embedded SQLite, LanceDB, and KuzuDB backends with no cloud dependency, or on Cognee Cloud when managed scale is needed
• Apache 2.0 license, free for personal and commercial use with no vendor lock-in

How Real Teams Use Cognee, Best for

• Coding agents that recall past debugging work: An agent that has diagnosed a sync bug once can search cognee's knowledge graph for that entity the next time it surfaces, rather than re-diagnosing from scratch. Each run creates a node in the graph connected to the skill, the task, and any errors that resulted.
• Long-running research agents: Bayer uses Cognee to power scientific research workflows where facts and relationships accumulate across many sessions and need to be retrievable with provenance attached.
• Multi-agent pipelines with shared knowledge: In a multi-agent pipeline, individual agents can read from a shared cognee graph while maintaining their own write scope, no cross-contamination, no redundant re-ingestion.
• Compliance-sensitive deployments: Teams in regulated industries run cognee fully on-premise with local embedding models via Ollama, satisfying GDPR and EU AI Act requirements with no cloud dependency. Cognee's Berlin base and EU AI Act awareness make this a real deployment story.
• LangGraph agents that need semantic memory: LangGraph agents add cognee as a tool via LangGraph's standard tool-calling interface and get sessionized memory with semantic search. No custom orchestration required.

Cognee Pricing

• Free: $0, 1 workspace, 1M tokens included, unlimited users and API calls, agentic integrations. No card required.
• Standard: $1.00 per 1M tokens processed, plus $5 per additional workspace. Includes data source integrations and in-app support.
• Enterprise: Dedicated support engineer and Slack channel, BYO cloud, SLAs.

The pricing model is transparent and token-based, teams pay for what they process, not for seats or feature tiers. There is no vendor lock-in on infrastructure: the open-source package is Apache 2.0 and runs locally for free. Cognee Cloud is for teams that want managed scale, not a requirement to use the product.

The honest caveat: not every agent needs a knowledge graph. Single-turn chatbots, static FAQ bots, and small stable document sets do not benefit meaningfully from the Cognify pipeline. Cognee's own documentation acknowledges this. Structured memory pays for itself on systems that accumulate state, reason across sources, or track what changed over time.

LangGraph Checkpoints vs cognee Memory: Feature Comparison

The table below is a side-by-side view of the architectural differences between LangGraph checkpoints and cognee memory. Understanding this table is the core answer to "do I need a memory layer if I already use LangGraph?" The two systems are complementary, not competing, they store different things, persist across different boundaries, and answer different questions.

This table frames the architectural decision clearly: LangGraph checkpoints are the right tool for execution continuity. Cognee's memory layer is the right tool for knowledge continuity. Most production agent stacks that accumulate meaningful state over time will eventually need both.

Using Cognee and LangGraph Together

Cognee provides sessionized memory tools that LangGraph agents use through LangGraph's standard tool-calling interface, no custom orchestration required. The pattern is: compile your LangGraph graph with a checkpointer for execution state, and attach cognee memory tools to your agent's tool list for semantic knowledge persistence. Below is a working example of both layers used together.

from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.postgres import PostgresSaver
from langgraph_cognee import get_sessionized_cognee_tools

# Checkpointer handles execution state: resume, replay, fault tolerance
checkpointer = PostgresSaver.from_conn_string("postgresql://user:pass@localhost/db")

# cognee tools handle semantic knowledge: what the agent knows across sessions
add_tool, search_tool = get_sessionized_cognee_tools()  # remember / recall under the hood

agent = create_react_agent(
    "openai:gpt-4o-mini",
    tools=[add_tool, search_tool],
    checkpointer=checkpointer,
)

# First session: the agent encounters a bug and stores the fix
config = {"configurable": {"thread_id": "session-001"}}
agent.invoke(
    {"messages": [{"role": "user", "content": "Customer 9132 hit a sync error. Maya fixed it 2025-11-03 by disabling retry on the batch writer."}]},
    config=config,
)

# Second session: new thread_id, so the checkpoint is gone, but cognee knowledge persists
config2 = {"configurable": {"thread_id": "session-002"}}
agent.invoke(
    {"messages": [{"role": "user", "content": "Customer 9132 is reporting an error again. What do we know?"}]},
    config=config2,
)
# The agent calls search_tool, finds the entity in cognee's knowledge graph,
# and returns Maya's fix without re-diagnosing from scratch.

For a complete walkthrough of setup, session management configuration, and cross-session persistence testing, see the full cognee LangGraph integration guide.

Do I Need a Memory Layer if I Already Use LangGraph?

The direct answer is: it depends on what your agent needs to persist. If the requirement is resuming a specific run after a failure, supporting a human approval gate mid-execution, or debugging a production incident by replaying state, LangGraph checkpoints handle all of that well. No additional memory layer is needed for those use cases.

If the requirement is that an agent accumulates knowledge across multiple sessions, recalls facts a different thread established, reasons across entities from multiple sources, or serves a returning user with context from a previous conversation under a different thread_id, a checkpointer alone is insufficient. LangGraph's own documentation confirms this: checkpointers are for in-thread state, and a BaseStore (or an external memory layer) is required for cross-thread knowledge. The BaseStore handles flat key-value facts well. The gap it leaves is semantic structure, the ability to traverse typed relationships, perform multi-hop reasoning, and retrieve knowledge that was inferred rather than explicitly stored.

That gap is where cognee adds value. LangGraph agents add cognee as a tool and get sessionized memory with semantic search without rebuilding their orchestration. The two systems work in parallel: the checkpointer manages execution continuity, and cognee's knowledge graph manages knowledge continuity. Neither replaces the other.

Related guides

• LangGraph × cognee: Enhancing Agents with Persistent, Queryable Memory
• LangChain Memory Explained: Short-Term vs Long-Term, LangGraph Persistence, and LangMem
• Agent State vs Agent Memory: How Long-Running Agents Resume in 2026
• Best Memory Tooling for AI Coding Agents: A Developer Guide (2026)
• cognee on BEAM: SOTA Results Without a Benchmark-Specific Memory System

FAQs: LangGraph Checkpoints vs cognee Memory

Why Is cognee the Best Memory Layer for LangGraph Agents?+

cognee is not the only memory layer compatible with LangGraph, LangMem is the ecosystem-native option and a reasonable choice for teams already committed to the LangChain platform. cognee's advantage is structural: it extracts typed entities and relationships via the Cognify pipeline and stores them in a queryable knowledge graph, rather than flat key-value facts. On multi-hop benchmarks like BEAM, cognee's graph-plus-vector architecture consistently outperforms flat retrieval, though gains are not uniform across all datasets. For agents that need to reason across entities from multiple sessions and sources, cognee's architecture is worth the added ingestion cost.

Why Should I Choose cognee Over LangMem?+

LangMem is a strong fit if your team is fully on LangGraph and LangGraph Platform. The coupling is intentional and it reduces integration friction. cognee makes sense when your agent stack is not fully LangGraph-native, when you need the same knowledge graph accessible from Claude Code, Cursor, or other MCP-compatible frameworks, or when multi-hop retrieval quality is a requirement. Cognee's framework-agnostic deployment via MCP means teams are not locked into a single orchestration vendor. Its Apache 2.0 license and self-hosted deployment options also matter for teams with GDPR or on-prem requirements.

Does cognee Support the Same Memory Types as LangMem?+

cognee covers semantic memory (facts and relationships as structured graph nodes) and episodic memory (past interactions stored and retrievable as session context) natively. LangMem's procedural memory type, which allows agents to update their own system prompt rules based on feedback, is distinct and worth noting as a LangMem-specific capability. Cognee's .improve operation refines and enriches the knowledge graph over time, which achieves a different form of self-improvement: the graph schema and entity weights evolve rather than the system prompt. Teams that specifically need procedural prompt-update behavior will want to evaluate LangMem's implementation directly.

Is There Support for Adding cognee to an Existing LangGraph Stack?+

cognee's LangGraph integration uses LangGraph's standard tool-calling interface. The core memory integration can be completed in fewer than 10 lines of code, and no custom orchestration is required. Cognee defaults require no external infrastructure for local development, pip install and an LLM API key are sufficient to start persisting agent memory. For teams migrating from LangMem, the conceptual model is similar: both expose a store interface that agents query via tools. The cognee LangGraph integration guide covers session management configuration, cross-session persistence testing, and the full setup walkthrough.

What Are the Best Persistence Approaches for Long-Running Agents in 2026?+

Long-running agents in 2026 typically need both layers: an execution-state layer for resumability and fault tolerance, and a knowledge-persistence layer for semantic memory across sessions. LangGraph checkpoints with a PostgreSQL backend handle the first. A graph-based memory layer handles the second. For agents that accumulate meaningful state over time, multi-session research agents, coding agents that recall past fixes, customer-facing agents that personalize over time, the architecture that works is LangGraph checkpoints for the run layer and cognee's knowledge graph for the memory layer. cognee running in production at more than 70 companies at more than 5 million SDK runs per month reflects that this combination is viable at scale.

When Does an Agent Not Need a Separate Memory Layer?+

Not every agent needs a knowledge graph. Single-turn agents, static FAQ assistants, and agents working over a small stable document set do not benefit meaningfully from the Cognify pipeline's ingestion cost. If an agent's entire knowledge base fits comfortably in a context window, and that knowledge does not change between sessions, a memory layer is overhead rather than infrastructure. The signal that a memory layer is worth adding is accumulation: the agent is expected to know more tomorrow than it knew today, to serve users differently based on their history, or to reason across facts that were established in different sessions.