mem0
Type: full-code · Vendor: Mem0 · Language: Python, TypeScript · License: Apache-2.0 · Status: active · Status in practice: mature
Drop-in memory layer that extracts salient facts from agent conversations and serves them back as personalized context across sessions, users, and agents.
Description. Mem0 is a managed and open-source memory layer for AI agents that turns ongoing conversations into a stored set of user facts, preferences, and episodes which the agent can search on subsequent turns. The agent sends raw messages to `add`; an LLM extracts salient items, deduplicates them against prior memory, and writes them to a vector store scoped by `user_id`, `agent_id`, or `run_id`. On later turns the agent calls `search` to retrieve the most relevant memories instead of replaying the full chat history. The project ships Python and TypeScript SDKs plus a hosted platform, and is described in the paper 'Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory'.
Agent loop shape. Sidecar memory loop wrapped around an external agent. On every user turn the agent calls `mem0.search(query, user_id)` to retrieve relevant prior memories and injects them into the LLM prompt; after the turn the agent calls `mem0.add(messages, user_id)` which sends the messages through an extraction LLM that derives facts, resolves conflicts against existing memories, and writes the survivors to managed vector storage. Memory operations are add / search / update / delete; identity is keyed by user_id, agent_id, or run_id.
Primary use cases
- persistent user memory across sessions
- personalized assistants that learn preferences over time
- reducing prompt bloat and token cost on long conversations
- cross-agent shared memory in multi-agent systems
Key concepts
- add / search / update / delete (docs) — Four operations on the memory store; `add` extracts facts via LLM, `search` returns relevant memories.
- user_id / agent_id / run_id → session-isolation (docs) — Scoping identifiers that key memories to a person, an agent, or a single run.
- Memory extraction (infer=True) (docs) — An LLM pulls out key facts, decisions, or preferences from raw messages and stores those rather than the verbatim turns.
- Short-term vs long-term memory → episodic-summaries (docs) — Short-term covers conversation history, working memory, attention; long-term covers factual, episodic, and semantic memory.
- Vector store backend → vector-memory (docs) — Managed vector storage holds extracted memories; an entity-linking pass replaces the older optional graph store.
Patterns this full-code implements —
- ★★Cross-Session Memory
Core value prop: memories scoped by user_id persist across sessions and across agents, so the next conversation does not start blank.
- ★★Vector Memory
Extracted memories land in managed vector storage; search returns by semantic similarity.
- ★★Session Isolation
Every read and write carries a user_id / agent_id / run_id; memories are keyed by identity for retrieval.
- ★Agentic Memory
Mem0 implements memory-ops-as-tools: at write time the LLM picks ADD/UPDATE/DELETE/NOOP against retrieved memories via a function-calling tool interface, and the Mem0 MCP server exposes add/search/up…
- ★★Episodic Summaries
Mem0's long-term memory taxonomy explicitly names episodic memory as compressed summaries of past interactions; the add pipeline produces these via LLM extraction rather than verbatim logs.
- ★Knowledge Graph Memory
Graph memory backends (Neo4j, Memgraph, Kuzu, AGE, Neptune) were a first-class option in the older SDK but have been removed from the open-source SDK and replaced by built-in entity linking; managed…
- ★MemGPT-Style Paging
Honest downgrade — mem0 is positioned as an alternative to MemGPT-style paging rather than an implementation of it. The mem0 paper explicitly contrasts itself with MemGPT's hierarchical paging pipeli…