What Is Mem0? The Memory Layer for AI Agents, Explained

Mem0 is a memory layer for AI agents and the applications built on them. Your code sends it conversation turns, it extracts the facts worth keeping, and before the next model call your code asks it for the memories that matter to the question at hand. It comes in two forms that share one API: Mem0 Platform, a managed service, and Mem0 Open Source, which you run yourself. Its audience is developers. The person chatting with an app built on Mem0 usually never sees it; the app remembers that they prefer aisle seats, and Mem0 is why. Everything below is from Mem0’s own site and documentation as of October 8, 2026.

If the idea of agent memory is new, what agent memory is covers the kinds and why they matter. This page is about one product.

How Mem0 works: extraction, then retrieval

Mem0’s guide to how Mem0 works↗ (opens in a new tab) describes two moments in an application. After a useful interaction, you call add. Before a model call, you call search and put the best results into the prompt. Your application decides which returned memories to use.

You send messages, but Mem0 stores memories, not a transcript. The documentation’s own examples: “I prefer aisle seats” becomes “User prefers aisle seats”, and “Let’s use Postgres for this project” becomes “Project decision: use Postgres”. Writing a memory runs in four steps:

1. Context lookup: related memories are checked so the same fact is not stored twice.
2. Fact extraction: a language model pulls out preferences, decisions, plans and other reusable details.
3. Deduplication and embedding: redundant facts are dropped and each memory is embedded for semantic search.
4. Entity extraction: people, places, organizations and concepts are pulled out for matching at search time.

Automatic extraction is additive. If a user says they moved from Austin to Seattle, Mem0 can store the new fact without silently rewriting the old one, and your code calls update or delete when a memory must be corrected or removed. Retrieval ranks memories on several signals: semantic similarity, keyword matches for names and IDs, entity overlap and time. Under the hood the parts of a memory live in three stores: a SQL database for facts and metadata, a vector database for embeddings, and an entity store.

from mem0 import MemoryClient

client = MemoryClient(api_key="your-api-key")

client.add(
    [{"role": "user", "content": "I love hiking on weekends"}],
    user_id="alice",
)

client.search("What does Alice like to do?", filters={"user_id": "alice"})

Scoping: whose memory is it?

Every write and search is tagged with identifiers. The documentation on entity-scoped memory↗ (opens in a new tab) lists four on the Platform: user_id for a person, agent_id for an agent persona, app_id for an app or tenant, and run_id for a short-lived session or ticket. The docs tell you to always scope searches, so memories from different users do not mix.

One detail catches people out. On the default extraction path, each fact is attributed to whoever said it: facts from the user’s messages carry user_id, facts from the assistant’s messages carry agent_id, never both. A search that requires both fields therefore returns nothing, and the docs recommend OR instead.

Mem0 Platform vs Mem0 Open Source

Both versions run the same core loop of add, search, get, update and delete, with per-memory history. Mem0’s Platform vs Open Source comparison↗ (opens in a new tab) lists what differs:

• Hosting: the Platform runs the vector store, model and embedder for you and has a web dashboard. Open source means you provision and operate each piece.
• Structure: the Platform has organizations and projects with member roles, plus a project-wide event feed. Open source has a single local configuration and per-memory history only.
• Search features: graph memory, memory decay, temporal reasoning and Dream, a background process that merges duplicates and supersedes outdated facts, are Platform-only.
• Data operations: webhooks, structured export, batch updates and feedback on retrieved memories are Platform-only.

The open-source version runs as a library you import or as a Docker stack with a dashboard and per-user API keys, and the Mem0 repository↗ (opens in a new tab) is Apache 2.0 licensed. By default the library uses an OpenAI model, a local Qdrant vector store and SQLite for history, and every component can be swapped in configuration.

Mem0 over MCP

Mem0 also runs a hosted MCP server, so an AI app such as Claude Code, Cursor or Codex can use memory without your writing code. According to the Mem0 MCP documentation↗ (opens in a new tab), the server lives at https://mcp.mem0.ai/mcp, signs you in through the browser or accepts an API key, and offers tools such as add_memory, search_memories, update_memory and delete_memory. The agent decides for itself when to save something or look it up, and memories live in your Mem0 account. If MCP itself is unfamiliar, see what MCP is.

Security and deployment

Mem0’s site says it is SOC 2 (Type 1), HIPAA and GDPR compliant, offers bring-your-own-key encryption, and can be deployed on Kubernetes, in a private cloud or air-gapped. The documentation adds a sensible warning of its own: avoid storing secrets, raw credentials or unredacted sensitive data, because Mem0 is built to retrieve what it stores. The wider risks of agent memory are covered in agent memory security.

What Mem0 is for, and what it is not for

Mem0 is strong at the things infrastructure should be strong at: many users kept apart, fast retrieval over a large store, automatic extraction so nobody writes memories by hand, and compliance options a regulated company can sign off on. If you are building an AI app for your users and want it to remember them, Mem0 is a reasonable default to evaluate first.

It is not a place where a team writes down how work should be done. The model decides what to extract, memories are read by code rather than people, and there is no notion of a task, a decision someone made, or where yesterday’s session stopped. That is not a flaw; it is a different job.

Questions to settle before you adopt it

• Platform or self-hosted? If you need graph memory, webhooks or export, that decides it for the Platform; if data must stay on your machines, open source or a private deployment does.
• Which identifier is the boundary? Decide what user_id, app_id and run_id mean in your product before the first write, because every search depends on it.
• Who corrects a wrong memory? Extraction is automatic, so plan where your support team or your users can see and fix what was stored.
• What must never be stored? Decide what to strip before add is called, not after.

Where fenbs fits

fenbs does that other job. It is a web app that keeps your AI work context in one place, as memory you can see, edit and share: projects, tasks in lanes To Do, Next Up, In Progress and Completed, Decisions and rules, lessons learned and Where we left off. People and the AI apps they use, such as ChatGPT, Claude, Claude Code, Codex and Cursor, read and update the same board over MCP, so you can switch apps or models without starting over.

The writing is deliberate rather than automatic. People record the rules, and every connected assistant reads them first through fenbs_get_context. An assistant can add a context note, signed with its name, but it cannot decide a decision or pre-approve work. History records every change and who made it, a person or “Claude via” that person. If you are building a product, use Mem0. If you are a person or a team using AI for work, a shared board is the piece Mem0 does not try to be.