Best AI Agent Memory 2026: Mem0 vs Letta vs Zep vs Cognee

TL;DR + decision tree

• If you want the fastest path from zero to working memory on an existing agent — five lines of Python, hosted or self-hosted, with a clean SDK — pick Mem0. It’s a memory layer, not a framework. Drop it in.
• If memory is the architecture — you want stateful agents you address as services, each with a self-edited core scratchpad plus a giant archival store — pick Letta. The MemGPT lineage makes the memory hierarchy the framework’s reason to exist.
• If your agent is conversational and the value is “remember what was true about this user as of last Tuesday” — chronological recall, fact extraction, temporal validity — pick Zep. The temporal knowledge graph (Graphiti underneath) is the product.
• If your memory problem is shaped like a graph — documents, entities, relationships, codebases, organisation charts — pick Cognee. It’s closer to graph-RAG than to chat memory, and the remember / recall / forget / improve pipeline reflects that.

These four overlap less than the marketing surfaces suggest. Mem0 and Zep both call themselves “memory for AI agents,” but Mem0 optimises for stable user-preference recall while Zep optimises for chronologically correct fact lookup. Letta and Mem0 both let you persist agent state, but Letta hosts the agent itself while Mem0 is a library you call from your own runtime. Cognee shares an Apache 2.0 license and a Python-first SDK with all three but lives closer to Neo4j + LLM than to a memory layer in the chat sense. Read the architectures section before you write any code — the wrong choice early costs a refactor that’s harder than picking a database.

What “agent memory” actually means

The word “memory” gets stretched to cover at least five different things in agent-land. Separate them before comparing frameworks — most arguments about which is best are really arguments about which kind of memory matters for the problem at hand.

Short-term / context-window memory is what the model already has: the prompt plus the last N turns. No framework solves this; it’s a property of the model and the orchestration layer. Token budget, attention degradation, and per-call cost are all in play. Everything below is about externalising state so the model doesn’t hold it all in context every turn.

Long-term / persistent memory is the generic name for anything written to a store that survives between sessions. All four frameworks here are solutions for it; they differ in what they think long-term memory should contain.

Episodic memory records specific things that happened — “on Tuesday the user said the checkout flow was broken, on Wednesday support marked it resolved.” Zep is the framework most obviously designed for this shape: every fact has a valid_at and invalid_at timestamp so you can ask “was this true on Wednesday morning?” without the model hallucinating. Mem0 stores facts but doesn’t index them temporally as a first-class concern; Letta approximates episodic recall through archival search.

Semantic memory is timeless factual knowledge — “the user prefers metric units,” “HQ is in Amsterdam.” Mem0’s sweet spot. The April 2026 algorithm update reported 91.6 on LoCoMo (a long-conversation recall benchmark), so the team is optimising hard for this shape. Letta’s core-memory blocks are primarily semantic too — facts the agent has learned and edits as the relationship evolves.

Procedural memory — “how to do something” — is the least well-served by any of the four. You’ll mostly handle it yourself by storing tool-call sequences or successful workflows. Letta gets closest, since an agent can self-edit a memory block titled “how I solve refund disputes” and the next session inherits it.

Cognee sits across all of these by being a graph layer rather than a memory layer in the chat sense. Primitives are nodes, edges, and the cognify pipeline that builds them from unstructured input. If your “memory” is really “a corpus of documents the agent traverses by relationship,” Cognee fits even though the chat-memory vocabulary barely applies.

Three memory architectures

Strip the surface APIs and the four frameworks reduce to three architectural patterns. Knowing which matches your workload is more useful than any benchmark.

Architecture 1 — vector index + extraction (Mem0)

The cleanest vector-first pattern. New messages arrive, an extraction step pulls out atomic facts, each fact gets embedded and stored with structured metadata (user_id, agent_id, session, timestamp). Retrieval fuses semantic similarity, BM25, and entity match into one ranked list. Mental model: structured notes with a vector index for fuzzy lookup. Strengths: simple API, fast lookup, low token overhead, easy to bolt onto any agent. Weaknesses: weak at modelling relationships between facts (graph is implicit in metadata), and chronology is just another metadata field, not a first-class temporal index.

Architecture 2 — tiered context with self-edit (Letta)

Letta inherits its memory model from MemGPT, which first treated the LLM context window as a tiered cache. The agent has a small core memory — a few hundred tokens of structured blocks the agent reads and writes itself via tool calls — and a much larger archival memory outside the context window, paged in via search. Older turns get summarised and pushed down the hierarchy. The framework manages page-in/page-out for you. Strengths: the agent feels genuinely stateful — it remembers what you told it last month because it wrote that fact into a core block. Weaknesses: opinionated runtime (you live in Letta’s server model), and the core-memory budget is a hard design constraint.

Architecture 3a — temporal knowledge graph (Zep)

Zep, powered by Graphiti, treats every message as a source of facts about entities and relationships, and every fact as a chronologically scoped edge in a knowledge graph. The validity window — valid_at and invalid_at — is the key innovation. If the user said “I work at Acme” in March and “I left Acme” in July, the graph encodes both with non-overlapping validity; a query in August retrieves the second. Strengths: chronological correctness over long horizons, automatic entity/fact extraction, sub-200ms lookups per Zep’s benchmark page. Weaknesses: graph backend (Neo4j-class) is real operational overhead, and the extraction pipeline burns LLM credits on high-volume conversations.

Architecture 3b — full knowledge graph from anything (Cognee)

Cognee shares the graph orientation with Zep but isn’t chat-shaped. It ingests arbitrary content — documents, code, emails, structured records — through a cognify pipeline that produces a knowledge graph plus embeddings. The recall step routes queries to whichever search strategy fits (graph traversal, semantic, keyword, hybrid). Strengths: best fit when your memory problem is really knowledge management; broadest backend flexibility (Neo4j, Kuzu, NetworkX, multiple vector stores). Weaknesses: heavier conceptual model — you think about the graph you’re building, not just call memory.add. Wrong tool for “remember the user’s favourite colour.”

Three quick litmus tests: if the question is “what does this user prefer,” vector + extraction wins (Mem0). If it’s “what was true at time T, given a moving conversation,” temporal graph wins (Zep). If it’s “how do entities in my corpus connect,” full graph wins (Cognee). If it’s “I want the agent itself to feel durable,” tiered runtime wins (Letta).

Side-by-side matrix

Every cell pulled from the official repo, docs, or pricing page. Snapshot taken 2026-05-11; pricing and feature surfaces drift, so confirm at the source before committing.

Three takeaways. First, every framework here is Apache 2.0 — licensing is not a tiebreaker. Second, only Letta includes an agent runtime; the other three are libraries you call from yours, which matters for orchestration choices. Third, only Zep and Cognee ship first-class knowledge-graph indexes; Mem0 and Letta can model relationships through metadata but won’t outperform a proper graph engine on multi-hop traversal.

Mem0 — install + recipe

Mem0mem0ai

Official1-Click Ready

Official Mem0 MCP server. Give AI assistants persistent memory — store, retrieve, and semantically search user preferenc

ai ml8.5k409

What it does best

Mem0 is right when you already have an agent and want it to remember things between sessions without rebuilding around a memory layer. The API is the shortest in this comparison: memory.add(messages, user_id=...) writes, memory.search(query, user_id=...) reads. Behind that surface is multi-signal retrieval fusion — semantic + BM25 + entity match scored in parallel — which the April 2026 algorithm update reports at 91.6 on the LoCoMo benchmark with 6.7-6.9K token overhead per retrieval. Headline strength is API minimalism plus a real free tier on the hosted product.

Pick this if you...

• Have an existing agent (LangChain, LlamaIndex, custom loop) and want to bolt on memory in under an hour
• Want a free hosted entry point (10k memories / 1k retrievals on the Hobby plan) before deciding whether to self-host
• Care most about semantic memory — stable user preferences, recent facts — and less about chronologically correct fact lookup
• Need MCP-first access from agents in Cursor, Claude Code, or Claude Desktop — Mem0 has an official MCP server already in this directory

Recipe: add memory to an existing agent in five lines

# pip install mem0ai
from mem0 import Memory

memory = Memory()

# Write
memory.add(
    [{"role": "user", "content": "I prefer metric units and bullet points."}],
    user_id="alex",
)

# Read
results = memory.search(
    query="What does Alex prefer?",
    user_id="alex",
    limit=5,
)
for r in results["results"]:
    print(r["memory"])

That’s the whole loop. In your agent’s pre-prompt, run memory.search with the current user query and prepend the top-k memories to the system message. Post-turn, pipe the last few messages into memory.add. Mem0 handles extraction, deduplication, and fact merging so the store doesn’t grow linearly with conversation length.

Skip it if...

Your problem is chronological correctness across a long conversation graph — Zep’s temporal validity windows are a structural advantage Mem0 doesn’t match. Or your memory is really a document graph — Cognee or Zep’s Graphiti will give you multi-hop traversal Mem0 has to approximate through repeated lookups. Mem0’s sweet spot is “remember what this user prefers,” not “reason across a thousand documents.”

Letta — install + recipe

What it does best

Letta is the only framework here where memory defines the architecture rather than supplementing it. Inheriting from MemGPT, it gives every agent a small core memory (a few hundred tokens of structured blocks the agent reads and writes itself via tool calls) and a much larger archival memory the agent searches for older context. The Letta server hosts agents as addressable services: create once, stable identity, every interaction picks up where the last left off. Headline strength is durable agent personality — a user returns three weeks later and the agent still knows their name, preferences, and open threads, no system-prompt stitching required.

Pick this if you...

• Want a stateful agent runtime rather than a stateless agent plus a memory library
• Are building multi-agent systems where each agent needs a persistent identity (support agent, research agent, scheduling agent — each with its own evolving core memory)
• Trust the agent to self-edit its core memory blocks rather than wanting deterministic write paths
• Are coming from the LangGraph / CrewAI / AutoGen world and want an opinionated alternative — see our LangGraph vs CrewAI vs Letta vs AutoGen comparison

Recipe: create a persistent agent with core memory

# pip install letta-client
from letta_client import Letta

client = Letta(token="YOUR_TOKEN")  # or self-hosted base_url

# Create a stateful agent once
agent_state = client.agents.create(
    model="openai/gpt-5.2",
    embedding="openai/text-embedding-3-small",
    memory_blocks=[
        {"label": "human", "value": "Name: Alex. Prefers metric units."},
        {"label": "persona", "value": "I am a research assistant."},
    ],
    tools=["web_search", "fetch_webpage"],
)

# Subsequent calls reuse the same agent — memory persists
response = client.agents.messages.create(
    agent_id=agent_state.id,
    messages=[{"role": "user", "content": "Remember I'm moving to Berlin."}],
)

# Agent self-edits core memory via tool calls; archival memory
# absorbs the rest. Pick the agent_id back up next session.

The agent itself can call core_memory_replace and archival_memory_insert as tools during its turn, which is the MemGPT-style self-management. You don’t write to memory directly; you trust the agent to do it. Some teams find that liberating; others find it unpredictable. Try both before committing.

Skip it if...

You already have an orchestration framework (LangGraph, CrewAI, your own loop) and don’t want a second runtime. Letta is opinionated; sliding it under an existing framework is more friction than picking Mem0 as a pure memory library. Also skip it if you need precise control over what gets remembered and forgotten — Letta’s self-editing model trades determinism for emergence.

Zep — install + recipe

What it does best

Zep is right when your agent is conversational and chronological correctness matters. Every message pushed runs through a pipeline that extracts entities and facts, links them into a graph, and attaches a temporal validity window to each fact. The Graphiti engine underneath is open-source and usable without Zep Cloud. Headline strength is the question nothing else in this comparison answers cleanly: “what was true about this user as of last Tuesday afternoon?” For customer success, longitudinal coaching, mental-health support, or any domain where conversational context drifts across weeks, the temporal index is structural, not cosmetic.

Pick this if you...

• Build conversational agents that talk to the same user across days, weeks, or months
• Need facts to expire automatically when newer facts contradict them (the user changed jobs, moved cities, switched preferences)
• Want the Graphiti graph engine without writing graph code — the Zep SDK abstracts node/edge creation behind a message-shaped API
• Are comfortable running a graph backend (Neo4j-class) or paying for Zep Cloud’s managed graph

Recipe: chat memory with temporal facts

# pip install zep-cloud
from zep_cloud.client import Zep
from zep_cloud.types import Message

zep = Zep(api_key="YOUR_KEY")

user_id = "alex"
session_id = "alex-session-001"

zep.user.add(user_id=user_id, email="[email protected]")
zep.memory.add_session(session_id=session_id, user_id=user_id)

# Push conversation — facts get extracted into the temporal graph
zep.memory.add(
    session_id=session_id,
    messages=[
        Message(role="user", content="I just moved from Amsterdam to Berlin."),
        Message(role="assistant", content="Got it — Berlin now."),
    ],
)

# Retrieve a memory bundle scoped to the session
memory = zep.memory.get(session_id=session_id)
print(memory.context)  # facts + relevant prior summaries

# Query the temporal graph directly
results = zep.graph.search(
    user_id=user_id,
    query="Where does Alex live?",
    scope="edges",  # ranked facts
)
for r in results.edges:
    print(r.fact, r.valid_at, r.invalid_at)

If next month Alex says “I moved to Lisbon,” Zep writes a new fact-edge with the new valid_at and retracts the Berlin edge by setting its invalid_at. A query in August naturally returns Lisbon. Mem0 can model this with metadata; Zep makes it the primary index.

Skip it if...

Your agent doesn’t actually talk to the same user repeatedly, or your memory problem is shaped like a document corpus rather than a conversation log. Zep’s strengths are wasted on stateless agents. Also skip if you want minimal infrastructure — the graph backend is a real operational commitment compared to Mem0’s pgvector / Qdrant story. Zep Cloud’s free plan (1,000 credits/mo) is the easiest way to try the temporal model without standing up Neo4j.

Cognee — install + recipe

What it does best

Cognee is right when your “memory” is really a knowledge-management problem. Feed it documents, code, emails, structured records, transcripts — anything textual — and the cognify pipeline produces a knowledge graph: entities as nodes, relationships as edges, embeddings for fuzzy lookup. Recall auto-routes queries to whichever search strategy fits. Cognee’s strongest relative claim is backend flexibility — adapters for multiple graph stores (Neo4j, Kuzu, NetworkX) and multiple vector stores, so you assemble the stack you already trust.

Pick this if you...

• Have a corpus of documents, transcripts, or structured data the agent needs to reason across — not just conversations to remember
• Need multi-hop graph traversal (“which people on the Atlas project also worked on Helios”) rather than nearest-neighbour over chunks
• Want to bring your own graph backend (already running Neo4j? already happy with Kuzu?) without buying into a hosted product
• Are comfortable thinking in graph terms — entities, edges, schemas — rather than “just add a memory.”

Recipe: ingest documents into a knowledge graph

# pip install cognee
import cognee
import asyncio

async def main():
    # Ingest unstructured input — Cognee handles chunking, entity
    # extraction, edge creation, and embedding under the hood
    await cognee.add(
        "Atlas was a 2024 project led by Alex. "
        "Helios followed in 2025 with the same core team."
    )

    # Build the graph from what's been added
    await cognee.cognify()

    # Recall — auto-routes between graph traversal, semantic, hybrid
    results = await cognee.search(
        query_text="Which projects has Alex led?",
        query_type="GRAPH_COMPLETION",
    )
    for r in results:
        print(r)

asyncio.run(main())

The cognify call is doing the heavy lifting: extracting entities, inferring relationships, and writing them to your chosen graph backend. search with a query type lets you switch between graph completion, semantic recall, or summarisation depending on what the agent needs. The same pipeline ingests Markdown, PDFs, raw text, or programmatic input through the same add surface.

Skip it if...

Your problem is “remember what this user said yesterday” — that’s Mem0 or Zep, not Cognee. The graph machinery is unnecessary overhead for chat-shaped memory, and you’ll spend more time thinking about schemas than benefiting from them. Pick Cognee when entities and relationships are first-class concerns, not when you wish they were.

Pick your shape: when memory ≠ vector DB

Before picking any of these four, ask whether you even need a memory framework or whether a vector database would do. Full head-to-head is in our Chroma vs Pinecone vs Qdrant vs Weaviate vs pgvector comparison. Short version: a raw vector DB is right when your agent only needs nearest-neighbour lookup over arbitrary chunks — no extraction, no dedup, no forgetting, no temporal correctness. “Here’s 50,000 documents, return the five most similar.”

Memory frameworks earn their keep when you need at least one of four hard problems solved beyond similarity. Fact extraction: turn multi-turn conversation into atomic facts so you don’t store “I’m a vegetarian,” “I don’t eat meat,” and “no animal products please” as three items. Merging / dedup: consolidate when the user repeats a fact with variation. Forgetting: when newer contradicts older (“I moved to Berlin” → “I moved to Lisbon”), the older fact loses primacy. Query routing: pick latest fact, chronological history, summary, or entity graph per query.

Mem0 solves all four for the chat-preference shape. Letta gives the agent self-edit tools and lets it figure out what to remember. Zep solves them with temporal validity. Cognee solves them by promoting entities and relationships to first-class citizens. A vector DB solves none of them. If you find yourself reinventing extraction or forgetting on top of a vector DB, you’re building a worse version of the framework you didn’t pick. Buy, don’t build.

One more axis: where does memory live in your stack? Mem0 and Cognee are libraries you call from orchestration code. Zep is a separate service your orchestration layer queries. Letta replaces the orchestration layer with its own server. Stack compatibility isn’t neutral — picking Letta means picking out of the LangGraph world; picking Mem0 means staying in it. See our LangGraph vs CrewAI vs Letta vs AutoGen comparison for the orchestration side.

Common pitfalls

Community signal

The agent-memory space matured through 2025 — MemGPT renamed to Letta, Zep doubled down on Graphiti, Mem0 shipped multi-signal retrieval fusion in April 2026, Cognee published research on the LLM-graph interface. That’s a younger conversation than the docs-RAG space, and the verbatim discourse is thinner than for tools like Context7 or DeepWiki. We won’t fabricate quotes.

Two patterns are consistent across GitHub discussions, vendor blogs, and conference talks. First, “just use a vector DB” is fading; teams shipping long-running agents pick a memory framework because the four hard problems hit them within weeks of go-live. Second, nobody uses two of these in production simultaneously — running both Mem0 and Zep means owning two extraction pipelines and two retrieval surfaces, doubling latency, cost, and ambiguity. Pick one, commit, revisit in a quarter.

Fastest signal you can collect yourself: clone each project, run its quickstart against a real transcript from your product, measure time-to-first-useful recall, token cost per turn, and behaviour on fact retraction. The framework that wins on your transcripts is the framework that wins.

Frequently asked questions

Sources

Mem0

• github.com/mem0ai/mem0 — Apache 2.0 Python SDK, README, install instructions
• docs.mem0.ai — API reference, self-host docs, integration guides
• mem0.ai/pricing — Hobby / Starter / Growth / Pro tiers and limits
• /servers/mem0 — Mem0 MCP server install card on this directory

Letta

• github.com/letta-ai/letta — Apache 2.0 agent runtime (formerly cpacker/MemGPT)
• docs.letta.com — concepts, memory blocks, SDK reference
• arxiv.org/abs/2310.08560 — original MemGPT paper (core / archival memory model)

Zep

• github.com/getzep/zep — Apache 2.0 memory store + Graphiti graph engine
• help.getzep.com — full documentation, SDK reference, schema model
• getzep.com/pricing — Free / Flex / Flex Plus / Enterprise tiers
• github.com/getzep/graphiti — underlying temporal-graph engine, open-source

Cognee

• github.com/topoteretes/cognee — Apache 2.0 knowledge-graph memory framework
• docs.cognee.ai — pipelines, adapters, SDK reference

Related comparisons

• /blog/chroma-vs-pinecone-vs-qdrant-vs-weaviate-vs-pgvector-mcp-2026 — when a raw vector DB is the right answer
• /blog/langgraph-vs-crewai-vs-letta-vs-autogen-2026 — orchestration framework comparison (includes Letta)
• /blog/goose-vs-cline-vs-aider-vs-claude-code-vs-opencode-2026 — coding-agent shootout

Internal links

• /servers/mem0
• /blog/what-is-mcp — protocol primer
• /best-mcp-servers — curated roundup
• /servers — browse the full catalog