Meet EverOS: An Open Source Markdown-First Agent Memory Runtime With Hybrid BM25 + Vector Retrieval and Self-Evolving Skills
EverMind has released EverOS , an open-source memory runtime for AI agents.

An Open Source Markdown-First Agent Memory Runtime With Hybrid BM25 + Vector Retrieval and Self-Evolving Skills">
EverMind has released EverOS , an open-source memory runtime for AI agents. It ships under an Apache 2.0 license. It targets a problem agent builders hit early: large language models are stateless. The conversation ends, and the context is gone.
EverOS proposes a different substrate. Instead of locking memory inside a vector database, it writes memory as plain Markdown files. Those files become the source of truth that agents read, edit, and search across sessions.
EverOS is a Python library and a local-first memory runtime. It runs as a server with a CLI and a FastAPI HTTP API, async-first throughout. You drop it into an existing agent loop rather than rebuilding your stack.
The design separates two memory tracks. User-side memory holds Profiles, Episodes, Facts, and Foresights. Agent-side memory holds Cases and Skills. Keeping them separate is unusual; most libraries center on chat history alone.
Every record lands as a .md file. You can open, edit, grep, and Git-version it, or view it in Obsidian. EverAlgo, a separate stateless library, handles the extraction algorithms. EverOS orchestrates and persists the results.
The endpoint stack is OpenAI-protocol compatible. It connects to OpenAI, OpenRouter, vLLM, Ollama, or DeepInfra by changing a base URL. That keeps integration close to a single configuration change.
The runtime is local-first by default. Data never has to leave your environment, and every layer is inspectable. A managed EverOS Cloud option exists for teams that prefer not to self-host. Both share the same SDK, retrieval engine, and memory format.
EverOS uses a three-piece storage stack. Markdown is the source of truth. SQLite manages state and queues. LanceDB manages vectors, BM25, and scalar filters.
This is deliberately lighter than a typical production memory setup. There is no required MongoDB, Elasticsearch, Milvus, Redis, or Kafka. For solo developers and small teams, that lowers operational cost.
Retrieval is hybrid. A single LanceDB query combines BM25 keyword matching, dense vector search, and scalar filtering. EverMind markets this multimodal retrieval path as mRAG.
A cascade index sync keeps files and indexes aligned. Editing a .md file triggers a file-watcher that re-syncs the index. Memory stays inspectable without going stale.
Source: MarkTechPost