Open-source memory layer for AI agents and assistants that extracts, stores, and retrieves user, session, and agent memories so applications can personalize and remember across interactions, with Python and TypeScript SDKs and pluggable vector, graph, and key-value stores.
by mem0ai · submitted by davion-knight·added 2026-07-09·
Stored memories influence future agent behavior, so treat memories written from external or user content as untrusted input and constrain what an agent may do based on retrieved memories., Scope memory by a per-user or per-agent identifier so one user's memories are not retrieved for another, and review which content is eligible to become a stored memory., The memory-extraction step calls a model provider with conversation content; use credentials scoped to the minimum needed and keep them out of source control., Self-hosting keeps memories in your own stores, while the managed platform processes them under its terms; choose the deployment that matches your data requirements., Keep production memory stores and permissions narrower than quickstart examples, and set retention rules for accumulated memories.
Privacy notes
Mem0 stores user preferences, facts, and history as memories, which can include personal or sensitive data extracted from conversations., Memory extraction and embedding send conversation content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine., Stored memories persist in the vector, graph, or key-value backend you configure, so apply retention, deletion, and access-control policies to that store., Provider keys, memory data, and any exports should be treated as sensitive and kept out of version control.
Author
mem0ai
Submitted by
davion-knight
Claim status
unclaimed
Last verified
2026-07-09
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Pending
Baseline comparison available
No baseline peer selected yet.
Pending
Diverging trust signals identified
No major trust-signal divergence found.
Pending
Adoption plan
Balanced adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Risk 16
Pre-adoption checks
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Done
Confirm metadata review state
Listing has review metadata.
Done
Verify install payload
Install/config payload exists and can be inspected.
Done
Security checks
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Done
Review privacy notesRequired
Privacy notes are present.
Done
Verify package integrity metadata
No package verification/checksum metadata.
Pending
Rollout
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Pending
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Pending
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Pending
Evidence readiness
Evidence readiness matrix · balanced
Required evidence gates are covered (5/6 signals complete).
Risk 15
Source provenance
Present
Source repository/provenance is listed.
Required in this preset
Metadata review
Present
Review metadata is present.
Required in this preset
Safety notes
Present
Safety notes are present.
Required in this preset
Privacy notes
Present
Privacy notes are present.
Optional in this preset
Package integrity
Missing
Package integrity metadata is missing.
Optional in this preset
Install payload
Present
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
Decision timeline · balanced
5/6 steps complete with no blocking gaps for this preset.
Risk 14
triage
Confirm source provenanceRequired
Source/provenance metadata is available.
Done
triage
Check metadata review statusRequired
Review metadata is available.
Done
verify
Review safety notesRequired
Safety notes are available.
Done
verify
Review privacy notes
Privacy notes are available.
Done
verify
Validate package integrity metadata
Package integrity metadata is missing.
Pending
rollout
Verify install payload and commandsRequired
Install payload is available.
Done
No required blockers for this timeline preset.
Safety notes
Stored memories influence future agent behavior, so treat memories written from external or user content as untrusted input and constrain what an agent may do based on retrieved memories.
Scope memory by a per-user or per-agent identifier so one user's memories are not retrieved for another, and review which content is eligible to become a stored memory.
The memory-extraction step calls a model provider with conversation content; use credentials scoped to the minimum needed and keep them out of source control.
Self-hosting keeps memories in your own stores, while the managed platform processes them under its terms; choose the deployment that matches your data requirements.
Keep production memory stores and permissions narrower than quickstart examples, and set retention rules for accumulated memories.
Privacy notes
Mem0 stores user preferences, facts, and history as memories, which can include personal or sensitive data extracted from conversations.
Memory extraction and embedding send conversation content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine.
Stored memories persist in the vector, graph, or key-value backend you configure, so apply retention, deletion, and access-control policies to that store.
Provider keys, memory data, and any exports should be treated as sensitive and kept out of version control.
Prerequisites
Python or TypeScript project and a package manager to install the SDK (`mem0ai` for Python or the TypeScript SDK for Node).
A model provider for the extraction and embedding steps, or local models if you prefer to run them yourself.
A backing store for memories (a supported vector store, and optionally a graph or key-value store) for self-hosted use, or a Mem0 platform key.
Stable identifiers for the user, session, or agent whose memories you are storing and retrieving.
A retention and access-control plan for the memory store, since it holds accumulated user data.
## Editorial notes
Mem0 ("mem-zero") is useful when Claude-adjacent teams want their assistants and agents to remember users and context across sessions instead of starting cold each time. It provides an intelligent memory layer that extracts memories from interactions, stores them, and retrieves the relevant ones later, so applications can personalize responses and carry state forward.
This is distinct from the agent frameworks, gateways, and observability tools in the directory: rather than building, routing, or tracing agents, Mem0 is the memory layer those workflows read from and write to, with SDKs and pluggable storage backends.
## Key capabilities
- **Multi-level memory** — retains User, Session, and Agent state, so personalization can be scoped to the right level.
- **Memory extraction** — extracts facts and preferences from conversations and stores agent-confirmed information as first-class memories.
- **Entity linking** — extracts and links entities across memories to improve later retrieval.
- **Multi-signal retrieval** — combines semantic, keyword, and entity matching to surface the most relevant memories.
- **Temporal reasoning** — time-aware retrieval that can distinguish current state, past events, and upcoming plans.
- **Pluggable storage** — works with supported vector stores, plus graph and key-value backends, for self-hosted deployments.
- **SDKs** — Python (`mem0ai`) and TypeScript SDKs for adding and searching memories from application code.
- **Self-host or managed** — run the open-source layer yourself, or use the managed Mem0 platform.
## How teams use it
- **Personalized assistants** — remember a user's preferences and history to tailor responses over time.
- **Customer support** — recall past tickets and context for more relevant help.
- **Long-running agents** — carry state and learned facts across sessions for autonomous workflows.
- **Adaptive products** — adjust workflows or experiences based on remembered user behavior.
- **Context efficiency** — retrieve only the relevant memories instead of resending full history each turn.
## Getting started
Mem0 is open source and can run self-hosted or against the managed platform. Add the SDK to your
project — `mem0ai` for Python or the TypeScript SDK for Node — configure a model provider and a
backing store, then add memories from interactions and search them by a user, session, or agent
identifier. Retrieved memories are supplied to your prompts so the assistant can personalize and
maintain context across sessions.
## Source notes
- The official repository describes Mem0 as an intelligent memory layer that enhances AI assistants and agents with personalized memory, remembering user preferences and adapting over time.
- Documented capabilities include multi-level memory (user, session, agent), memory extraction with agent-confirmed facts as first-class entries, entity linking, multi-signal retrieval (semantic, keyword, and entity), and temporal reasoning.
- Mem0 provides Python (`mem0ai`) and TypeScript SDKs and supports pluggable vector, graph, and key-value backends for self-hosting.
- A managed Mem0 platform is available with additional optimizations, separate from the open-source SDK; the project also open-sources its evaluation framework.
- The GitHub repository is `mem0ai/mem0`, is Apache-2.0 licensed, is installed from PyPI as `mem0ai`, and targets Python 3.10+.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, skills, hooks, rules, commands, guides, open pull requests, and repository-wide content for `Mem0`, `mem0`, `mem0ai`, `mem0.ai`, `github.com/mem0ai/mem0`, `memory layer`, and `agent memory`. Existing entries reference memory in passing and cover adjacent RAG and storage tools, but no dedicated Mem0 tools entry, Mem0 source URL duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used.
About this resource
Editorial notes
Mem0 ("mem-zero") is useful when Claude-adjacent teams want their assistants and agents to remember users and context across sessions instead of starting cold each time. It provides an intelligent memory layer that extracts memories from interactions, stores them, and retrieves the relevant ones later, so applications can personalize responses and carry state forward.
This is distinct from the agent frameworks, gateways, and observability tools in the directory: rather than building, routing, or tracing agents, Mem0 is the memory layer those workflows read from and write to, with SDKs and pluggable storage backends.
Key capabilities
Multi-level memory — retains User, Session, and Agent state, so personalization can be scoped to the right level.
Memory extraction — extracts facts and preferences from conversations and stores agent-confirmed information as first-class memories.
Entity linking — extracts and links entities across memories to improve later retrieval.
Multi-signal retrieval — combines semantic, keyword, and entity matching to surface the most relevant memories.
Temporal reasoning — time-aware retrieval that can distinguish current state, past events, and upcoming plans.
Pluggable storage — works with supported vector stores, plus graph and key-value backends, for self-hosted deployments.
SDKs — Python (mem0ai) and TypeScript SDKs for adding and searching memories from application code.
Self-host or managed — run the open-source layer yourself, or use the managed Mem0 platform.
How teams use it
Personalized assistants — remember a user's preferences and history to tailor responses over time.
Customer support — recall past tickets and context for more relevant help.
Long-running agents — carry state and learned facts across sessions for autonomous workflows.
Adaptive products — adjust workflows or experiences based on remembered user behavior.
Context efficiency — retrieve only the relevant memories instead of resending full history each turn.
Getting started
Mem0 is open source and can run self-hosted or against the managed platform. Add the SDK to your
project — mem0ai for Python or the TypeScript SDK for Node — configure a model provider and a
backing store, then add memories from interactions and search them by a user, session, or agent
identifier. Retrieved memories are supplied to your prompts so the assistant can personalize and
maintain context across sessions.
Source notes
The official repository describes Mem0 as an intelligent memory layer that enhances AI assistants and agents with personalized memory, remembering user preferences and adapting over time.
Documented capabilities include multi-level memory (user, session, agent), memory extraction with agent-confirmed facts as first-class entries, entity linking, multi-signal retrieval (semantic, keyword, and entity), and temporal reasoning.
Mem0 provides Python (mem0ai) and TypeScript SDKs and supports pluggable vector, graph, and key-value backends for self-hosting.
A managed Mem0 platform is available with additional optimizations, separate from the open-source SDK; the project also open-sources its evaluation framework.
The GitHub repository is mem0ai/mem0, is Apache-2.0 licensed, is installed from PyPI as mem0ai, and targets Python 3.10+.
Duplicate check
Checked current content/tools/, content/mcp/, agents, skills, hooks, rules, commands, guides, open pull requests, and repository-wide content for Mem0, mem0, mem0ai, mem0.ai, github.com/mem0ai/mem0, memory layer, and agent memory. Existing entries reference memory in passing and cover adjacent RAG and storage tools, but no dedicated Mem0 tools entry, Mem0 source URL duplicate, or open duplicate PR was found.
Disclosure
Editorial listing. No paid placement or affiliate link is used.
Open-source memory layer for AI agents and assistants that extracts, stores, and retrieves user, session, and agent memories so applications can personalize and remember across interactions, with Python and TypeScript SDKs and pluggable vector, graph, and key-value stores.
Apache-2.0 Python framework for building visible, controllable, production AI agents and multi-agent services with event streaming, permission controls, workspaces, sandbox backends, middleware, MCP support, Mem0 memory, agent teams, and multi-tenant multi-session serving.
Open-source Python multi-agent framework for building agent societies, role-playing agents, stateful ChatAgent workflows, RAG agents, synthetic data generation, MCP-enabled use cases, and research-scale agent experiments.
✓Stored memories influence future agent behavior, so treat memories written from external or user content as untrusted input and constrain what an agent may do based on retrieved memories.
Scope memory by a per-user or per-agent identifier so one user's memories are not retrieved for another, and review which content is eligible to become a stored memory.
The memory-extraction step calls a model provider with conversation content; use credentials scoped to the minimum needed and keep them out of source control.
Self-hosting keeps memories in your own stores, while the managed platform processes them under its terms; choose the deployment that matches your data requirements.
Keep production memory stores and permissions narrower than quickstart examples, and set retention rules for accumulated memories.
✓Griptape structures (Agent, Pipeline, Workflow) can call tools that run code, execute shell or Python, query databases, scrape the web, call external APIs, and read or write files; review each tool's side effects before enabling it.
Tool names, descriptions, schemas, rulesets, and retrieved documents become model-facing context, so treat them as untrusted input that can influence the agent.
Off-prompt Task Memory keeps large or sensitive tool outputs out of the prompt by default, but data returned to the LLM, other tools, or downstream tasks still needs review.
Human-in-the-loop approval, rate limits, timeouts, and rollback policies belong on any tool that performs account, billing, data, or infrastructure actions.
Keep production permissions narrower than notebook or demo examples, and scope model-provider and tool credentials to least privilege.
✓AgentScope examples can give agents Bash, file-read, file-write, edit, search, MCP, and custom tools. Scope tool permissions and approval rules before connecting a real project or account.
The README demonstrates permission control, including bypass mode. Do not use bypass-style behavior on production systems, sensitive files, paid APIs, cloud resources, or unreviewed tool chains without compensating controls.
Workspace support can run tools and code through local, Docker, or E2B backends; review filesystem mounts, network access, secrets, resource limits, and cleanup behavior.
Agent teams, background tasks, and multi-session services can continue work after the initial request; define cancellation, timeout, wakeup, escalation, and audit behavior.
Mem0 memory, Redis-backed sessions, MCP configuration, OpenTelemetry, FastAPI services, and model-provider integrations all need version pinning, credential isolation, and security review before production use.
✓CAMEL agents can coordinate multi-step tasks, call tools, use web/search integrations, connect to MCP examples, and run with provider credentials; review tool permissions before giving agents write access or account access.
Large-scale agent societies and role-playing workflows can generate high volumes of model calls, tool calls, logs, synthetic data, and intermediate artifacts; set budgets, rate limits, and stop conditions before long runs.
RAG, document, media, browser, communication, and data-tool extras may access local files, third-party APIs, vector stores, notebooks, or generated datasets; isolate experiments from production systems.
CAMEL examples include MCP-oriented use cases, but MCP does not make connected tools safe by default. Scope server permissions, credentials, filesystem access, and approval gates separately.
Do not treat generated code, generated datasets, citations, research summaries, or multi-agent decisions as verified until they have been reviewed against source data and policy requirements.
Privacy notes
✓Mem0 stores user preferences, facts, and history as memories, which can include personal or sensitive data extracted from conversations.
Memory extraction and embedding send conversation content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine.
Stored memories persist in the vector, graph, or key-value backend you configure, so apply retention, deletion, and access-control policies to that store.
Provider keys, memory data, and any exports should be treated as sensitive and kept out of version control.
✓Griptape runs can send prompts, instructions, conversation memory, tool arguments, tool results, and retrieved context to configured model providers and embedding services.
Tools and drivers can expose local files, database records, API responses, secrets, or proprietary business data to the model and workflow if they are made available to a structure.
Conversation memory, task memory, vector stores, and any observability or run-logging destinations can retain prompts, outputs, embeddings, and metadata outside the application runtime.
The managed Griptape Cloud processes data you send to it; review its data-handling terms before sending production or customer data.
RAG and web/file loaders can pull third-party or workspace content into prompts, memory, and stored artifacts, so apply normal retention and access-control policies.
✓AgentScope workflows can process prompts, model responses, tool arguments, tool outputs, workspace files, code, credentials accidentally present in context, event streams, web UI state, logs, traces, memory records, session state, and tenant metadata.
Long-term memory through Mem0 and multi-session service storage can persist user facts, intermediate outputs, retrieved context, and tool results beyond a single conversation.
Docker, E2B, MCP servers, model providers, Redis, OpenTelemetry exporters, FastAPI deployments, and web UI integrations may send or store data outside the local Python process depending on configuration.
Do not expose private prompts, API keys, unpublished code, customer data, tenant identifiers, session transcripts, or workspace artifacts in public issues, examples, screenshots, logs, or generated reports.
✓Prompts, model responses, agent messages, tool arguments, tool outputs, retrieved documents, search results, logs, generated datasets, traces, and errors may include user or workspace data.
Model providers, search providers, MCP servers, vector stores, web tools, document parsers, browser tools, and observability integrations may receive data from CAMEL workflows.
Keep provider API keys, OAuth tokens, MCP server credentials, vector database URLs, generated logs, and synthetic datasets out of committed examples, screenshots, public issues, and shared notebooks.
If `CAMEL_MODEL_LOG_ENABLED` or other logging/tracing integrations are enabled, review request/response logs and model configuration logs before sharing or retaining them.
Prerequisites
Python or TypeScript project and a package manager to install the SDK (`mem0ai` for Python or the TypeScript SDK for Node).
A model provider for the extraction and embedding steps, or local models if you prefer to run them yourself.
A backing store for memories (a supported vector store, and optionally a graph or key-value store) for self-hosted use, or a Mem0 platform key.
Stable identifiers for the user, session, or agent whose memories you are storing and retrieving.
Python 3.10+ project and a dependency manager to install `griptape` (optionally with extras such as `griptape[all]`) from PyPI.
Model-provider credentials or local model configuration for the prompt, embedding, and vector-store drivers the agent uses.
Clear tool, driver, and memory boundaries before connecting structures to databases, APIs, files, web scraping, or code-execution tools.
A decision on self-hosting the open-source framework versus using the managed Griptape Cloud, with the matching data and secret handling plan.
Python 3.11 or newer and an isolated Python environment managed with pip, uv, or another package manager.
Model provider credentials for the selected model backend, such as DashScope, OpenAI-compatible APIs, Anthropic, Gemini, Ollama, xAI, or another supported route.
A permission policy for tools such as Bash, Grep, Glob, Read, Write, Edit, MCP tools, custom functions, and long-running background tasks.
A workspace isolation decision for local, Docker, E2B, or other sandbox backends before running code or file tools.
Python 3.10 through 3.14 and an isolated Python environment managed with pip, uv, or another package manager.
A configured model provider such as OpenAI or another provider supported by the selected CAMEL model route.
Provider API keys, search credentials, vector database credentials, or tool-specific secrets stored outside source control.
Optional extras for web tools, document tools, RAG, model platforms, storage backends, dev tools, or research tools only when those integrations are required.