Open Source Project of the Day (Part 36): EverMemOS - A Long-Term Memory OS for Agents Across LLMs and Platforms

A deep dive into EverMemOS, EverMind-AI's open-source Agent long-term memory system — achieving 93% reasoning accuracy on the LoCoMo benchmark through structured extraction, intelligent retrieval, and progressive profiling, with multi-modal memory and production-grade deployment support

·11 min read·AI Tools
Open SourceEverMemOSLong-term MemoryAI AgentPythonMilvusElasticsearchMongoDBFastAPIRAG

Introduction

"More than memory — it's foresight."

This is Part 36 of the "Open Source Project of the Day" series. Today we explore EverMemOS (GitHub).

Conversational Agents with only "current turn" context forget everything between sessions and can't share state across platforms — making true long-term companionship and personalization difficult. EverMemOS is EverMind-AI's open-source long-term memory operating system: structurally extracting memories from conversations (Encoding), organizing and consolidating them by episodes and profiles (Consolidation), and intelligently retrieving them for context injection when needed (Retrieval) — supporting memory types including episodic memory, facts, preferences, and relationships. It achieves 93% reasoning accuracy on the LoCoMo long-context memory benchmark, uses production-grade components like Milvus, Elasticsearch, MongoDB, and Redis, integrates with any LLM via a REST API, and is designed as a cross-LLM, cross-platform Agent memory foundation.

Why it's worth checking out:

  • 🎯 93% LoCoMo accuracy: Leading performance on the long-context memory and reasoning benchmark
  • 🏗️ Production-grade stack: Milvus vector store, Elasticsearch, MongoDB, Redis — enterprise-ready
  • 🔌 Easy integration: REST API, model-agnostic, works with any LLM
  • 📊 Multi-modal memory: Episodes, Facts, Preferences, Relations
  • 🔍 Multiple retrieval methods: BM25, vector, hybrid, Agentic retrieval — configurable
  • 📄 Paper and documentation: Architecture overview, API docs, Demo, evaluation guide

What You'll Learn

  • EverMemOS's positioning and three-stage pipeline (Encoding → Consolidation → Retrieval)
  • Multi-modal memory types and retrieval strategies (lightweight vs. Agentic)
  • Quick start: Docker + uv, environment variables, starting the service and health checks
  • Basic API usage: writing memories, retrieving by query
  • Demo and evaluation: simple_demo, extract_memory, chat_with_memory; LoCoMo/LongMemEval/PersonaMem
  • Project structure, key configuration, and extension directions (Memory Genesis Competition 2026)

Prerequisites

  • Basic understanding of LLMs, Agents, and RAG
  • Familiarity with vector retrieval and BM25 is helpful
  • Local requirements: Python 3.10+, Docker 20.10+, uv, ~4GB RAM

Project Background

Project Introduction

EverMemOS's slogan is "Long-term memory OS for your agents across LLMs and platforms". It addresses the problem of Agents lacking cross-session, cross-platform, reasoning-capable long-term memory.

Through three pipelines:

  1. Encoding: Extracts structured memories (events, facts, preferences, relationships, etc.) from conversations
  2. Consolidation: Organizes memories into Episodes and Profiles for long-term maintenance and updates
  3. Retrieval: Intelligently retrieves relevant memories by query and injects into context when needed, supporting BM25, vector, hybrid, and Agentic strategies

This realizes "not just remembering what happened, but understanding the meaning of memories and using them to guide decisions." Achieves 93% reasoning accuracy on the LoCoMo (Long-Context Memory) benchmark, outperforming similar memory systems.

Target users:

  • Developers who need to add long-term memory to conversational Agents
  • Architects who want memory decoupled from LLMs and platforms for reusability
  • Products and researchers needing multi-modal memory (episodes, facts, preferences, relationships) and multiple retrieval methods
  • Teams pursuing production-grade deployment (vector stores, search engines, persistence)

Author/Team Introduction

  • Team: EverMind-AI (evermind.ai)
  • Repository: EverMind-AI/EverMemOS
  • Community: Discord, WeChat, X, LinkedIn, Hugging Face, Reddit (see README)
  • Recent: Hosting Memory Genesis Competition 2026 (tracks: Agent+Memory, Platform Plugins, OS Infrastructure, etc.)

Project Stats

  • ⭐ GitHub Stars: ~2.3k
  • 🍴 Forks: ~246
  • 📦 Version: v1.2.0 (API enhancements and DB efficiency improvements, see Changelog)
  • 📄 License: Apache-2.0
  • 🌐 Website: evermind.ai
  • 📚 Documentation: Quick Start, Configuration, API Usage, Development, Memory API, Demo, Evaluation

Tech stack: Python (~99.9%), Docker, FastAPI, MongoDB, Elasticsearch, Milvus, Redis.

Main Features

Core Purpose

EverMemOS's core purpose is to provide Agents with cross-LLM, cross-platform long-term memory capabilities, including:

  1. Memory writing: Write individual or batched conversations/messages into the system, triggering extraction and storage
  2. Structured extraction: Use LLMs to extract Episodes, Facts, Preferences, Relations, etc. from natural language
  3. Organization and consolidation: Organize memories by episodes and user/entity profiles, supporting incremental updates
  4. Intelligent retrieval: Retrieve relevant memories by natural language query, supporting BM25, vector, hybrid, Agentic
  5. REST API: Standard HTTP interface for connecting with frontends, any LLM, or platforms

This enables Agents to maintain "memorable, retrievable, usable" memory across multi-turn, multi-session, multi-device scenarios.

Use Cases

  1. Conversational assistants

    • User preferences, historical topics, and important facts preserved across sessions — responses become more consistent and personalized

  2. Customer service and support

    • Record user issues, resolutions, device/account information — automatically bring relevant memories on next contact

  3. Personal/team knowledge Agents

    • Distill documents, meetings, and conversations into episodes and facts — retrieve and augment generation on demand

  4. Multi-Agent collaboration

    • Shared or role-isolated memory layer — different Agents reuse the same memory OS

  5. Research and evaluation

    • Reproduce and compare memory/reasoning performance on LoCoMo, LongMemEval, PersonaMem, and other benchmarks

Quick Start

Requirements: Python 3.10+, Docker 20.10+, uv, 4GB RAM.

# 1. Clone and enter directory
git clone https://github.com/EverMind-AI/EverMemOS.git
cd EverMemOS
 
# 2. Start Docker dependencies (MongoDB, Elasticsearch, Milvus, Redis, etc.)
docker compose up -d
 
# 3. Install uv and project dependencies
curl -LsSf https://astral.sh/uv/install.sh | sh
uv sync
 
# 4. Configure API keys
cp env.template .env
# Edit .env: LLM_API_KEY (for memory extraction), VECTORIZE_API_KEY (for vectorization/reranking), etc.
 
# 5. Start service
uv run python src/run.py
 
# 6. Health check
curl http://localhost:1995/health
# Expected: {"status": "healthy", ...}

Service runs at http://localhost:1995 by default. See Getting Started for complete steps.

Basic API Usage

Write a conversation memory:

import requests
 
API_BASE = "http://localhost:1995/api/v1"
 
# Write a single message (system extracts and stores)
requests.post(f"{API_BASE}/memories", json={
    "message_id": "msg_001",
    "create_time": "2025-02-01T10:00:00+00:00",
    "sender": "user_001",
    "content": "I love playing soccer on weekends"
})

Retrieve memories by query:

# Retrieve memories related to "what sports the user likes"
response = requests.get(f"{API_BASE}/memories/search", json={
    "query": "What sports does the user like?",
    "user_id": "user_001",
    "memory_types": ["episodic_memory"],
    "retrieve_method": "hybrid"  # Options: bm25, embedding, hybrid, agentic, etc.
})
 
result = response.json().get("result", {})
for memory_group in result.get("memories", []):
    print(memory_group)

For more examples and complete API, see the API Usage Guide and Memory API.

Core Features

  1. 93% LoCoMo accuracy

    • Outperforms existing memory systems on long-context memory and single-hop/multi-hop reasoning benchmarks

  2. Production-grade infrastructure

    • Milvus: Vector storage and retrieval
    • Elasticsearch: Full-text/keyword retrieval (e.g., BM25)
    • MongoDB: Structured memory and metadata
    • Redis: Caching and sessions

  3. LLM-agnostic

    • Integrates via REST API — any LLM or platform can act as the "frontend," with the memory layer uniformly provided by EverMemOS

  4. Multi-modal memory

    • Episodes: Episodic memory (what happened, when, where)
    • Facts: Factual memory
    • Preferences: User preferences
    • Relations: Relationships between entities

  5. Multiple retrieval strategies

    • BM25, vector retrieval, hybrid, Agentic (Agent decides retrieval and reranking) — choose lightweight or strong reasoning per scenario

  6. Group chat and metadata

    • Supports multi-speaker conversations and session metadata control for group, channel, and thread scenarios

  7. Batch processing and evaluation

    • Batch write and evaluation scripts supporting LoCoMo, LongMemEval, PersonaMem, and other benchmarks

  8. Docker + uv

    • One-click startup of dependency services, Python environment managed by uv for easy local and CI reproduction

Project Advantages

ComparisonEverMemOSConversation history / simple KVCustom vector + RAG
Memory structureMulti-modal (episodes/facts/preferences/relations)Mostly raw textImplementation-dependent
Reasoning capabilityLoCoMo 93%, specifically optimized for memory reasoningNo benchmarkSelf-testing required
Retrieval methodsBM25 + vector + hybrid + AgenticMostly keyword or simple vectorSelf-developed
Production componentsMilvus + ES + MongoDB + RedisOften single-machine/single-DBSelf-selected
Integration methodREST API, LLM-agnosticOften tied to a specific LLMArchitecture-dependent
Documentation and evaluationFull documentation + multi-benchmark reproductionMinimalProject-dependent

Why choose EverMemOS?

  • Focused on "long-term memory OS" — closes the loop from extraction, organization to retrieval, backed by papers and benchmarks
  • Production-grade components and API design, suitable as a direct product memory layer or for secondary development
  • Cross-LLM, cross-platform — build once, use across multiple endpoints
  • Active open-source community with competitions and multilingual community (Discord, WeChat, etc.)

Detailed Project Analysis

Architecture Overview (Three Stages)

The core pipeline from README and documentation:

  1. Encoding

    • Input: Conversation messages (individual or batch)
    • Process: Calls LLM for structured extraction, yielding Episodes, Facts, Preferences, Relations, etc.
    • Output: Structured memories written to storage (MongoDB, etc.), vectors written to Milvus, full text to Elasticsearch (configurable)

  2. Consolidation

    • Organizes memories by episodes and profiles (Profiles)
    • Supports incremental updates, deduplication, and merging to form a long-term usable memory graph

  3. Retrieval

    • Input: Natural language query, user_id, memory types, retrieval method, etc.
    • Process: BM25 (ES) + vector (Milvus) + optional reranking and Agentic decision
    • Output: List of relevant memories for the caller to inject into LLM context

Overall, EverMemOS acts as a "memory middleware layer" between the conversation/frontend and LLM: the frontend or Agent writes messages into EverMemOS, retrieves from EverMemOS when needed, and injects the results into the prompt before calling the LLM.

Project Structure (Overview)

  • src/: Core service entry (e.g., run.py), API, encoding/consolidation/retrieval logic
  • data/, data_format/: Sample data and data format documentation
  • demo/: simple_demo, extract_memory, chat_with_memory and other scripts
  • docs/: Development documentation, configuration, API, architecture overview
  • evaluation/: LoCoMo, LongMemEval, PersonaMem evaluation scripts and documentation
  • config.json, env.template: Service and dependency configuration
  • docker-compose.yaml: MongoDB, Elasticsearch, Milvus, Redis, etc.

Retrieval Strategies Overview

  • BM25: Elasticsearch-based keyword/full-text retrieval — good for exact terms and proper nouns
  • Embedding: Vector retrieval — good for semantic similarity and paraphrases
  • Hybrid: Combines BM25 and vector — commonly used as a default balanced solution
  • Agentic: LLM/Agent participates in retrieval or reranking — good for complex queries and multi-step reasoning, at higher cost

Selected via retrieve_method and other API parameters. See the API documentation for details.

Demo and Evaluation

Running the simple Demo:

# Terminal 1: Start API
uv run python src/run.py
 
# Terminal 2: Run simple demo
uv run python src/bootstrap.py demo/simple_demo.py

Full experience: First run extract_memory.py to extract memories from sample data, then chat_with_memory.py for interactive conversation with memory. See the Demo Guide for details.

Evaluation (LoCoMo example):

uv sync --group evaluation
uv run python -m evaluation.cli --dataset locomo --system evermemos --smoke  # Quick smoke test
uv run python -m evaluation.cli --dataset locomo --system evermemos          # Full evaluation
cat evaluation/results/locomo-evermemos/report.txt

See the Evaluation Guide for details.

Key Configuration Notes

  • .env: Copied from env.template, requires LLM_API_KEY (for extraction) and VECTORIZE_API_KEY (for vectorization/reranking); other service addresses use Docker Compose defaults.
  • config.json: Service port, storage connections, default retrieval parameters, etc. See the Configuration Guide.

Memory Genesis Competition 2026

An open-source competition hosted by EverMind-AI, with tracks including: Agent + Memory (agents with long-term memory), Platform Plugins (VSCode, Chrome, Slack, Notion, LangChain integrations, etc.), OS Infrastructure (core features and performance optimization). Form teams and get a Starter Kit via Discord. See README for details.

Project Resources

Official Resources

Related Resources

  • Paper and vision: Paper, Vision & Overview, Architecture linked in README
  • DeepWiki: Ask DeepWiki for AI Q&A about the repository
  • GitHub Codespaces: Supported on 4-core+ machines for immediate use — see README

Who Should Use This

  • Agent and conversational system developers: Need long-term memory, multi-modal memory, and reproducible benchmarks
  • Architects: Designing a unified memory layer for multiple LLMs and platforms
  • Researchers: Conducting experiments and comparisons on memory, reasoning, and RAG
  • Competition and plugin developers: Participating in Memory Genesis 2026 or building VSCode/Chrome/LangChain integrations

Welcome to visit my personal homepage for more useful knowledge and interesting products

← Back to Blog