The best open-source memory layer for LLM agents depends on what you need memory to do: simple key-value recall (Mem0), self-managing agent state (Letta), temporal knowledge graphs (Graphiti / Zep), graph+vector cognitive architecture (Cognee), framework-native integration (LangMem), or human-readable cross-tool memory over MCP (PLUR). All six are open source, all give your agent persistent storage outside the model, and they differ in storage format, retrieval model, portability, and how much of the memory the agent manages itself. There is no single best — there is a best for your use case, and picking wrong means either over-engineering (adopting an agent OS when you needed a key-value store) or under-engineering (a flat vector store when you needed temporal reasoning).
Every LLM call is stateless. The model has no memory of yesterday’s conversation, last week’s coding preferences, or the architecture decision from the sprint planning session. Wang et al. identify memory as the foundation for “self-evolving capability” in agents — without it, an agent does not improve with use (arXiv:2404.13501). You pay to re-teach the same context every session, in tokens and in time.
A memory layer fixes this by capturing what the agent learns, storing it outside the model, and recalling the right piece at the right time. The question is which one — because the storage format, retrieval model, and portability constraints of your choice determine what you can do later.
Not every memory tool that calls itself open source meets the same bar. Three properties matter:
License: An OSI-approved license (MIT, Apache-2.0) means you can inspect, modify, and self-host without vendor permission. All six projects below meet this bar. Note: Mem0, Letta, Cognee, Graphiti, and PLUR are Apache-2.0; LangMem is MIT.
Inspectable storage: The memory format is something you can read, edit, and audit — not opaque embeddings locked in a vector database you cannot open. This is where the projects diverge most: some store memory as plain text you can open in a text editor, others as vector embeddings you can only query through an API.
No mandatory cloud: You can run the full memory layer on your own infrastructure without a hosted service. Some projects offer cloud as an option; others require it for full functionality.
Mem0 (github.com/mem0ai/mem0, ~63K stars, Apache-2.0) is the most widely adopted open-source memory layer. It provides a simple CRUD API — add(), update(), delete(), search() — that drops into any agent with minimal integration. As of April 2026, Mem0 switched to a single-pass ADD-only extraction algorithm: memories accumulate without UPDATE/DELETE, with entity linking and hybrid retrieval (semantic + BM25 keyword + entity matching). The April 2026 algorithm scores 92.5 on LoCoMo and 94.4 on LongMemEval on the managed platform (Mem0’s README notes open-source SDK results are directionally similar but not identical) (github.com/mem0ai/mem0).
Best for: Agents that need persistent memory with the lowest-friction integration. If you have an existing agent and want to add memory in an afternoon, Mem0 is the simplest path.
Storage format: Vector embeddings in a backend of your choice (Qdrant, Chroma, PostgreSQL with pgvector). Memories are opaque — you query them through the API, not by reading a file.
Portability: SDKs for Python and TypeScript. Plugins for Claude Code, Codex, Cursor, and OpenClaw. Memory is locked to Mem0’s format — migrating away means re-extracting.
Open-source bar: Apache-2.0, fully self-hostable via Docker. Cloud platform available but not required.
Letta (github.com/letta-ai/letta, ~24K stars, Apache-2.0), formerly MemGPT, is not just a memory layer — it is an agent operating system where the agent manages its own memory in tiers. Core memory is always in context; archival memory is paged in on demand. The agent can edit its own memory blocks during a conversation. Letta has moved active development to the Letta Agent SDK and Letta Code CLI, with the legacy server repository in maintenance (github.com/letta-ai/letta).
Best for: Long-running, stateful agents that need to manage their own context — deciding what to keep in working memory and what to archive.
Storage format: Agent state blocks (editable text) plus archival storage. More inspectable than vector-only approaches — the agent’s core memory is text you can read.
Portability: Tightly coupled to the Letta agent runtime. Memory does not transfer to agents built on other frameworks.
Open-source bar: Apache-2.0, self-hostable. Cloud option (Constellation) available.
Graphiti (github.com/getzep/graphiti, ~30K stars, Apache-2.0) is a framework for building and querying temporal context graphs — knowledge graphs where each fact has a validity window (when it became true, when it was superseded). Unlike static knowledge graphs, Graphiti tracks how facts change over time and supports hybrid retrieval: semantic search, keyword matching, and graph traversal. Graphiti powers Zep’s managed platform but is usable standalone. It has an MCP server for Claude, Cursor, and other MCP clients (github.com/getzep/graphiti).
Best for: Agents that need to reason about when facts were learned and how they change — customer profiles that evolve, inventory that shifts, policies that update. If “what is true now” and “what was true last month” are both questions your agent must answer, Graphiti is the fit.
Storage format: Graph nodes (entities) and edges (facts with temporal validity windows), backed by FalkorDB or Neo4j. Provenance is preserved — every fact traces back to the episode (raw data) that produced it.
Portability: MCP server available. Graph format is not directly interchangeable with vector-based systems.
Open-source bar: Apache-2.0, fully self-hostable. Zep Cloud is the managed version.
Cognee (github.com/topoteretes/cognee, ~30K stars, Apache-2.0) is an open-source AI memory platform that combines vector embeddings, graph reasoning, and cognitive-science-grounded ontology generation. You ingest data in any format and Cognee builds a self-hosted knowledge graph that gives agents persistent long-term memory. The API is four operations: remember, recall, forget, and improve. Cognee supports multiple vector backends (including Turso/libSQL as of July 2026), has an MCP server, and ships plugins for OpenClaw and Claude Code (github.com/topoteretes/cognee).
Best for: Teams that want a knowledge graph approach with ontology grounding — structured memory where relationships between concepts are first-class, not just similarity scores.
Storage format: Knowledge graph with vector embeddings, ontology types defined via Pydantic models. More structured than Mem0’s flat vectors, less temporal than Graphiti.
Portability: MCP server, OpenClaw plugin, Claude Code plugin, Rust client, TypeScript client. Multiple entry points but the graph format is Cognee-specific.
Open-source bar: Apache-2.0, fully self-hostable. Cloud option available.
LangMem (github.com/langchain-ai/langmem, ~1.6K stars, MIT) is LangChain’s memory library, designed for agents built on LangGraph. It provides memory management tools the agent can call during conversations (store and search in the “hot path”), plus a background memory manager that automatically extracts, consolidates, and updates knowledge. LangMem integrates natively with LangGraph’s Long-term Memory Store, available by default in LangGraph Platform deployments (github.com/langchain-ai/langmem).
Best for: Agents already built on LangChain / LangGraph. If your stack is LangGraph, LangMem is the zero-friction choice — it uses the storage layer you already have.
Storage format: Any storage system (the API is storage-agnostic), with native integration to LangGraph’s BaseStore (in-memory for dev, Postgres-backed for production).
Portability: Tightly coupled to the LangChain ecosystem. Memory tools use LangGraph’s store abstraction — not portable to agents on other frameworks.
Open-source bar: MIT. Storage backends depend on what you configure.
PLUR (github.com/plur-ai/plur, ~233 stars, Apache-2.0) is a local-first memory layer that stores knowledge as plain-text engrams — YAML files on your disk that you can read, edit, and delete with any text editor. Memory is shared across MCP-compatible tools: Claude Code, Hermes, OpenClaw, Cursor, and any tool that speaks MCP. The core differentiator is storage format: instead of opaque vector embeddings, PLUR stores engrams as structured YAML with metadata (domain, scope, confidence, last-verified timestamp). Retrieval is hybrid — BM25 keyword search plus optional vector embeddings — and runs locally with zero API calls. PLUR reports 98.0% recall at R@5 on LongMemEval-S (N=500, fully local, BGE-reranker-v2-m3 cross-encoder) (github.com/plur-ai/plur).
Best for: Developers who want memory they can inspect, correct, and delete at the file level — and who work across multiple agent tools. If you use Claude Code for one project and Cursor for another and want the same memory in both, PLUR’s cross-tool MCP architecture is the differentiator.
Storage format: Plain-text YAML engrams on local disk. Human-readable, human-editable, auditable. This is the core architectural choice — memory as text files, not vectors.
Portability: MCP-native (works with any MCP client). Adapters for LangChain, Hermes, OpenClaw. Python SDK. One storage format across all tools.
Open-source bar: Apache-2.0, fully self-hostable, local-first by design. No cloud required — memory lives on your disk.
| If you need… | Choose… | Why |
|---|---|---|
| The simplest drop-in memory API | Mem0 | Four CRUD calls, minimal integration, most adopted |
| An agent that manages its own memory | Letta | Tiered memory the agent edits during conversations |
| Time-aware knowledge (“what’s true now vs then”) | Graphiti | Temporal validity windows on every fact |
| Structured knowledge graph with ontology | Cognee | Graph + vector + ontology generation |
| Memory inside a LangGraph agent | LangMem | Native LangGraph store integration |
| Human-readable, cross-tool memory over MCP | PLUR | Plain-text YAML engrams, local-first, works across tools |
| Temporal knowledge graph as a managed service | Zep (Graphiti’s cloud) | Graphiti engine, production scale, sub-200ms retrieval |
Storage format is the lock-in, not the license. Every project here is open source under an OSI-approved license. But once your agent has accumulated 10,000 memories in Mem0’s vector format or Letta’s state blocks or Graphiti’s graph, migrating to another format means re-extracting and re-importing everything. The storage format you choose today is the one you will live with. Choose based on whether you need opaque-but-fast (vectors), readable-and-editable (text), structured-and-relational (graph), or temporal-and-versioned (temporal graph).
Retrieval model determines what questions your agent can answer. Semantic similarity (Mem0, PLUR, Cognee), tier-based paging (Letta), graph traversal (Graphiti), or hybrid keyword+semantic (Mem0’s April 2026 algorithm, PLUR, Cognee). If your agent needs to answer “what changed since last week?” you need temporal retrieval, not just similarity. If it needs to answer “what does the agent know about X?” similarity is sufficient.
Portability determines whether memory survives a tool change. Framework-native memory (LangMem, Letta) does not transfer if you switch frameworks. MCP-native memory (Mem0’s MCP support, PLUR, Graphiti’s MCP server, Cognee’s MCP server) works across any MCP-compatible tool — but the storage format is still tool-specific. The only way to avoid format lock-in entirely is an open, portable memory specification — which does not yet exist as an industry standard, though the engram spec (github.com/plur-ai/plur) is one proposal seeking adoption.
Is Mem0 the best open-source memory layer? Mem0 is the most adopted (~63K stars) and the simplest to integrate. Its managed platform scores 92.5 on LoCoMo (open-source SDK results are directionally similar). But “best” depends on use case: if you need temporal reasoning, Graphiti is better; if you need human-readable storage, PLUR is better; if you need an agent OS, Letta is better. Mem0 is the safest default for simple use cases.
Can I use multiple memory layers together? Yes. A common pattern is Mem0 or PLUR for simple fact storage plus Graphiti for temporal reasoning. The MCP protocol (specification 2025-11-25, modelcontextprotocol.io) allows an agent to connect to multiple memory servers simultaneously.
What is the difference between a memory layer and a vector database? A vector database stores embeddings and returns similar vectors. A memory layer adds semantics: what to store (extraction), when to retrieve (injection), how to forget (decay), and how to resolve contradictions. Wang et al. describe memory as comprising “memory formation, retrieval, refinement, and utilization” — a vector database handles only storage (arXiv:2404.13501).
Is local-first memory as good as cloud memory? Local-first memory (PLUR, self-hosted Mem0, self-hosted Cognee) gives you data sovereignty and zero API costs. Cloud memory (Zep, Mem0 Cloud, Cognee Cloud) gives you managed infrastructure and scale. The retrieval quality depends on the algorithm and embeddings, not where the server runs. PLUR’s local-first hybrid search achieves 98.0% recall (R@5, BGE-reranker-v2-m3, LongMemEval-S N=500) — competitive with cloud options on the same benchmark.