Related Pages

Related topics: System Architecture, Quick Start Guide, Use Cases and Applications

Introduction to Mem0

Mem0 is an open-source memory infrastructure designed specifically for AI agents and applications. It provides intelligent, persistent memory management that enables AI systems to retain, retrieve, and utilize information across conversations and sessions. Unlike traditional retrieval-augmented generation (RAG) approaches that treat all context equally, Mem0 implements a hierarchical memory system that automatically prioritizes and maintains relevant information over time.

The platform addresses one of the most significant challenges in AI development: creating systems that can remember user preferences, conversation context, and learned facts in a way that feels natural and improves over time. Mem0 serves as a foundational layer for building production-ready AI agents with scalable long-term memory capabilities.

Core Concepts

Memory Hierarchy

Mem0 organizes memory into multiple scopes, enabling fine-grained control over information retention and retrieval. The system distinguishes between user-level, agent-level, and session-level memories, allowing developers to choose the appropriate context for different types of information.

Memory Operations

The memory system supports four fundamental operations that form the backbone of all interactions:

Add - Stores new information in the memory system with automatic entity extraction and deduplication. The system intelligently parses input to identify key facts, relationships, and metadata.

Search - Retrieves relevant memories using vector similarity search combined with semantic understanding. The search operation supports hybrid queries that combine keyword matching with semantic similarity.

Update - Modifies existing memories when new information supersedes or refines previously stored facts. The system maintains version history for audit purposes.

Delete - Removes specific memories or bulk deletes based on scope filters. Supports soft deletes and hard deletes depending on compliance requirements.

Architecture Overview

Mem0's architecture is designed with modularity and extensibility in mind. The system consists of several interconnected components that work together to provide seamless memory management.

graph TD
    A[AI Agent / Application] --> B[Mem0 API Layer]
    B --> C[Memory Core Engine]
    C --> D[Vector Store]
    C --> E[Graph Store]
    C --> F[SQLite / Database]
    D --> G[Embedding Models]
    E --> H[Entity Extraction]
    F --> I[Metadata Storage]
    B --> J[LLM Integration]
    J --> K[Fact Extraction]
    J --> L[Memory Synthesis]

Key Components

Deployment Options

Mem0 offers multiple deployment options to meet different organizational requirements and use cases.

Cloud Platform

The managed Mem0 Platform provides a fully hosted solution with zero infrastructure management. Users can sign up at app.mem0.ai and immediately begin using the memory infrastructure via SDK or API keys. The cloud platform includes built-in monitoring, automatic scaling, and enterprise-grade security features.

Self-Hosted Server

For organizations requiring on-premise deployment or data sovereignty, Mem0 provides a self-hosted option using Docker Compose. The server includes a web-based dashboard for configuration and management.

# Recommended bootstrap command
cd server && make bootstrap

# Manual start
cd server && docker compose up -d

Self-hosted deployments support authentication out of the box, with options to configure admin accounts and API keys through a setup wizard or environment variables. The ADMIN_API_KEY environment variable enables programmatic admin creation for automated deployments.

Python SDK

The primary Python SDK provides the most comprehensive feature set for Python-based applications:

pip install mem0ai

For NLP-enhanced features including BM25 keyword matching and entity extraction:

pip install mem0ai[nlp]
python -m spacy download en_core_web_sm

TypeScript/JavaScript SDK

The official npm package provides TypeScript-first support for JavaScript and TypeScript applications:

npm install mem0ai

The TypeScript implementation (mem0-ts) offers an alternative open-source option using OpenAI for embeddings and completions, with SQLite-based history tracking and optional graph-based memory relationships.

CLI Tools

Command-line interfaces are available for both Python and Node.js environments:

# Python CLI
pip install mem0-cli

# Node.js CLI
npm install -g @mem0/cli

Key Features

Intelligent Memory Extraction

Mem0 automatically extracts entities, facts, and relationships from conversational input. The extraction process uses large language models to understand context and identify meaningful information that should be stored. This reduces the burden on developers to explicitly specify what to remember.

Hybrid Search Capabilities

Memory retrieval combines multiple search techniques for optimal results:

• Vector similarity search - Finds semantically similar memories using embeddings
• BM25 keyword matching - Ensures exact keyword matches are captured
• Entity extraction - Identifies specific entities for targeted retrieval

Graph-Based Memory (Mem0+)

An enhanced version called Mem0+ adds graph-based relationship tracking, enabling the system to understand connections between entities and facts. This is particularly useful for complex reasoning tasks that require understanding relationships between different pieces of information.

Custom Instructions

Mem0 supports custom extraction instructions that guide the memory system to prioritize specific types of information based on use case requirements. The platform can auto-generate these instructions based on a description of the application domain.

Configuration and Customization

Embedding Models

Mem0 supports multiple embedding providers and models:

LLM Configuration

Language model settings control fact extraction and memory synthesis:

• Provider selection (OpenAI, Anthropic, local models)
• Model selection per operation type
• API key management and key rotation
• Temperature and generation parameters

Memory Storage

Configurable storage backends adapt to different deployment requirements:

graph LR
    A[Memory Write] --> B{Storage Backend}
    B --> C[In-Memory]
    B --> D[SQLite]
    B --> E[PostgreSQL + pgvector]
    B --> F[Qdrant]
    B --> G[ChromaDB]
    B --> H[Weaviate]

Use Cases

Mem0 supports a wide range of applications where persistent memory is valuable:

Personal AI Assistants - Maintain user preferences, conversation history, and learned habits across sessions to provide increasingly personalized experiences.

Customer Service Bots - Remember customer context across multiple support interactions, eliminating the need for customers to repeat information.

Developer Tools - Enable AI coding assistants to learn team conventions, project-specific patterns, and individual developer preferences.

Healthcare Applications - Maintain patient history and context across appointments while ensuring data privacy and compliance.

Educational Platforms - Track student progress, learning preferences, and knowledge gaps to provide personalized tutoring experiences.

Evaluation Framework

Mem0 includes a comprehensive evaluation framework for assessing memory system performance across different scenarios. The framework supports comparison between multiple memory techniques including base Mem0, Mem0+, RAG implementations, and LangMem.

The evaluation framework uses Makefile commands for standardized testing and supports custom parameter configuration via command-line arguments.

Citation

If you use Mem0 in your research or development, please cite the following paper:

@article{mem0,
  title={Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory},
  author={Chhikara, Prateek and Khant, Dev and Aryan, Saket and Singh, Taranjeet and Yadav, Deshraj},
  journal={arXiv preprint arXiv:2504.19413},
  year={2025}
}

License

Mem0 is released under the Apache 2.0 license, enabling both commercial and open-source usage with minimal restrictions. The permissive license allows integration into proprietary applications while requiring attribution and preservation of copyright notices.

Related Pages

Related topics: Introduction to Mem0, Python SDK, TypeScript/Node.js SDK

Quick Start Guide

Mem0 provides a comprehensive memory infrastructure for AI applications, enabling persistent, personalized, and adaptive AI experiences. This guide covers all deployment options to get you up and running quickly.

Overview

Mem0 is a production-ready memory layer for AI agents that handles memory management including storing, retrieving, and updating user/agent memories across interactions. The platform supports multiple deployment options: cloud-hosted, self-hosted server, and local SDK integration.

Key Features:

• Multi-level memory (user, agent, session, app)
• Hybrid search with semantic and keyword matching
• Entity extraction and relationship tracking
• Cloud, self-hosted, and SDK deployment options
• Cross-platform SDK support (Python, Node.js, CLI)

Sources: README.md:1-30

Installation Methods

Mem0 supports multiple installation pathways depending on your use case and deployment preference.

Python SDK

Install the core Mem0 package via pip:

pip install mem0ai

For enhanced search capabilities with NLP support (BM25 keyword matching and entity extraction):

pip install mem0ai[nlp]
python -m spacy download en_core_web_sm

Sources: README.md:12-16

Node.js SDK

For JavaScript/TypeScript environments:

npm install mem0ai

Sources: README.md:20-22

CLI Tool

Install the Mem0 CLI for terminal-based memory management:

npm install -g @mem0/cli   # or: pip install mem0-cli

Sources: README.md:24-26

Deployment Options

Mem0 offers three deployment models to fit different infrastructure requirements.

graph TD
    A[Mem0 Deployment Options] --> B[Cloud Platform]
    A --> C[Self-Hosted Server]
    A --> D[Local SDK Integration]
    
    B --> B1[app.mem0.ai]
    B --> B2[API Key Required]
    
    C --> C1[Docker Compose]
    C --> C2[Custom Configuration]
    
    D --> D1[Python SDK]
    D --> D2[Node.js SDK]

Sources: README.md:1-30

Cloud Platform

The quickest path to production memory infrastructure:

1. Sign up at Mem0 Platform
2. Embed the memory layer via SDK or API keys
3. Start using memory operations immediately

Sources: README.md:28-32

Self-Hosted Server

For organizations requiring full control over their infrastructure.

#### Quick Bootstrap (Recommended)

cd server && make bootstrap

This single command starts the Docker stack, creates an admin account, and issues your first API key.

#### Manual Setup

cd server && docker compose up -d

Access the setup wizard at http://localhost:3000.

Note: Self-hosted authentication is enabled by default. If upgrading from a pre-auth build, set ADMIN_API_KEY, register an admin through the wizard, or use AUTH_DISABLED=true for local development only.

Sources: README.md:17-19

Configuration Requirements: For detailed configuration options, refer to the self-hosted documentation.

Sources: README.md:18-19

Initial Setup Workflow

graph LR
    A[Initialize Mem0] --> B[Configure Provider]
    B --> C[Set API Keys]
    C --> D[Add Memories]
    D --> E[Search/Retrieve]
    
    F[CLI: mem0 init] --> A
    G[SDK: Mem0() config] --> A

Web Dashboard Setup

The self-hosted server includes a guided setup wizard with the following steps:

Sources: server/dashboard/src/app/setup/page.tsx

Setup Commands Example:

curl -X POST ${apiUrl}/memories \
  -H "X-API-Key: ${apiKey}" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "${testMessage}"}], "user_id": "setup-test"}'

Sources: server/dashboard/src/app/setup/page.tsx

CLI Setup

Initialize the CLI with your credentials:

mem0 init
mem0 add "Prefers dark mode and vim keybindings" --user-id alice
mem0 search "What does Alice prefer?" --user-id alice

Sources: README.md:26-27

Provider Configuration

Configure your LLM and embedding providers:

Sources: server/dashboard/src/app/(root)/dashboard/configuration/page.tsx/dashboard/configuration/page.tsx)

Core Operations

Adding Memories

Memories can be added through various interfaces:

CLI:

mem0 add "User prefers dark mode" --user-id alice
mem0 add "Agent configuration" --agent-id bot-123

SDK (Python):

from mem0 import Mem0

client = Mem0()
client.add("User prefers dark mode", user_id="alice")

Searching Memories

mem0 search "What are user preferences?" --user-id alice

Bulk Import

Import memories from a JSON file:

mem0 import data.json --user-id alice

JSON file format:

[
  {
    "memory": "User prefers dark mode",
    "user_id": "alice",
    "metadata": {"source": "survey"}
  }
]

Each item can include memory (or text or content), optional user_id, agent_id, and metadata fields.

Sources: cli/node/README.md

Entity Management

# List entities
mem0 entity list users
mem0 entity list agents --output json

# Delete entities
mem0 entity delete --user-id alice --force

Sources: cli/node/README.md

API Key Management

Creating API Keys

1. Navigate to Dashboard → API Keys
2. Click Create API Key
3. Save the generated key securely

Important: Save your API key immediately after creation — it will not be displayed again.

Sources: server/dashboard/src/app/(root)/dashboard/api-keys/page.tsx/dashboard/api-keys/page.tsx)

Key Limitations

A warning banner appears when you reach the 3-key limit on self-hosted deployments.

Sources: server/dashboard/src/app/(root)/dashboard/api-keys/page.tsx/dashboard/api-keys/page.tsx)

CLI Commands Reference

Flags:

• --user-id <id> — Specify user context
• --agent-id <id> — Specify agent context
• --preview — Preview without deleting (for delete operations)
• --force — Skip confirmation prompt
• -o, --output — Output format (text/json)

Sources: cli/node/README.md

Docker Development (OpenMemory)

For local API development using OpenMemory:

# Build containers
make build

# Create environment file
make env
# Then edit api/.env and enter OPENAI_API_KEY

# Start services
make up

The API will be available at http://localhost:8765

Common Commands:

make logs      # View container logs
make shell     # Open shell in container
make migrate   # Run database migrations
make test      # Run tests
make test-clean # Run tests and clean up
make down      # Stop containers

API documentation available at:

• Swagger UI: http://localhost:8765/docs
• ReDoc: http://localhost:8765/redoc

Sources: openmemory/api/README.md

Running Experiments

For evaluation purposes, Mem0 provides experiment scripts:

# Memory Techniques
make run-mem0-add         # Add memories using Mem0
make run-mem0-search      # Search memories using Mem0
make run-mem0-plus-add    # Add memories using Mem0+ (graph-based)
make run-mem0-plus-search # Search memories using Mem0+

# RAG Experiments
make run-rag              # Run RAG with chunk size 500
make run-full-context     # Run RAG with full context

# Other Techniques
make run-langmem          # Run LangMem experiments
make run-zep-add          # Add memories using Zep
make run-zep-search       # Search memories using Zep
make run-openai           # Run OpenAI experiments

Custom Parameters:

Alternatively, run experiments directly:

python run_experiments.py --technique_type [mem0|rag|langmem] [additional parameters]

Sources: evaluation/README.md

Next Steps

• Configuration: Customize provider settings in the dashboard configuration page
• API Reference: Explore the full API at /docs when running self-hosted
• Documentation: Visit docs.mem0.ai for detailed guides
• Examples: Check the examples/ directory for integration demos
• CLI Help: Run mem0 --help for command options

Citation

If you use Mem0 in your research or application, please cite:

@article{mem0,
  title={Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory},
  author={Chhikara, Prateek and Khant, Dev and Aryan, Saket and Singh, Taranjeet and Yadav, Deshraj},
  journal={arXiv preprint arXiv:2504.19413},
  year={2025}
}

Sources: README.md:1-10

Related Pages

Related topics: Introduction to Mem0

Use Cases and Applications

Mem0 provides a comprehensive memory infrastructure for AI applications, enabling developers to build intelligent systems that maintain context across conversations, users, and sessions. This page documents the primary use cases, application patterns, and real-world scenarios where Mem0 adds significant value.

Overview

Mem0 is designed as a memory layer for AI agents and applications. It addresses the fundamental challenge of maintaining stateful, personalized interactions in AI systems that are inherently stateless. The platform supports multiple deployment models including self-hosted servers, cloud platforms, and embedded SDK integrations. Sources: README.md:1-30

Core Use Cases

Personal AI Assistants

Mem0 powers personal AI assistants that learn and remember user preferences, habits, and historical interactions. These assistants can recall past conversations, understand user context, and provide personalized responses based on accumulated knowledge.

graph TD
    A[User Input] --> B[Mem0 Memory Layer]
    B --> C{Retrieve Relevant Memories}
    C --> D[User Preferences]
    C --> E[Conversation History]
    C --> F[Historical Context]
    D --> G[AI Response Generation]
    E --> G
    F --> G
    G --> H[Store New Memories]
    H --> B

Key Features:

• Persistent user profiles across sessions
• Preference learning and adaptation
• Context-aware response generation
• Multi-turn conversation continuity

Customer Support Chatbots

Enterprise customer support systems benefit from Mem0's ability to maintain conversation history and customer context. Support agents and chatbots can access previous tickets, understand ongoing issues, and provide consistent assistance across multiple interaction channels. Sources: README.md:40-60

Implementation Pattern:

# Typical customer support memory flow
memory.add(
    text="Customer reported payment failure on order #12345",
    user_id="customer_456",
    metadata={"ticket_id": "T-789", "priority": "high"}
)

Healthcare Assistants

AI-powered healthcare applications use Mem0 to maintain patient context, track medical history, and ensure continuity of care across multiple interactions. These systems must handle sensitive data with appropriate privacy considerations while providing valuable clinical insights. Sources: README.md:50-80

Key Considerations:

• HIPAA compliance for patient data
• Structured memory storage for medical records
• Temporal context preservation
• Multi-provider information aggregation

Enterprise Knowledge Management

Organizations leverage Mem0 to build knowledge bases that automatically capture, organize, and retrieve institutional knowledge. Unlike static knowledge bases, Mem0-powered systems continuously learn from interactions and user feedback.

Sources: README.md:35-45

Application Architecture Patterns

Multi-Agent Systems

Mem0 supports complex multi-agent architectures where different agents share contextual information through a unified memory layer.

graph LR
    A[Agent A] -->|Read/Write| M[Mem0 Memory]
    B[Agent B] -->|Read/Write| M
    C[Agent C] -->|Read/Write| M
    M --> D[Shared Context]
    D --> E[Coordinated Actions]

Multi-Agent Memory Configuration:

from mem0 import Memory

memory = Memory.from_ids(
    user_id="shared_session_123",
    agent_id=None,  # Shared across agents
    run_id="workflow_456"
)

Retrieval-Augmented Generation (RAG)

Mem0 integrates with RAG pipelines to enhance LLM responses with retrieved memories. The platform supports configurable chunk sizes, embedding models, and hybrid search strategies. Sources: evaluation/README.md:1-50

Multi-Modal Applications

Modern AI applications process multiple input types including text, images, and audio. Mem0 stores and retrieves context from multi-modal conversations, enabling coherent responses across different content types. Sources: examples/multimodal-demo/src/components/messages.tsx:1-60

Deployment Scenarios

Self-Hosted Server

Organizations requiring full control over their data can deploy Mem0 as a self-hosted solution. The self-hosted server includes a dashboard for management, API key generation, and configuration options. Sources: README.md:60-80

# Quick start with bootstrap
cd server && make bootstrap

# Manual Docker deployment
cd server && docker compose up -d

Self-Hosted Features:

• Admin account creation via setup wizard
• API key management through dashboard
• Configuration for LLM and embedding providers
• Request logging and analytics
• Webhook support for event notifications

Cloud Platform

The Mem0 cloud platform provides a managed solution with additional features including project-based isolation, SSO/SAML authentication, and enterprise support. Sources: README.md:50-60

Embedded SDK Integration

For applications requiring client-side or edge deployment, Mem0 provides lightweight SDKs:

Sources: README.md:25-40

CLI Applications

The Mem0 CLI enables developers to manage memories directly from the terminal, useful for development, debugging, and automation tasks. Sources: cli/node/README.md:1-80

# Initialize CLI configuration
mem0 init

# Add memories
mem0 add "User prefers dark mode" --user-id alice

# Search memories
mem0 search "What does Alice prefer?" --user-id alice

# Manage entities
mem0 entity list users
mem0 entity delete --user-id alice --force

CLI Commands Reference:

Evaluation and Benchmarking

Mem0 includes comprehensive evaluation tools for comparing different memory techniques and configurations. The evaluation framework supports multiple approaches including Mem0, Mem0+, RAG, and LangMem. Sources: evaluation/README.md:50-100

# Run Mem0 experiments
make run-mem0-add
make run-mem0-search

# Run Mem0+ with graph-based search
make run-mem0-plus-add
make run-mem0-plus-search

# Run RAG experiments
make run-rag
make run-full-context

# Run custom experiments
python run_experiments.py --technique_type mem0 --method add

Experiment Parameters:

Industry-Specific Applications

OpenClaw Platform Integration

OpenClaw demonstrates how Mem0 integrates with specialized AI platforms for specific domains. The platform supports both hosted API mode and self-hosted open-source mode with configurable memory behaviors. Sources: openclaw/README.md:1-50

Platform Mode Configuration:

Open-Source Mode Defaults:

Support Inbox Automation

Automated support systems use Mem0 to track issue resolution history, maintain customer context across channels, and enable intelligent routing based on historical patterns.

Email Automation

Email-based workflows leverage Mem0's ability to maintain conversation context across email threads, automatically categorizing and prioritizing messages based on user history and past interactions.

Best Practices

Memory Structuring

Organize memories with appropriate metadata for optimal retrieval:

memory.add(
    text="Customer's subscription expired",
    user_id="customer_123",
    metadata={
        "category": "billing",
        "priority": "medium",
        "timestamp": "2025-01-15"
    }
)

Privacy Considerations

• Implement data retention policies
• Use encryption for sensitive information
• Leverage user consent mechanisms
• Enable data export and deletion capabilities

Performance Optimization

• Configure appropriate embedding models for your use case
• Use hybrid search combining semantic and keyword matching
• Implement caching for frequently accessed memories
• Monitor request latency through the dashboard

Additional Resources

• Quick Start Guide
• API Reference
• Self-Hosted Documentation
• CLI Reference
• Platform Documentation

Related Pages

Related topics: Introduction to Mem0, Memory Operations, Python SDK, Vector Stores and Storage

System Architecture

Overview

Mem0 is an intelligent memory layer designed for AI agents and applications. It provides persistent, scalable long-term memory capabilities that enable AI systems to retain, retrieve, and manage information across conversations and sessions.

Sources: server/README.md

The architecture follows a modular design pattern with distinct layers for memory management, storage, API serving, and client implementations. This separation enables flexibility in deployment options and supports multiple use cases from embedded applications to cloud-based services.

High-Level Architecture

graph TD
    subgraph Client_Layer["Client Layer"]
        CLI["CLI Application<br/>mem0"]
        TS_Client["TypeScript Client<br/>mem0-ts"]
        Python_SDK["Python SDK<br/>mem0ai/mem0"]
    end
    
    subgraph API_Layer["API Layer"]
        Server["FastAPI Server<br/>server/main.py"]
        Routers["API Routers<br/>server/routers/"]
    end
    
    subgraph Memory_Core["Memory Core"]
        Main["Memory Manager<br/>mem0/memory/main.py"]
        Base["Base Memory<br/>mem0/memory/base.py"]
        Storage["Storage Engine<br/>mem0/memory/storage.py"]
    end
    
    subgraph Storage_Backend["Storage Backend"]
        VectorStore["Vector Store"]
        DB["Database"]
    end
    
    CLI --> Server
    TS_Client --> Server
    Python_SDK --> Main
    Main --> Base
    Main --> Storage
    Storage --> VectorStore
    Storage --> DB
    Server --> Main

Core Components

Memory Module Architecture

The memory module is the heart of the Mem0 system, implementing the core memory operations.

Sources: mem0/memory/main.py

Base Memory Class

The base class defines the contract that all memory implementations must follow.

Sources: mem0/memory/base.py

classDiagram
    class BaseMemory {
        <<abstract>>
        +add() AddMemory
        +search() SearchMemory
        +get() GetMemory
        +update() UpdateMemory
        +delete() DeleteMemory
        +list() ListMemories
    }
    
    class MemoryManager {
        +add()
        +search()
        +get()
        +update()
        +delete()
        +list()
        -storage: Storage
    }
    
    BaseMemory <|-- MemoryManager

Storage Engine

The storage layer handles the persistence of memory data using vector embeddings and traditional database storage.

Sources: mem0/memory/storage.py

#### Supported Storage Backends

API Layer

Server Architecture

The server layer is built on FastAPI, providing RESTful endpoints for memory operations.

Sources: server/main.py

graph LR
    subgraph Endpoints["API Endpoints"]
        A["Add Memory"]
        S["Search Memory"]
        G["Get Memory"]
        U["Update Memory"]
        D["Delete Memory"]
        L["List Memories"]
    end
    
    subgraph Router["Router Module"]
        R["server/routers/__init__.py"]
    end
    
    A --> R
    S --> R
    G --> R
    U --> R
    D --> R
    L --> R
    R --> MemoryCore["Memory Core"]

API Configuration

The system supports various configuration options for deployment flexibility.

Sources: server/README.md

Client Implementations

Python SDK

The Python SDK provides the primary interface for integrating Mem0 into applications.

Sources: mem0ai/mem0

from mem0 import Memory

memory = Memory()
memory.add("User prefers dark mode", user_id="alice")
results = memory.search("What are user preferences?", user_id="alice")

TypeScript Client

The TypeScript implementation provides memory capabilities for JavaScript/TypeScript environments.

Sources: mem0-ts/src/client/mem0.ts

import { Memory } from "mem0-ts";

const memory = new Memory({
  embedder: {
    provider: "openai",
    config: { apiKey: process.env.OPENAI_API_KEY }
  }
});

CLI Application

The command-line interface provides direct access to memory operations.

Sources: cli/README.md

#### CLI Agent Mode

The CLI supports agent mode for AI agent tool loops:

mem0 --agent search "user preferences" --user-id alice
mem0 --agent add "User prefers dark mode" --user-id alice

Sources: cli/node/README.md

Memory Techniques

Mem0 supports multiple memory retrieval techniques for different use cases.

Sources: evaluation/README.md

graph TD
    subgraph Techniques["Memory Techniques"]
        M0["Mem0<br/>Vector-based retrieval"]
        M0P["Mem0+<br/>Graph-based search"]
        RAG["RAG<br/>Chunk-based retrieval"]
        LM["LangMem<br/>Language model memory"]
    end
    
    subgraph Use_Cases["Use Cases"]
        UC1["Personal assistants"]
        UC2["Customer support"]
        UC3["Research tools"]
        UC4["Enterprise applications"]
    end
    
    M0 --> UC1
    M0P --> UC2
    RAG --> UC3
    LM --> UC4

Technique Comparison

Data Models

Memory Entity Structure

Evaluation Metrics

The system tracks multiple metrics for performance evaluation.

Sources: evaluation/README.md

Deployment Options

Local/Embedded Mode

For applications requiring local-only memory:

• SQLite-based vector store: ~/.mem0/vector_store.db
• History database: ~/.mem0/history.db
• Memory consolidation state: <pluginStateDir>/dream-state.json

Sources: openclaw/README.md

Cloud Mode

For managed Mem0 cloud services:

• Requires MEM0_API_KEY
• Project and organization configuration
• Scalable vector storage

Server Deployment

The FastAPI server can be deployed independently:

# Start server
python server/main.py

# Configure via environment variables
# - Set API keys
# - Configure storage backends
# - Set model preferences

Sources: server/main.py

Vercel AI SDK Integration

Mem0 provides seamless integration with the Vercel AI SDK for streaming responses with memory.

Sources: vercel-ai-sdk/README.md

const mem0 = createMem0({
  config: {
    // Model configuration options
  }
});

Best Practices for Vercel Integration

1. User Identification: Always provide a unique user_id for consistent memory retrieval
2. Context Management: Balance context window sizes with memory requirements
3. Error Handling: Implement proper error handling for memory operations
4. Memory Cleanup: Regularly clean up unused memory contexts

Evaluation Framework

The evaluation module provides comprehensive testing capabilities.

Sources: evaluation/README.md

Running Experiments

# Run Mem0 experiments
make run-mem0-add
make run-mem0-search

# Run Mem0+ experiments
make run-mem0-plus-add
make run-mem0-plus-search

# Run RAG experiments
make run-rag

Evaluation Command-Line Parameters

System Flow Diagrams

Memory Addition Flow

sequenceDiagram
    participant Client
    participant API
    participant MemoryManager
    participant Storage
    participant VectorStore
    
    Client->>API: Add memory request
    API->>MemoryManager: Process memory
    MemoryManager->>MemoryManager: Extract facts
    MemoryManager->>Storage: Store memory
    Storage->>VectorStore: Generate embeddings
    VectorStore->>Storage: Store vectors
    Storage->>MemoryManager: Confirm storage
    MemoryManager->>API: Return memory ID
    API->>Client: Success response

Memory Search Flow

sequenceDiagram
    participant Client
    participant API
    participant MemoryManager
    participant Storage
    participant VectorStore
    
    Client->>API: Search request
    API->>MemoryManager: Process query
    MemoryManager->>VectorStore: Generate query embedding
    VectorStore->>MemoryManager: Return similar memories
    MemoryManager->>API: Format results
    API->>Client: Return search results

Security Considerations

API Key Management

• Use environment variables for sensitive credentials
• Rotate API keys periodically
• Implement proper access controls for production deployments

Data Privacy

• User data isolation via user_id scoping
• Support for entity-level deletion
• Optional metadata encryption for sensitive information

Extensibility Points

The architecture supports extension through:

1. Custom Storage Backends: Implement the storage interface for new backends
2. Custom Embedding Providers: Add support for alternative embedding models
3. Custom Memory Techniques: Extend base class for specialized retrieval
4. Plugin System: OpenClaw integration for additional capabilities

References

• Main Repository: mem0ai/mem0
• Documentation: docs.mem0.ai
• Paper Citation: arXiv:2504.19413

Related Pages

Related topics: System Architecture, AI Model Integration, Vector Stores and Storage, Python SDK

Memory Operations

Memory operations are the core CRUD (Create, Read, Update, Delete) interactions that power the Mem0 memory system. These operations enable AI agents to store, retrieve, modify, and delete persistent memory across user sessions, agent executions, and application contexts. The memory operations layer abstracts the complexity of vector storage, semantic indexing, and multi-entity management into a unified API that supports both synchronous and asynchronous execution patterns.

Overview

The Mem0 memory system provides five fundamental operations that form the backbone of persistent memory management. Each operation is designed to work with multiple entity scopes, including user-level, agent-level, application-level, and run-level contexts. The operations support rich metadata filtering, custom instructions for memory processing, and both blocking and non-blocking execution modes for handling large-scale memory operations.

Memory operations in Mem0 are built on a layered architecture where the core memory module (mem0/memory/main.py) handles the business logic, while underlying vector stores and databases manage persistence. This separation allows Mem0 to support different deployment scenarios from local SQLite-based storage to cloud-hosted vector databases.

Core Memory Operations

Add Memory

The Add operation is the primary mechanism for storing new information in the memory system. When a memory is added, Mem0 performs several processing steps including embedding generation, fact extraction, and semantic categorization before storing the data in the appropriate vector store.

Function signature and parameters:

def add(
    messages: str | list[dict],
    user_id: str | None = None,
    agent_id: str | None = None,
    app_id: str | None = None,
    run_id: str | None = None,
    metadata: dict | None = None,
    filter_version: str | None = "v1.0",
    prompt: str | None = None,
    max_items: int | None = None
) -> dict

Sources: mem0/memory/main.py

Operation workflow:

graph TD
    A[Input: messages + entity identifiers] --> B[Validate input and entity scope]
    B --> C[Generate vector embeddings]
    C --> D[Extract facts using LLM]
    D --> E[Apply custom instructions if configured]
    E --> F[Store in vector store with metadata]
    F --> G[Return memory IDs and stored content]

Adding memories via CLI:

# Add a simple text memory
mem0 add "I prefer dark mode" --user-id alice

# Add from a JSON messages array
mem0 add --file conversation.json --user-id alice

# Add from stdin
echo "Loves hiking on weekends" | mem0 add --user-id alice

# Add with metadata
mem0 add "User prefers TypeScript over JavaScript" --metadata '{"category": "preference", "priority": "high"}'

Sources: cli/python/README.md

Search Memory

The Search operation retrieves relevant memories based on natural language queries. Mem0 converts the query into a vector embedding and performs similarity search against stored memories, returning results ranked by relevance. The search operation supports filtering by entity scope, metadata attributes, and memory types.

Function signature and parameters:

def search(
    query: str,
    user_id: str | None = None,
    agent_id: str | None = None,
    app_id: str | None = None,
    run_id: str | None = None,
    version: str | None = "v1.1",
    limit: int = 10,
    category: str | None = None,
    filter: dict | None = None,
    rerank: bool = False
) -> list[dict]

Sources: docs/core-concepts/memory-operations/search.mdx

Search with metadata filtering:

Metadata filtering allows precise memory retrieval based on specific attributes stored with each memory. This is particularly useful for retrieving memories that match certain criteria without relying solely on semantic similarity.

result = memory.search(
    query="user preferences",
    user_id="alice",
    filter={
        "category": "preference",
        "priority": {"$eq": "high"}
    }
)

Sources: docs/open-source/features/metadata-filtering.mdx

CLI search examples:

# Basic semantic search
mem0 search "What are Alice's preferences?" --user-id alice

# Search with output formatting
mem0 search "preferences" --output json --top-k 20

# Search within specific scope
mem0 search "agent behavior" --agent-id agent-123

Get Memory

The Get operation retrieves a specific memory by its unique identifier. Unlike search which performs semantic similarity, get provides direct access to a known memory record for viewing, editing, or deletion operations.

CLI usage:

# Retrieve a specific memory by ID
mem0 get 7b3c1a2e-4d5f-6789-abcd-ef0123456789

# Get memory with JSON output for AI agent processing
mem0 get 7b3c1a2e-4d5f-6789-abcd-ef0123456789 --output json

Sources: cli/node/README.md

Update Memory

The Update operation modifies the content or metadata of an existing memory while preserving the memory's history and relationships. The update operation preserves the original memory ID and maintains audit trails of modifications.

Function signature and parameters:

def update(
    memory_id: str,
    data: str | None = None,
    metadata: dict | None = None,
    user_id: str | None = None
) -> dict

Sources: docs/core-concepts/memory-operations/update.mdx

Update operation workflow:

graph TD
    A[Update request with memory_id] --> B[Locate existing memory record]
    B --> C[Apply content or metadata changes]
    C --> D[Update vector embeddings if content changed]
    D --> E[Preserve modification history]
    E --> F[Return updated memory object]

CLI update examples:

# Update memory text
mem0 update <memory-id> "Updated preference text"

# Update metadata only
mem0 update <memory-id> --metadata '{"priority": "high"}'

# Update via stdin
echo "new text" | mem0 update <memory-id>

Delete Memory

The Delete operation removes memories from the storage system. Mem0 supports multiple deletion strategies including single memory deletion, bulk deletion by scope, and entity-level deletion that removes all associated memories.

Function signature and parameters:

def delete(
    memory_id: str | None = None,
    user_id: str | None = None,
    agent_id: str | None = None,
    app_id: str | None = None,
    run_id: str | None = None,
    delete_all: bool = False,
    confirm: bool = False
) -> dict

Sources: docs/core-concepts/memory-operations/delete.mdx

CLI delete examples:

# Delete a single memory
mem0 delete <memory-id>

# Delete all memories for a user (with confirmation)
mem0 delete --all --user-id alice

# Delete all memories project-wide
mem0 delete --all --project --force

# Preview what would be deleted
mem0 delete --all --user-id alice --dry-run

Delete flags reference:

Sources: cli/node/README.md

List Memories

The List operation retrieves memories with optional filters, pagination, and sorting. Unlike search which returns semantically relevant results, list provides comprehensive enumeration of stored memories within specified scopes.

CLI usage:

# List all memories for a user
mem0 list --user-id alice

# List with pagination
mem0 list --user-id alice --page 1 --page-size 50

# List in JSON format for agent consumption
mem0 list --user-id alice --output json

Entity Scopes

Mem0 organizes memories within hierarchical entity scopes that provide logical separation and access control. Each memory belongs to at least one entity identifier, creating an ownership hierarchy.

graph TB
    A[Memory Record] --> B[user_id]
    A --> C[agent_id]
    A --> D[app_id]
    A --> E[run_id]
    
    B --> F[User Entity]
    C --> G[Agent Entity]
    D --> H[Application Entity]
    E --> I[Run Entity]
    
    F --> J[Project/Organization]
    G --> J
    H --> J
    I --> J

Entity scope parameters:

Sources: docs/core-concepts/memory-types.mdx

Asynchronous Memory Operations

For large-scale memory operations that may take extended time to complete, Mem0 provides asynchronous execution modes. Async operations return immediately with an event ID that can be used to track progress and retrieve results.

Async operation support:

Sources: docs/open-source/features/async-memory.mdx

Event monitoring via CLI:

# List recent background processing events
mem0 event list

# Check the status of a specific event
mem0 event status <event-id>

Memory Types

Mem0 supports different memory types that serve distinct purposes in AI agent architectures. Each memory type has specific characteristics optimized for different retrieval patterns and use cases.

Memory type reference:

Sources: docs/core-concepts/memory-types.mdx

Metadata and Filtering

Mem0 supports rich metadata storage and filtering capabilities that enable precise memory retrieval beyond semantic similarity. Metadata can include arbitrary key-value pairs that are indexed for efficient filtering.

Metadata structure example:

memory = {
    "id": "mem_xxxxx",
    "memory": "User prefers dark mode for the interface",
    "metadata": {
        "category": "preference",
        "priority": "high",
        "source": "explicit_feedback",
        "tags": ["ui", "theme", "dark-mode"]
    },
    "created_at": "2025-01-15T10:30:00Z",
    "user_id": "alice"
}

Filter operators supported:

Sources: docs/open-source/features/metadata-filtering.mdx

Custom Instructions

Custom instructions provide a mechanism to customize how Mem0 processes and interprets memories. These instructions guide the LLM in extracting relevant facts, categorizing information, and determining storage behavior.

Configuration example:

memory = Memory()

# Set custom instructions for the memory instance
memory.configure(
    custom_instructions="Focus on extracting user preferences about product features. "
                        "Categorize memories by product area. "
                        "Prioritize recent explicit feedback over implicit observations."
)

# Add memory with custom processing
result = memory.add(
    messages="I really love the new dark mode feature in the settings panel",
    user_id="alice"
)

Sources: docs/open-source/features/custom-instructions.mdx

Bulk Import

Mem0 supports bulk importing of memories from JSON files, enabling migration from other systems or initial data population.

Import file format:

[
  {
    "memory": "User prefers dark mode",
    "user_id": "alice",
    "metadata": {"category": "preference"}
  },
  {
    "text": "Agent uses fallback strategy when API fails",
    "agent_id": "agent-123",
    "metadata": {"behavior": "error-handling"}
  },
  {
    "content": "Application has rate limiting enabled",
    "app_id": "app-production",
    "metadata": {"configuration": true}
  }
]

CLI import command:

mem0 import data.json --user-id alice

Sources: cli/node/README.md

Agent Mode

The CLI supports an agent mode that formats output specifically for AI agent tool loops. This mode returns structured JSON that can be easily parsed by AI systems for decision-making.

Agent mode usage:

mem0 --agent search "user preferences" --user-id alice
mem0 --agent add "User prefers dark mode" --user-id alice
mem0 --agent list --user-id alice

Sources: cli/python/README.md

Dashboard Memory Management

The Mem0 dashboard provides a web-based interface for viewing, searching, and managing memories. The memory operations are accessible through a visual interface that includes pagination, detail views, and deletion confirmation modals.

Dashboard features:

• Paginated memory listing with navigation controls
• Memory detail view showing content, ID, timestamps, and metadata
• Inline deletion with confirmation modal
• Search functionality within the memories page

Sources: server/dashboard/src/app/(root)/dashboard/memories/page.tsx/dashboard/memories/page.tsx)

Configuration and Status

The Mem0 CLI provides commands for managing configuration and verifying connectivity.

Configuration commands:

mem0 config show              # Display current config (secrets redacted)
mem0 config get api_key       # Get a specific value
mem0 config set user_id bob   # Set a value

mem0 status                   # Verify API connection and display project
mem0 version                  # Print CLI version

Operation Flow Summary

graph LR
    A[Client Request] --> B{Operation Type}
    
    B -->|add| C[Process & Store]
    B -->|search| D[Embed Query & Search]
    B -->|get| E[Direct Lookup]
    B -->|update| F[Modify & Re-index]
    B -->|delete| G[Remove from Store]
    
    C --> H[(Vector Store)]
    D --> H
    E --> H
    F --> H
    G --> H
    
    C --> I[Event ID]
    D --> J[Results]
    E --> K[Memory Object]
    F --> K
    G --> L[Confirmation]

Error Handling

Memory operations may encounter various error conditions that should be handled appropriately in client applications.

Common error scenarios:

See Also

• Memory Types - Understanding semantic, episodic, procedural, and long-term memory
• Async Memory - Large-scale asynchronous operations
• Metadata Filtering - Advanced filtering capabilities
• Custom Instructions - Customizing memory processing behavior

Related Pages

Related topics: Memory Operations, Embedding Models, System Architecture

AI Model Integration

Overview

The AI Model Integration module in mem0 provides a unified abstraction layer for interacting with various large language model (LLM) providers. This architecture enables seamless switching between different AI backends while maintaining a consistent interface for memory operations. Sources: docs/components/llms/overview.mdx:1-5

Architecture

The integration follows a Provider Pattern with a base class defining the contract and provider-specific implementations extending it.

graph TD
    A[mem0 Core] --> B[LLM Base Interface]
    B --> C[OpenAI Provider]
    B --> D[Anthropic Provider]
    B --> E[Azure OpenAI Provider]
    B --> F[Gemini Provider]
    
    C --> G[OpenAI API]
    D --> H[Anthropic API]
    E --> I[Azure Cognitive Services]
    F --> J[Google AI API]

Supported Providers

Sources: mem0/llms/base.py:1-20

Base Interface

All LLM providers inherit from LargeLanguageModel base class which defines the core contract:

class LargeLanguageModel(ABC):
    @abstractmethod
    def generate_response(self, messages, **kwargs):
        pass
    
    @abstractmethod
    def get_model_name(self):
        pass

Sources: mem0/llms/base.py:15-30

Core Methods

Provider Implementations

OpenAI Integration

The OpenAI provider supports GPT-4, GPT-4 Turbo, and GPT-3.5 Turbo models through the OpenAI API.

class OpenAILargeLanguageModel(LargeLanguageModel):
    def __init__(
        self,
        model: str = "gpt-4",
        api_key: str = None,
        temperature: float = 0.7,
        max_tokens: int = 2000,
        **kwargs
    ):

Sources: mem0/llms/openai.py:10-25

Configuration Parameters:

Environment Variable: OPENAI_API_KEY

Sources: docs/components/llms/models/openai.mdx:1-15

Anthropic Integration

The Anthropic provider enables access to Claude models through the Anthropic API.

class AnthropicLargeLanguageModel(LargeLanguageModel):
    def __init__(
        self,
        model: str = "claude-3-5-sonnet-20241022",
        api_key: str = None,
        temperature: float = 0.7,
        max_tokens: int = 2000,
        **kwargs
    ):

Sources: mem0/llms/anthropic.py:10-25

Supported Models:

Environment Variable: ANTHROPIC_API_KEY

Sources: docs/components/llms/models/anthropic.mdx:1-20

Azure OpenAI Integration

Azure OpenAI provides enterprise-grade access with compliance features and regional deployment options.

class AzureOpenAILargeLanguageModel(LargeLanguageModel):
    def __init__(
        self,
        model: str = "gpt-4",
        api_key: str = None,
        azure_endpoint: str = None,
        api_version: str = "2024-02-01",
        temperature: float = 0.7,
        max_tokens: int = 2000,
        **kwargs
    ):

Sources: mem0/llms/azure_openai.py:10-30

Azure-Specific Parameters:

Environment Variables:

• AZURE_OPENAI_API_KEY
• AZURE_OPENAI_ENDPOINT

Google Gemini Integration

The Gemini provider integrates with Google AI's Gemini models for multimodal capabilities.

class GeminiLargeLanguageModel(LargeLanguageModel):
    def __init__(
        self,
        model: str = "gemini-2.0-flash-exp",
        api_key: str = None,
        temperature: float = 0.7,
        max_tokens: int = 2000,
        **kwargs
    ):

Sources: mem0/llms/gemini.py:10-25

Supported Models:

Environment Variable: GEMINI_API_KEY

Configuration System

Base Configuration

All LLM configurations inherit from LLMConfig using Pydantic for validation:

class LLMConfig(BaseModel):
    provider: str
    model: str
    temperature: float = 0.7
    max_tokens: int = 2000
    extra_params: dict = {}

Sources: mem0/configs/llms/base.py:1-20

Configuration Factory

The LLMConfigs class provides a centralized configuration registry:

class LLMConfigs:
    @staticmethod
    def get_config(provider: str) -> LLMConfig:
        # Returns provider-specific configuration
        pass

Sources: mem0/configs/llms/__init__.py:1-30

Usage Patterns

Direct Instantiation

from mem0.llms.openai import OpenAILargeLanguageModel

llm = OpenAILargeLanguageModel(
    model="gpt-4",
    temperature=0.3,
    max_tokens=1000
)

response = llm.generate_response(messages=[
    {"role": "user", "content": "Summarize my notes"}
])

Configuration-Based

from mem0.configs.llms import LLMConfigs

config = LLMConfigs.get_config("openai")
llm = config.initialize()

Message Format

All providers accept a standardized message format:

messages = [
    {"role": "system", "content": "You are a helpful assistant"},
    {"role": "user", "content": "What is mem0?"},
    {"role": "assistant", "content": "Mem0 is a memory system..."},
    {"role": "user", "content": "Tell me more"}
]

Error Handling

All LLM providers implement consistent error handling:

try:
    response = llm.generate_response(messages)
except AuthenticationError:
    # Handle invalid API key
    pass
except RateLimitError:
    # Handle rate limiting
    pass
except APIConnectionError:
    # Handle connection issues
    pass

Extending the Framework

To add a new LLM provider:

1. Create a new class inheriting from LargeLanguageModel
2. Implement generate_response() and get_model_name() methods
3. Add provider-specific configuration in mem0/configs/llms/
4. Register the provider in the configuration factory

class CustomLLM(LargeLanguageModel):
    def __init__(self, model: str = "custom-model", **kwargs):
        self.model = model
    
    def generate_response(self, messages, **kwargs):
        # Implementation
        pass
    
    def get_model_name(self):
        return self.model

Security Considerations

• API keys should be provided via environment variables, not hardcoded
• Rate limiting is handled by the underlying provider APIs
• Azure OpenAI supports managed identity for enterprise deployments
• Gemini supports API key restrictions in Google Cloud Console

Related Pages

Related topics: System Architecture, Embedding Models, Memory Operations

Vector Stores and Storage

Overview

Vector stores in Mem0 provide the foundational persistence layer for semantic memory storage and retrieval. Mem0 supports multiple vector database backends, allowing users to choose the storage solution that best fits their infrastructure requirements, scale needs, and operational constraints.

The vector store system enables:

• Semantic Search: Store memory embeddings and retrieve relevant memories based on cosine similarity
• Multi-Provider Support: Integrate with popular vector databases including Pinecone, Qdrant, Chroma, PGVector, Weaviate, and Redis
• Unified Interface: Consistent API across all providers through an abstract base class
• Metadata Filtering: Filter memories by user_id, agent_id, run_id, and custom metadata
• Scalability: Support for both local development (Chroma) and production-scale deployments (Pinecone, Qdrant)

Sources: docs/components/vectordbs/overview.mdx

Architecture

Mem0 implements a provider-based architecture for vector stores. The system consists of:

1. Base Vector Store Interface: Abstract class defining the contract all providers must implement
2. Provider Implementations: Concrete implementations for each supported vector database
3. Configuration System: Provider-specific configuration management
4. Factory Pattern: Dynamic instantiation based on provider selection

graph TD
    A[Mem0 Memory Core] --> B[VectorStoreFactory]
    B --> C[BaseVectorStore]
    C --> D[Pinecone]
    C --> E[Qdrant]
    C --> F[Chroma]
    C --> G[PGVector]
    C --> H[Weaviate]
    C --> I[Redis]
    
    J[Embedding Service] --> K[Vector Store]
    K --> L[Semantic Search Results]

Sources: mem0/vector_stores/base.py

Base Vector Store Interface

All vector store providers inherit from BaseVectorStore, which defines the core operations required for memory storage and retrieval.

Core Methods

Sources: mem0/vector_stores/base.py

Data Model

Each vector entry in the store contains:

{
    "id": str,           # Unique identifier (UUID)
    "vector": List[float],  # Embedding vector
    "data": str,         # Original text content
    "metadata": {
        "user_id": str,
        "agent_id": Optional[str],
        "run_id": Optional[str],
        "event": Optional[str],
        "created_at": str,
        "memory_type": Optional[str]
    }
}

Sources: mem0/vector_stores/base.py

Supported Providers

Provider Comparison

Sources: docs/components/vectordbs/overview.mdx

Chroma (Development)

Chroma is the default vector store for local development and testing. It runs as an embedded database within the application process.

Characteristics:

• Zero-configuration setup
• In-process operation
• File-based persistence
• Best for development and evaluation

Sources: mem0/vector_stores/chroma.py

Pinecone (Cloud)

Pinecone is a managed vector database service offering serverless and pod-based deployments.

Configuration:

{
    "vector_store": {
        "provider": "pinecone",
        "config": {
            "api_key": "your-api-key",
            "index_name": "mem0-memory",
            "environment": "gcp-starter"
        }
    }
}

Sources: mem0/vector_stores/pinecone.py, docs/components/vectordbs/config.mdx

Qdrant (Self-hosted/Cloud)

Qdrant is an open-source vector search engine with both self-hosted and cloud options.

Configuration:

{
    "vector_store": {
        "provider": "qdrant",
        "config": {
            "host": "localhost",
            "port": 6333,
            "collection_name": "mem0"
        }
    }
}

Sources: mem0/vector_stores/qdrant.py

PGVector (PostgreSQL)

PGVector extends PostgreSQL with vector similarity search capabilities, ideal for applications already using PostgreSQL.

Configuration:

{
    "vector_store": {
        "provider": "pgvector",
        "config": {
            "host": "localhost",
            "port": 5432,
            "dbname": "mem0",
            "user": "postgres",
            "password": "password"
        }
    }
}

Sources: mem0/vector_stores/pgvector.py

Weaviate

Weaviate is an open-source vector database with built-in support for hybrid search and knowledge graphs.

Configuration:

{
    "vector_store": {
        "provider": "weaviate",
        "config": {
            "url": "http://localhost:8080",
            "api_key": "your-api-key",  # Optional, for cloud
            "index_name": "Mem0"
        }
    }
}

Sources: mem0/vector_stores/weaviate.py

Redis

Redis Stack provides vector search capabilities built on the popular in-memory data store.

Configuration:

{
    "vector_store": {
        "provider": "redis",
        "config": {
            "host": "localhost",
            "port": 6379,
            "index_name": "mem0",
            "password": "password"  # Optional
        }
    }
}

Sources: mem0/vector_stores/redis.py

Configuration System

Configuration Schema

The vector store configuration is defined in configs.py and follows a structured schema:

@dataclass
class VectorStoreConfig:
    provider: str                    # Provider name
    collection_name: str             # Collection/index name
    embedding_model_dims: int        # Embedding dimension size
    api_key: Optional[str] = None   # Provider API key
    # ... additional provider-specific fields

Sources: mem0/vector_stores/configs.py

Configuration File

Vector store settings are typically defined in config.yaml:

vector_store:
  provider: "chroma"  # or pinecone, qdrant, pgvector, weaviate, redis
  collection_name: "mem0"
  embedding_model_dims: 1536

Sources: docs/components/vectordbs/config.mdx

Environment Variables

Many providers support configuration via environment variables:

Search Operations

Semantic Search

The primary operation for memory retrieval is semantic search, which finds vectors most similar to a query embedding.

results = vector_store.search(
    query="user's preference for morning coffee",
    limit=5,
    filters={
        "user_id": "user-123"
    }
)

Search Parameters

Sources: mem0/vector_stores/base.py

Metadata Filtering

Mem0 supports filtering search results by various metadata fields:

filters = {
    "user_id": "user-123",           # Required: filter by user
    "agent_id": "agent-456",         # Optional: filter by agent
    "run_id": "run-789",             # Optional: filter by session
    "memory_type": "preference",     # Optional: filter by type
    "created_at": {"$gte": "2024-01-01"}  # Optional: time-based
}

Memory Management

Adding Memories

vector_store.add(
    vectors=embeddings,
    documents=memory_texts,
    metadatas=metadata_list
)

Updating Memories

vector_store.update(
    id="memory-uuid",
    vector=new_embedding,
    data=new_text,
    metadata=updated_metadata
)

Deleting Memories

# Delete single memory
vector_store.delete(id="memory-uuid")

# Delete all memories for a user
vector_store.delete(filters={"user_id": "user-123"})

# Delete all memories
vector_store.delete(delete_all=True)

Embedding Integration

Vector stores work in conjunction with Mem0's embedding service to convert text into vector representations.

graph LR
    A[User Message] --> B[Embedding Service]
    B --> C[Embedding Vector]
    C --> D[Vector Store]
    D --> E[Storage / Retrieval]
    
    F[Search Query] --> G[Embedding Service]
    G --> H[Query Vector]
    H --> D
    D --> I[Similarity Search]
    I --> J[Top-K Results]

The embedding dimension must match the vector store configuration. Mem0 uses 1536 dimensions by default (OpenAI text-embedding-3-small).

Sources: docs/components/vectordbs/overview.mdx

Best Practices

Development vs Production

Performance Considerations

1. Index Management: Ensure proper indexing is configured for your provider
2. Batch Operations: Use batch inserts when adding multiple memories
3. Connection Pooling: Configure connection pools for high-throughput scenarios
4. Embedding Cache: Cache embeddings to avoid redundant computations

Security

• Store API keys in environment variables, not in configuration files
• Use TLS/SSL connections for production deployments
• Implement proper access controls based on user_id filtering

Troubleshooting

Common Issues

Debug Mode

Enable verbose logging for vector store operations:

import logging
logging.getLogger("mem0.vector_stores").setLevel(logging.DEBUG)

See Also

• Memory Core - The main memory orchestration layer
• Embedding Services - Text vectorization
• Configuration Guide - Full configuration reference
• Deployment Guide - Production deployment patterns

Related Pages

Related topics: AI Model Integration, Vector Stores and Storage

Embedding Models

Embedding models are a fundamental component of the mem0 memory system. They transform textual information into dense vector representations (embeddings) that enable semantic search, similarity matching, and efficient memory retrieval. The embedding layer sits at the core of mem0's architecture, bridging raw user interactions with the vector-based storage layer.

Overview

Mem0 provides a flexible, provider-agnostic embedding abstraction that supports multiple embedding backends while maintaining a consistent interface. This design allows users to choose embedding providers based on their requirements for cost, latency, privacy, or quality.

The embedding system in mem0 is built around an abstract base class that defines the contract for all concrete implementations. Each provider implementation handles the specifics of API communication, response parsing, and error handling while conforming to the unified interface.

Key characteristics of mem0's embedding layer:

• Provider-agnostic abstraction with consistent API across implementations
• Support for both cloud-based and local embedding models
• Configuration-driven provider selection
• Seamless integration with the vector storage layer
• Extensible architecture for adding custom embedding providers

Architecture

graph TD
    A[User Input] --> B[Memory Layer]
    B --> C[Embedding Module]
    C --> D[Vector Store]
    
    C --> E[OpenAI Embedder]
    C --> F[Azure OpenAI Embedder]
    C --> G[HuggingFace Embedder]
    C --> H[Ollama Embedder]
    
    E --> I[text-embedding-3-small]
    F --> J[Azure OpenAI Models]
    G --> K[HF Sentence Transformers]
    H --> L[Local Ollama Models]
    
    D --> M[Semantic Search]
    D --> N[Memory Retrieval]
    D --> O[Similarity Matching]

Supported Providers

Mem0 supports multiple embedding providers to accommodate various deployment scenarios. Each provider implements the same abstract interface, allowing transparent switching between backends.

Provider Comparison

Configuration

Embedding models are configured through the mem0 configuration system. Each provider has its own configuration parameters, but all share a common structure.

Basic Configuration

from mem0 import Memory

config = {
    "embedder": {
        "provider": "openai",
        "config": {
            "model": "text-embedding-3-small",
            "api_key": "sk-..."
        }
    }
}

memory = Memory.from_config(config)

Environment Variable Configuration

Many configuration parameters can be set via environment variables, simplifying deployment and reducing boilerplate code:

OpenAI Embeddings

The OpenAI embedder provides access to OpenAI's embedding models through the official API. It is the default provider in mem0 and offers a balance of quality, cost, and ease of use.

Supported Models

Configuration Options

{
    "provider": "openai",
    "config": {
        "model": "text-embedding-3-small",  # Optional, defaults to text-embedding-3-small
        "api_key": "sk-...",                 # Optional if OPENAI_API_KEY is set
        "base_url": "https://api.openai.com/v1",  # Optional, for proxies
        "timeout": 60,                       # Optional, request timeout in seconds
        "max_retries": 3                     # Optional, number of retries on failure
    }
}

Azure OpenAI Embeddings

Azure OpenAI embeddings provide the same model quality as OpenAI with enterprise-grade security, compliance, and regional availability. This is the preferred option for organizations requiring Azure infrastructure.

Configuration Options

{
    "provider": "azure_openai",
    "config": {
        "model": "text-embedding-3-small",    # Model deployment name
        "api_key": "your-azure-api-key",
        "azure_endpoint": "https://your-resource.openai.azure.com",
        "azure_deployment": "your-deployment-name",
        "api_version": "2024-02-01"           # Optional, Azure API version
    }
}

HuggingFace Embeddings

The HuggingFace embedder supports both cloud-based inference and local models from the HuggingFace ecosystem. This provides flexibility for privacy-sensitive applications or cost optimization.

Supported Model Families

Configuration Options

{
    "provider": "huggingface",
    "config": {
        "model": "sentence-transformers/all-MiniLM-L6-v2",  # Model identifier
        "token": "hf_...",           # Optional, for gated models
        "device": "cpu",             # Optional, cpu/cuda/mps
        "encode_kwargs": {          # Optional, encoding parameters
            "normalize_embeddings": True
        }
    }
}

Ollama Embeddings

Ollama enables running embedding models entirely locally, providing complete data privacy and no API costs. This is ideal for development, testing, or production environments with strict data residency requirements.

Supported Models

Configuration Options

{
    "provider": "ollama",
    "config": {
        "model": "nomic-embed-text",        # Model name
        "base_url": "http://localhost:11434" # Ollama server URL
    }
}

Base Interface

All embedding providers inherit from the abstract base class that defines the standard interface:

class EmbedderBase(ABC):
    @abstractmethod
    def embed(self, text: str) -> List[float]:
        """Generate embedding vector for a single text."""
        pass
    
    @abstractmethod
    def embed_batch(self, texts: List[str]) -> List[List[float]]:
        """Generate embedding vectors for multiple texts."""
        pass
    
    @abstractmethod
    def get_vector_size(self) -> int:
        """Return the dimensionality of embedding vectors."""
        pass

Usage Patterns

Single Text Embedding

from mem0 import Memory

memory = Memory()
result = memory.add("User prefers dark mode theme", user_id="user123")

Batch Embedding

from mem0 import Memory

memory = Memory()
messages = [
    "User lives in San Francisco",
    "Prefers coffee over tea",
    "Works as a software engineer"
]
result = memory.add_batch(messages, user_id="user123")

Semantic Search with Custom Embedder

from mem0 import Memory

config = {
    "embedder": {
        "provider": "ollama",
        "config": {
            "model": "nomic-embed-text",
            "base_url": "http://localhost:11434"
        }
    }
}

memory = Memory.from_config(config)
results = memory.search("What are the user's preferences?", user_id="user123")

Extending with Custom Providers

To add a new embedding provider, implement the EmbedderBase abstract class:

from mem0.embeddings.base import EmbedderBase

class CustomEmbedder(EmbedderBase):
    def __init__(self, config: dict):
        self.config = config
        # Initialize your embedding client
    
    def embed(self, text: str) -> List[float]:
        # Implement single text embedding
        pass
    
    def embed_batch(self, texts: List[str]) -> List[List[float]]:
        # Implement batch embedding
        pass
    
    def get_vector_size(self) -> int:
        # Return embedding dimensions
        pass

Best Practices

1. Model Selection: Choose text-embedding-3-small for general use cases as it offers the best balance of quality and cost. Use text-embedding-3-large when higher accuracy is required.

1. Local Deployment: For privacy-sensitive applications, use Ollama with nomic-embed-text to keep all data local.

1. Consistent Embedding Dimensions: Ensure all memories use the same embedding model and configuration for proper similarity calculations.

1. API Key Management: Use environment variables for API keys in production environments rather than hardcoding credentials.

1. Error Handling: Implement appropriate retry logic and timeout settings, especially when using cloud-based embedding providers.

Related Components

• Vector Store: The embedding layer feeds into the vector storage system for efficient similarity search
• Memory Layer: High-level memory operations use embeddings for storage and retrieval
• Configuration System: Centralized configuration management for all embedding providers

Related Pages

Related topics: Memory Operations, TypeScript/Node.js SDK

Python SDK

Overview

The mem0 Python SDK provides a programmatic interface for integrating memory management capabilities into AI applications. It enables developers to store, retrieve, search, and manage persistent memory across AI agent interactions, supporting both self-hosted deployments and managed cloud services.

Sources: mem0/__init__.py:1-50

Architecture

The SDK is structured around three core components that handle different aspects of memory operations:

graph TD
    A[Client Layer] --> B[Memory Layer]
    A --> C[Configuration]
    B --> D[Vector Store]
    B --> E[LLM Integration]
    C --> F[BaseConfig]
    C --> G[LLMConfig]
    C --> H[VectorStoreConfig]

Core Components

Sources: mem0/client/main.py:1-30

Installation

Install the mem0 package along with required dependencies:

pip install mem0ai

For specific LLM and vector store backends, install additional packages:

# OpenAI + Qdrant
pip install mem0ai[openai,qdrant]

# Azure OpenAI + Chroma
pip install mem0ai[azure-openai,chromadb]

Sources: docs/open-source/python-quickstart.mdx:1-50

Quick Start

Basic Memory Operations

from mem0 import Memory

# Initialize memory instance
memory = Memory()

# Add memories
result = memory.add(
    messages=[
        {"role": "user", "content": "I'm planning to visit Tokyo next month."},
        {"role": "assistant", "content": "That's exciting! Tokyo has great places to visit."}
    ],
    user_id="user_123"
)

# Search memories
results = memory.search(
    query="What are my travel plans?",
    user_id="user_123"
)

# Get all memories for a user
all_memories = memory.get_all(user_id="user_123")

# Update a memory
memory.update(memory_id="mem_xxx", data="Updated content here")

# Delete a memory
memory.delete(memory_id="mem_xxx")

Sources: docs/open-source/python-quickstart.mdx:50-100

Configuration

Configuration Parameters

Sources: mem0/configs/base.py:1-80

LLM Configuration

from mem0 import Memory
from mem0.configs.base import LLMConfig

config = LLMConfig(
    provider="openai",
    model="gpt-4o",
    api_key="your-api-key"
)

memory = Memory.from_config(llm_config=config)

Vector Store Configuration

from mem0.configs.base import VectorStoreConfig

vector_config = VectorStoreConfig(
    provider="qdrant",
    host="localhost",
    port=6333,
    collection_name="memories"
)

Sources: mem0/configs/base.py:80-150

Memory Operations API

Adding Memories

The add() method stores new memories from conversation messages:

memory.add(
    messages=[{"role": "user", "content": "User message"}],
    user_id="user_123",
    session_id="session_456",
    metadata={"source": "chat"}
)

Sources: mem0/memory/main.py:100-180

Searching Memories

results = memory.search(
    query="Find information about...",
    user_id="user_123",
    limit=5,
    rerank=True
)

Sources: mem0/memory/main.py:180-250

Retrieving Memories

# Get all memories for a user
all_memories = memory.get_all(user_id="user_123")

# Get specific memory by ID
memory_item = memory.get(memory_id="mem_xxx")

Updating Memories

memory.update(
    memory_id="mem_xxx",
    data="Updated memory content",
    metadata={"key": "value"}
)

Deleting Memories

# Delete specific memory
memory.delete(memory_id="mem_xxx")

# Delete all memories for a user
memory.delete_all(user_id="user_123")

Sources: mem0/memory/main.py:250-350

Client Interface

The Mem0 client provides a unified interface for interacting with mem0 services:

from mem0 import Mem0

# Initialize client
client = Mem0(api_key="your-api-key", app_id="your-app-id")

# Add memories via client
result = client.add(
    messages=[{"role": "user", "content": "Hello"}],
    user_id="user_123"
)

Sources: mem0/client/main.py:1-100

Exception Handling

The SDK defines custom exceptions for error handling:

Sources: mem0/exceptions.py:1-50

Handling Exceptions

from mem0.exceptions import Mem0Exception, ValidationError

try:
    memory.add(messages=[], user_id="user_123")
except ValidationError as e:
    print(f"Invalid input: {e}")
except Mem0Exception as e:
    print(f"Memory operation failed: {e}")

Data Flow

sequenceDiagram
    participant App as Application
    participant SDK as Python SDK
    participant Memory as Memory Engine
    participant Vector as Vector Store
    participant LLM as LLM Provider

    App->>SDK: memory.add(messages)
    SDK->>Memory: process_messages()
    Memory->>LLM: extract_and_summarize()
    LLM-->>Memory: structured_memories
    Memory->>Vector: store(memories)
    Vector-->>Memory: confirm
    Memory-->>SDK: result
    SDK-->>App: MemoryResult

Supported Providers

LLM Providers

Vector Store Providers

Sources: mem0/configs/base.py:150-250

Advanced Configuration

Self-Hosted Deployment

from mem0 import Memory

memory = Memory()

# Configure with custom providers
memory.configure(
    llm={
        "provider": "ollama",
        "model": "llama3.1",
        "api_base": "http://localhost:11434"
    },
    vector_store={
        "provider": "qdrant",
        "host": "localhost",
        "port": 6333
    }
)

Sources: docs/open-source/python-quickstart.mdx:100-150

Embedder Configuration

memory.configure(
    embedder={
        "provider": "openai",
        "model": "text-embedding-3-small",
        "dimension": 1536
    }
)

Best Practices

1. User Identification: Always provide unique user_id for each user to maintain proper memory isolation
2. Session Management: Use session_id to organize memories within conversation threads
3. Metadata: Attach relevant metadata for better searchability and filtering
4. Error Handling: Implement proper exception handling for production applications
5. Configuration: Store API keys securely using environment variables

See Also

• API Reference Documentation
• Open Source Quickstart
• GitHub Repository

Related Pages

Related topics: Python SDK

TypeScript/Node.js SDK

The mem0 TypeScript/Node.js SDK provides a robust client library for integrating memory management capabilities into JavaScript and TypeScript applications. It enables developers to store, retrieve, search, and manage persistent memory across user interactions and AI agent workflows.

Overview

The SDK offers two primary deployment modes:

Sources: mem0-ts/README.md

Architecture

graph TD
    A[Application] --> B[Mem0Client]
    B --> C{Deployment Mode}
    C -->|Hosted| D[mem0ai Cloud API]
    C -->|OSS| E[Local Memory Store]
    D --> F[Vector Database]
    E --> G[SQLite/Vector Store]
    
    H[Mem0Config] --> B
    I[API Key] --> B

The SDK architecture separates configuration management, client initialization, and memory operations into distinct modules. The Mem0Client class serves as the primary interface, accepting a Mem0Config object during instantiation to determine deployment mode and connection parameters.

Sources: mem0-ts/src/client/mem0.ts

Installation

Install the SDK using npm, yarn, or pnpm:

npm install mem0ai
# or
yarn add mem0ai
# or
pnpm add mem0ai

The package name is mem0ai on npm, supporting both CommonJS and ESM module formats.

Sources: mem0-ts/package.json

Configuration

Mem0Config Parameters

OSS Configuration

Sources: mem0-ts/src/client/config.ts

Client Initialization

Hosted Mode

import { Mem0Client } from "mem0ai";

const client = new Mem0Client({
  apiKey: "your-api-key",
  orgId: "your-org-id",    // optional
  projectId: "your-project-id"  // optional
});

Open Source Mode

import { Mem0Client } from "mem0ai";

const client = new Mem0Client({
  embedder: {
    provider: "openai",
    config: {
      api_key: "your-openai-key",
      model: "text-embedding-3-small"
    }
  },
  vectorStore: {
    provider: "chroma",
    config: {
      collection_name: "memory"
    }
  },
  db: {
    provider: "sqlite"
  }
});

Sources: mem0-ts/src/client/index.ts

Core API Methods

Memory Operations

Sources: mem0-ts/src/client/mem0.ts

MemoryResult Data Model

interface MemoryResult {
  id: string;           // Unique memory identifier
  memory: string;       // Memory content text
  event: string;        // Event type (e.g., "memory", "preference", "fact")
  created_at: string;   // ISO timestamp
  updated_at: string;   // ISO timestamp
  metadata?: {          // Optional metadata object
    category?: string;
    source?: string;
    [key: string]: any;
  };
}

Sources: mem0-ts/src/client/mem0.types.ts

Add Memories

// Add a single memory
const memories = await client.add({
  messages: [
    { role: "user", content: "I prefer dark mode in my IDE" },
    { role: "assistant", content: "I'll remember that you prefer dark mode" }
  ],
  userId: "user-123"
});

// With metadata
const memories = await client.add({
  messages: [
    { role: "user", content: "Book a flight to Tokyo next month" }
  ],
  userId: "user-123",
  metadata: {
    category: "travel",
    priority: "high"
  }
});

Search Memories

const results = await client.search({
  query: "What are my IDE preferences?",
  userId: "user-123",
  limit: 5
});

results.forEach(memory => {
  console.log(`${memory.id}: ${memory.memory}`);
  console.log(`Category: ${memory.metadata?.category}`);
});

Get All Memories

const allMemories = await client.getAll({
  userId: "user-123"
});

Update Memory

await client.update({
  memoryId: "memory-uuid-here",
  data: "Updated memory content here",
  metadata: {
    category: "updated-category"
  }
});

Delete Memory

await client.delete({
  memoryId: "memory-uuid-here"
});

Reset User Memories

await client.reset({
  userId: "user-123"
});

Sources: mem0-ts/README.md

Open Source Module Structure

The OSS implementation follows a modular architecture with separate concerns for memory management, embedding, and storage.

graph LR
    A[Mem0Client] --> B[Memory Class]
    B --> C[Embedding]
    B --> D[Vector Store]
    B --> E[SQLite DB]
    C --> F[OpenAI Embeddings]
    D --> G[Chroma/Qdrant/In-Memory]

Memory Class

The Memory class orchestrates the OSS memory operations, coordinating between the embedding service, vector store, and SQLite database.

Sources: mem0-ts/src/oss/src/memory/index.ts

Message Format

The SDK uses a standardized message format for conversation history:

interface Message {
  role: "system" | "user" | "assistant";
  content: string;
}

Messages are processed to extract semantic meaning and stored as discrete memory entries with associated event types.

Sources: mem0-ts/src/oss/src/types/index.ts

Supported Embedders

Sources: mem0-ts/src/client/config.ts

Supported Vector Stores

Event Types

Memories are categorized by event types for organizational purposes:

Sources: mem0-ts/src/client/mem0.types.ts

Workflow Diagram

sequenceDiagram
    participant App as Application
    participant Client as Mem0Client
    participant API as mem0ai API
    
    App->>Client: new Mem0Client(config)
    Note over Client: Initialize with config
    
    App->>Client: add({messages, userId})
    Client->>API: POST /memories
    API-->>Client: MemoryResult[]
    Client-->>App: Promise<MemoryResult[]>
    
    App->>Client: search({query, userId})
    Client->>API: POST /memories/search
    API-->>Client: MemoryResult[]
    Client-->>App: Promise<MemoryResult[]>
    
    App->>Client: getAll({userId})
    Client->>API: GET /memories
    API-->>Client: MemoryResult[]
    Client-->>App: Promise<MemoryResult[]>

Error Handling

The SDK uses standard JavaScript error handling patterns:

try {
  const memories = await client.search({
    query: "test query",
    userId: "user-123"
  });
} catch (error) {
  if (error.status === 401) {
    console.error("Invalid API key");
  } else if (error.status === 404) {
    console.error("Resource not found");
  } else {
    console.error("Request failed:", error.message);
  }
}

Environment Variables

While not required, the SDK supports environment-based configuration:

export MEM0_API_KEY="your-api-key"
export OPENAI_API_KEY="your-openai-key"

TypeScript Support

The SDK is written in TypeScript and provides full type definitions out of the box. No additional @types packages are required.

import { Mem0Client, Mem0Config, MemoryResult, Message } from "mem0ai";

All exported types are available from the main package entry point.

Sources: mem0-ts/src/client/index.ts

Quick Reference

Minimal Hosted Example

import { Mem0Client } from "mem0ai";

const client = new Mem0Client({ apiKey: "your-key" });
const memories = await client.add({
  messages: [{ role: "user", content: "Hello" }],
  userId: "user-1"
});

Minimal OSS Example

import { Mem0Client } from "mem0ai";

const client = new Mem0Client({
  embedder: { provider: "openai", config: { api_key: "key", model: "text-embedding-3-small" } },
  vectorStore: { provider: "chroma", config: { collection_name: "memories" } },
  db: { provider: "sqlite" }
});

Sources: mem0-ts/README.md

Doramagic Pitfall Log

Doramagic extracted 6 source-linked risk signals. Review them before installing or handing real data to the project.

1. Capability assumption: README/documentation is current enough for a first validation pass.

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: The project should not be treated as fully validated until this signal is reviewed.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: capability.assumptions | github_repo:656099147 | https://github.com/mem0ai/mem0 | README/documentation is current enough for a first validation pass.

2. Maintenance risk: Maintainer activity is unknown

• Severity: medium
• Finding: Maintenance risk is backed by a source signal: Maintainer activity is unknown. Treat it as a review item until the current version is checked.
• User impact: Users cannot judge support quality until recent activity, releases, and issue response are checked.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: evidence.maintainer_signals | github_repo:656099147 | https://github.com/mem0ai/mem0 | last_activity_observed missing

3. Security or permission risk: no_demo

• Severity: medium
• Finding: no_demo
• User impact: The project may affect permissions, credentials, data exposure, or host boundaries.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: downstream_validation.risk_items | github_repo:656099147 | https://github.com/mem0ai/mem0 | no_demo; severity=medium

4. Security or permission risk: no_demo

• Severity: medium
• Finding: no_demo
• User impact: The project may affect permissions, credentials, data exposure, or host boundaries.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: risks.scoring_risks | github_repo:656099147 | https://github.com/mem0ai/mem0 | no_demo; severity=medium

5. Maintenance risk: issue_or_pr_quality=unknown

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: Users cannot judge support quality until recent activity, releases, and issue response are checked.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: evidence.maintainer_signals | github_repo:656099147 | https://github.com/mem0ai/mem0 | issue_or_pr_quality=unknown

6. Maintenance risk: release_recency=unknown

• Severity: low
• Finding: release_recency=unknown。
• User impact: Users cannot judge support quality until recent activity, releases, and issue response are checked.
• Recommended check: Open the linked source, confirm whether it still applies to the current version, and keep the first run isolated.
• Evidence: evidence.maintainer_signals | github_repo:656099147 | https://github.com/mem0ai/mem0 | release_recency=unknown

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using mem0 with real data or production workflows.

• Add boto3 timeout configuration support for AWS Bedrock client - github / github_issue
• feat(openclaw): expose Qdrant payload filter in recall path for category - github / github_issue
• Type-Aware Memory Retrieval with Support for Deterministic (Persistent) - github / github_issue
• Why has the Dockerhub Image for the OSS Rest API not been updated - github / github_issue
• Mem0 Python SDK (v2.0.2) - github / github_release
• Mem0 Node SDK (v3.0.2) - github / github_release
• Mem0 OpenClaw Plugin (v1.0.11) - github / github_release
• Mem0 Python SDK (v2.0.1) - github / github_release
• Mem0 Node SDK (v3.0.2) - github / github_release
• Mem0 OpenClaw Plugin (v1.0.10) - github / github_release
• Mem0 OpenClaw Plugin (v1.0.9) - github / github_release
• Mem0 OpenClaw Plugin (v1.0.8) - github / github_release