Mem0 (agent memory API)

What it is and how it works

Mem0 is a memory layer that sits between an LLM application and its storage backend, giving agents persistent, queryable memory across sessions instead of relying purely on a context window that resets every conversation. The core idea is straightforward: instead of stuffing an entire chat history into every prompt, Mem0 extracts salient facts from conversations (using an LLM call to summarize and structure what matters), stores those facts as embeddings in a vector database, and retrieves only the relevant subset on each new turn via similarity search. This keeps prompt sizes bounded while letting an agent "remember" user preferences, past decisions, and long-running context indefinitely.

The distinguishing architectural feature is the dual-mode memory system. The standard mode is vector-only: facts get embedded and stored, then retrieved by nearest-neighbor search, which is the same pattern used by most RAG-style memory add-ons. The second mode, referred to as Mem0g or graph memory, layers a directed labeled knowledge graph on top of the vector store. Extracted facts become nodes and relationships (entities, attributes, and the edges connecting them), which lets the system answer multi-hop queries that pure vector similarity handles poorly — questions like "what did the user say about their manager's opinion on the project they mentioned two months ago" require traversing relationships, not just finding semantically similar text. The graph layer also does conflict detection: when new information contradicts a previously stored fact, Mem0 attempts to reconcile or flag it rather than silently duplicating stale data, which is a real pain point in naive vector-memory systems that just keep appending.

Mem0 is model-agnostic on both ends — it works with any LLM for the extraction/reasoning step (including local models run through Ollama) and is not tied to a specific vector database, supporting common backends operators already run in their stack. This makes it fundamentally a middleware/library concern rather than a standalone service you point traffic at, though the managed cloud offering wraps this into a hosted API.

Deployment patterns

For a solo developer or small project, Mem0 is typically installed as a Python (or JS) package directly inside the agent application, pointed at a local or lightweight cloud vector store (Chroma, Qdrant, or similar), with an existing LLM client — including a local Ollama endpoint — supplying the extraction calls. This is genuinely a "minutes to integrate" setup: wrap your existing chat loop with add() calls after each exchange and search() calls before generating a response, and you have working persistent memory without standing up new infrastructure. This pattern suits prototypes, personal assistants, and single-user agent projects where the LLM inference and the memory extraction can both run on the same machine.

For homelab or small-team setups, the natural evolution is running a dedicated vector database (Qdrant or a managed pgvector instance) alongside the application, with Mem0 configured against it, so multiple agent instances or services share a common memory store keyed by user/agent IDs. Graph memory in this configuration adds real cost: every fact extraction that populates the graph is an additional LLM call, so teams running Mem0g at scale on local models need to budget inference throughput accordingly, or route the extraction step to a cheaper/faster model than the one handling actual conversation.

For production or multi-tenant workloads, most teams move to the managed Mem0 cloud tier rather than self-hosting the full pipeline, since the OSS library's self-hosted path leaves you responsible for vector DB scaling, embedding cost management, and graph store operations. This is explicitly one of the tool's honest tradeoffs — the OSS core is free and functional, but production-scale multi-user deployments lean on the hosted service for the operational parts Mem0 doesn't try to solve itself.

How it compares

Against Letta (formerly MemGPT), the comparison is architecture-of-control versus speed-of-integration. Letta takes an OS-like approach, giving developers explicit control over memory tiers (core context, archival storage, recall) and how the agent manages its own memory through defined function calls — more configurable, but with a steeper integration path. Mem0 trades that explicit control for a drop-in API that requires far less design work up front, at the cost of being more of a black box about exactly what gets extracted and stored.

Against LangChain's memory modules (ConversationBufferMemory, VectorStoreRetrieverMemory, etc.), Mem0 is a more opinionated, purpose-built product rather than a grab-bag of composable primitives inside a larger framework. LangChain's memory tools are flexible and free if you're already in that ecosystem, but require more manual wiring to get fact extraction, deduplication, and conflict handling — behaviors Mem0 provides out of the box.

Against a raw RAG-over-vector-DB approach (just embedding chat logs into Pinecone/Qdrant/Chroma directly), Mem0 adds real value in the extraction and structuring step — deciding what's worth remembering, deduplicating, and (in graph mode) modeling relationships — rather than leaving you to dump raw transcripts and hope similarity search finds the right fragment. The cost is an extra LLM call per turn for extraction, which a bare vector-DB approach avoids.

Best use cases and honest limitations

Mem0 fits well for teams building conversational agents, personal assistants, or customer-support bots that need to remember user-specific facts across sessions without hand-rolling extraction and retrieval logic. The local-LLM compatibility makes it a reasonable choice for privacy-conscious or offline-first agent projects built on Ollama, since the memory layer itself doesn't require a cloud dependency at the OSS tier. Its benchmark performance on multi-hop question answering makes the graph variant particularly relevant for agents that need to reason over accumulated history rather than just retrieve recent facts.

It's a weaker fit for teams that want fine-grained, explicit control over what enters memory and how it's tiered — Letta's more deliberate architecture serves that need better. It's also not the right choice if you're allergic to the recurring LLM-call cost of extraction, especially with graph memory enabled, since every stored interaction implies additional inference spend on top of the primary conversation. And despite the free OSS core, honest operators should plan for the managed cloud tier once they need production-scale multi-tenant memory, since the self-hosted path doesn't include the operational tooling that scale requires.

Install via pip: pip install mem0ai. Requires Python 3.10+. Mem0 is a memory layer for LLM applications — it stores, retrieves, and updates personalized user memories without building the agent infrastructure yourself. Quick start: from mem0 import Memory; m = Memory(); m.add("I like pizza and live in New York", user_id="alice"); results = m.search("Where does Alice live?", user_id="alice"). The Memory class auto-configures with an in-memory vector store for development. For production: set MEM0_API_KEY to use the managed cloud service, or configure a local vector store (Qdrant, Chroma) in config.yaml. Mem0 auto-extracts memories from conversation messages: messages = [{"role": "user", "content": "I'm a vegetarian"}, {"role": "assistant", "content": "Got it, I'll remember that"}]; m.add(messages, user_id="alice") — it extracts the vegetarian preference automatically. Serve as a REST API: from mem0 import Memory; from fastapi import FastAPI wrap endpoints around m.add(), m.search(), m.get_all(). First run: ~30 seconds for package install and model download (default: all-MiniLM-L6-v2 for embeddings, GPT-4o-mini for memory extraction). Verify: run the search example above — it returns relevant memories. Time-to-first-memory: ~5 seconds including embedding computation.

Best for: adding user-level memory to LLM chatbots and applications without building memory infrastructure, personalization features where the LLM should remember user preferences across sessions, customer support bots that recall user history and context, AI companions that learn about the user over time, any application where "the chat should remember what the user said last week" is a product requirement. Not suited for: document-level RAG over files and databases (use LlamaIndex), full autonomous agents with memory-driven behavior (use Letta), applications requiring memory without API call overhead for extraction (build direct vector store + embedding integration), strict data sovereignty requirements (default extraction model is OpenAI-hosted), applications where memory should be graph-structured rather than text-embedded.

Use Mem0 when you need memory as a service — add user_id to your API calls and Mem0 handles storage, retrieval, deduplication, and memory update without you building a memory infrastructure. It's the lightest way to add user-level memory to any LLM application. Switch to Letta when you need a full agent framework with memory as one component — Letta's OS-inspired memory paging is more sophisticated but more opinionated. Use Zep for an alternative memory service with built-in conversation summarization and graph memory. Use LlamaIndex when memory is for document retrieval (RAG) not user preferences — Mem0 is user-centric memory, LlamaIndex is document-centric. Build your own memory layer with a vector DB when you need maximum control and minimal dependency. Mem0's strength: the extraction LLM automatically identifies what's worth remembering from conversations — you don't write memory extraction logic. Its weakness: the extraction model uses an API call (OpenAI by default), adding latency and cost to every .add() call.

Problem: Memory().add() hangs or fails silently. Fix: Mem0's default .add() sends messages to OpenAI for memory extraction (defaults to gpt-4o-mini). If OPENAI_API_KEY is not set, the call fails silently — set export OPENAI_API_KEY=sk-.... Or switch to a local model for extraction: configure "custom_fact_extraction_model" in the Memory config to use a local provider. Problem: Memory search returns irrelevant or empty results. Fix: Mem0's search uses semantic similarity. If memories are too generic, the embedding distance may not distinguish them. Check that filters={"user_id": "alice"} is applied — without user_id filtering, results mix across users. Adjust threshold=0.3 (lower = more results, higher = more relevant) in .search(). Problem: Duplicate or contradictory memories accumulate. Fix: Mem0's deduplication checks for near-duplicate memories at .add() time based on embedding similarity. If contradictory memories enter (e.g., "I live in New York" then "I live in Boston"), Mem0 doesn't auto-resolve — it stores both. Use m.update(memory_id, "I live in Boston") to manually update. For auto-resolution, implement a periodic memory reconciliation pipeline on your side.