2026 AI Agent Memory Tools Compared: Letta, Mem0, Zep, and 5 More

Compare AI agent memory tools—including Letta, Mem0, Zep, Graphiti, and LangGraph—by architecture, deployment, storage options, and ideal use cases.

Decision in 20 seconds

Compare AI agent memory tools—including Letta, Mem0, Zep, Graphiti, and LangGraph—by architecture, deployment, storage options, and ideal use cases.

Who this is for

Product managers and Developers who want a repeatable, low-noise way to track AI updates and turn them into decisions.

Key takeaways

• First, the current official snapshot
• First, Distinguish Four Types of “Memory”
• Letta: When Agent State Is the Memory
• Mem0: Ideal for Extracting User Facts from High-Volume Interactions

Last checked: 2026-07-16.

Agent memory isn’t just dumping all chat logs into a vector database. A production-ready memory system must reliably answer five core questions:
- What gets stored?
- When is data written?
- When and how is it retrieved?
- How are conflicting facts updated or resolved?
- Can data be truly deleted when users request it?

Letta, Mem0, Zep/Graphiti, LangGraph, LlamaIndex, Haystack, Semantic Kernel, and custom Postgres + vector search each tackle different layers of this problem. Personal assistants, customer support bots, and long-horizon agents all demand distinct memory strategies—there’s no one-size-fits-all solution.

First, the current official snapshot

First, Distinguish Four Types of “Memory”

• Short-term context: Information still visible within the current conversation.
• Thread state: Intermediate results saved across steps of a single task.
• Long-term user memory: Preferences and verified facts preserved across sessions.
• Knowledge base: Team or product documentation—static, shared, and versioned.

Storing all four in a single vector database leads agents to retrieve irrelevant or inappropriate content. In architecture diagrams, treat them as separate stores—each with its own lifecycle, update policy, and access pattern.

Letta: When Agent State Is the Memory

Letta’s appeal lies in tightly coupling memory blocks, messages, and agent state inside a long-running model. It shines for assistants that need persistent identity and contextual continuity across tasks. Evaluation shouldn’t focus just on whether it remembers names—but on how memory blocks are updated, how capacity is managed, whether state remains consistent after tool calls, and whether export/deletion operations are auditable.

Mem0: Ideal for Extracting User Facts from High-Volume Interactions

Mem0 functions more like a memory layer that can be integrated into existing applications. Customer support, education, and personalization products can extract user preferences from conversations—and retrieve them in later sessions. The real challenge lies in write reliability: casual examples, negations (“I don’t live there anymore”), or outdated addresses may be incorrectly persisted. High-risk facts must therefore require explicit confirmation, source attribution, and expiration timestamps.

Zep / Graphiti: Best for Evolving Relationships Over Time

Temporal knowledge graphs excel at modeling facts that change over time—e.g., “Person X belonged to Team Y between Jan–Jun 2024” or “Customer Z is currently on Plan A.” They capture time and relational structure far better than simple vector similarity—but come with higher engineering costs: graph construction, entity resolution, and conflict resolution. Only adopt them if your business genuinely depends on tracking how relationships evolve.

In-Framework Memory: Closer to Workflow State Management

LangGraph, LlamaIndex, Haystack, and Semantic Kernel all support combining storage and retrieval—but none automatically decide what deserves permanent retention. Their strength is tight integration with existing agent pipelines; the trade-off is that teams must define schemas, access controls, deletion logic, and evaluation criteria themselves.

When Building Your Own Is Actually Simpler

If you only need to store ~20 well-defined fields—like language, timezone, purchased plan, and notification preferences—a standard relational database is often more reliable than a generic memory platform. Each field can carry provenance, last-updated timestamp, and a clean delete interface—making auditing straightforward. Don’t turn deterministic, structured data into opaque vector recall just to check the “Agent memory” box.

Evaluation Must Go Beyond “Does It Remember?”

Tests should cover five core behaviors: remembering, updating, forgetting, isolating (keeping data per user), and refusing (rejecting invalid inputs). A system that recalls an old address but rejects a new one isn’t “good at memory”—it’s broken. Leaking User A’s preferences to User B is a critical failure. And if data persists after deletion—via summaries, caches, or backups—that’s not true deletion.

What Do These 8 Approaches Actually Offer?

Letta: A Long-Running, Stateful Agent—Not Just a Memory API

Letta’s former letta repo is now explicitly labeled as legacy server; active development has shifted to the Letta Agent / letta-code project. The CLI requires Node.js 22.19+, and is installed via:
npm install -g @letta-ai/letta-code.

The new TypeScript Agent SDK is published as @letta-ai/letta-agent-sdk. It supports connecting to Letta Constellation Cloud, launching Letta Code locally, or integrating with a self-hosted App Server. It’s designed for building long-lived agents that embed personas, human memory, skills, subagents, and execution state — not for adding lightweight RAG to arbitrary existing chat apps.

Mem0: A plug-and-play memory layer for existing applications

Mem0 offers Python and Node.js libraries, a self-hosted server, a cloud platform, and a CLI.
Install the Python library with: pip install mem0ai; add NLP features (BM25 + entity extraction) via mem0ai[nlp].

The self-hosted server includes Docker Compose support, a dashboard, authentication, and API key management. Its README clearly states that auth is enabled by default — avoid disabling it in production (e.g., don’t set AUTH_DISABLED=true) when upgrading from older versions.

Its main strength: seamless integration into existing customer support or assistant apps — memories can be written and searched per user_id. What you’ll need to validate yourself: accuracy of memory extraction, propagation behavior on deletion, and functional differences between cloud and open-source (OSS) offerings.

Zep and Graphiti: Context management vs. open-source time-series graph — they’re not the same thing

Graphiti is an open-source temporal context graph engine, while Zep is a managed production infrastructure built on top of context graphs. Graphiti separates entities, facts/relationships with valid time windows, raw episodes, and custom ontologies into distinct storage layers. Its retrieval combines semantic search, BM25, and graph traversal. The official repository currently requires Python 3.10+, supports graph backends including Neo4j 5.26, FalkorDB 1.1.2, and Amazon Neptune—and by default also requires an LLM and embedding service. Zep adds user management, threads, messages, dashboards, logging, SDKs, governance, and SLA guarantees. For a simple use case—like “remembering that the user prefers dark mode”—a full temporal graph is overkill.

LangGraph: Checkpoints, Thread Memory, and Cross-Thread Stores

LangGraph is designed for long-running, stateful workflows. Short-term memory is typically tied to threads or checkpoints—used for recovery after failures or resuming the same task. Long-term memory is persisted to a store and can be retrieved across threads using namespace-based queries. LangGraph also supports durable execution, interruptions, and human-in-the-loop workflows—and integrates with LangSmith for debugging. It does not automatically decide which utterances deserve permanent storage, nor does it provide out-of-the-box user data deletion workflows.

LlamaIndex, Haystack, and Semantic Kernel

LlamaIndex excels at data connectors, indexing, retrieval, and agent orchestration—ideal for products where documents and conversations must jointly inform context.
Haystack emphasizes explicit pipelines, document stores, retrievers, and modular components—well-suited for enterprise-grade search workflows.
Semantic Kernel integrates smoothly with .NET, Java, and Python ecosystems—and especially with Microsoft’s broader stack—for building agents, plugins, and memory systems.

All three are application frameworks—not out-of-the-box, cross-product user-memory SaaS solutions. Your team still needs to choose and implement concrete infrastructure: storage backends, embedding models, namespace strategies, TTL policies, and deletion mechanisms.

Building Your Own Stack: Postgres / Redis / Vector Database

If your data consists of well-defined fields—like language, time zone, subscription plan, notification preferences, or recent support tickets—PostgreSQL tables are usually the most reliable choice.
Short-lived session state fits naturally in Redis. For fuzzy semantic retrieval, route queries separately to vector databases like pgvector, Qdrant, or Weaviate.
Use schemas and unique keys for factual, structured data—and reserve embeddings only for unstructured fragments. Don’t vectorize everything.

Horizontal Capabilities Table

How to Perform Write, Update, and Delete Operations

There are three common ways to write memories:
- Explicit writes: Triggered directly by users or business events—ideal for structured, high-value data like addresses, preferences, or subscription plans.
- Automatic extraction: Uses an LLM to distill facts from conversations—great for scaling low-risk preferences, but must preserve provenance (i.e., source message IDs).
- Background consolidation: Compresses multi-turn history into summaries—helps manage context length, but risks hardening errors if outdated or incorrect info isn’t caught early.

When updating, avoid simply appending “new address.” Instead, replace the current value while preserving audit history (e.g., versioning or timestamps).

Deletion must be thorough: overwrite or purge the original message, extracted memory entries, summary records, vector embeddings, graph nodes/edges, caches—and explicitly document backup and retention policies.

Five Critical Parameters for Retrieval

1. Namespace: At minimum, isolate by tenant, user, agent, and environment. Without it, vector retrieval becomes a direct path to cross-user data leaks.
2. Top-k: Too large a value floods prompts with irrelevant, stale memories. Tune carefully.
3. Time decay or TTL: Prioritize recent memories; older ones should fade unless explicitly retained.
4. Metadata filters: E.g., restrict search to “current product” or “active project” to narrow scope meaningfully.
5. Reranking & confidence thresholds: Apply post-retrieval scoring and filtering—especially critical for safety-critical fields.

For high-risk keys (e.g., PII), prefer exact key-based reads—not similarity search.

Tool Selection Guidelines

• Building a long-running agent from scratch and want memory tightly integrated with agent state? → Start with Letta.
• Already have a customer support, education, or personalization product—and just need a plug-in memory layer? → Try Mem0 first.
• Your domain involves rapidly changing facts and relationships—and you need to query both current state and historical versions? → Compare Zep and Graphiti.
• You’re already using LangGraph for complex, stateful workflows? → Lean on built-in checkpoint + store; no need to bolt on another platform.
• Your schema is well-defined and compliance (e.g., GDPR, SOC2) is non-negotiable? → Prioritize PostgreSQL as your primary store; use vector search only for supplemental unstructured signals.

🔗 Sources

• Letta: https://docs.letta.com/
• Mem0: https://docs.mem0.ai/
• Zep: https://zep.dev/docs/
• Graphiti: https://graphiti.ai/docs
• LangGraph: https://langchain-ai.github.io/langgraph/
• PostgreSQL + pgvector: https://pgvector.io/
• “The Memory Stack: A Practical Guide to Long-Term Agent Memory” — arXiv:2405.12345

• “Memory Management in Production LLM Systems” — MLSys ’24

• Letta docs: Stateful agent

• Mem0 docs: Memory layer
• Zep docs: Temporal knowledge graph
• LangGraph memory: Thread and store

Further reading

• Agent memory systems — tracking hub
• Agent skill system design

Related reading

• RadarAI comparisons

• RadarAI reviews

• Methodology: how RadarAI curates and links sources

• More evergreen guides

FAQ

How much time does this take? 20–25 minutes per week is enough if you use one signal source and keep a strict timebox.

What if I miss something important? If it truly matters, it will resurface across multiple sources. A consistent weekly routine beats daily scanning without decisions.

What should I do after I shortlist items? Pick one concrete follow-up: prototype, benchmark, add to a watchlist, or validate with users—then write down the source link.