EverOS: A Markdown-First Memory Layer for AI Agents
One portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.
At a glance
- What is it?
- EverOS stores agent memories as editable Markdown files and syncs local SQLite and LanceDB indexes for retrieval. This review covers its architecture, setup, and where its local-first approach fits or falls short.
- Who is it for?
- Adopt EverOS if you want an agent memory system that is human-readable and versionable, and if you can live with its local-first stack and the need for an OpenRouter key for LLM features. Skip it if you need managed cloud storage or if your agents run in environments that cannot run a local server process.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Why a Portable Memory Layer Matters
AI agents often lack continuity between sessions. Each conversation starts fresh, and past decisions or user preferences are lost. EverOS addresses this by providing a single memory layer that works across coding assistants, apps, and workflows. The target user is a developer or maker who builds agents and wants them to remember facts, conversations, and trajectories in a way that is not locked into a single vendor's API. The README emphasizes that memory should be user-owned and editable. That is a specific stance: instead of treating memory as an opaque database, EverOS makes it a set of Markdown files you can open in any text editor.
The Markdown-First Architecture
The core idea is that Markdown files are the canonical source of truth. Conversations, files, and agent trajectories are stored as readable .md files. These files are diffable and can be versioned with Git. A cascade watcher monitors the files and syncs them into local SQLite and LanceDB indexes. This gives you fast retrieval while keeping the source material human-readable. The README contrasts this with other agent memory libraries that rely on API state, vector databases, or dashboard-backed storage. Direct file editing is a first-class operation: you can edit a .md file and the watcher picks up the change. This design is refreshing because it avoids vendor lock-in and makes debugging easier. You can inspect exactly what the agent remembers by reading a file.
Separating User and Agent Tracks
EverOS distinguishes between user memory and agent memory. User data lives in episodes and profiles, while agent knowledge is stored in cases and skills. This separation is more than organizational. It reflects a real difference in how memory is used. A profile might hold a user's preferences, while a skill encapsulates a procedure the agent has learned. The README claims this is a first-class surface, unlike other libraries that focus only on chat history or facts. Retrieval is orthogonal: you can search by user_id, agent_id, app_id, project_id, or session_id. That flexibility is useful when you run multiple agents or apps against the same memory store. You can isolate one agent's cases from another's, or pull up all sessions for a single user.
Getting Started: Commands and Configuration
Installation is straightforward. The README shows uv pip install everos or pip install everos. A standalone demo runs with everos demo and requires no API key. That demo lets you enter a fact and then ask a question to see the ingest, extract, index, and recall pipeline. For a full setup, you run everos init. This creates configuration files at ~/.everos/everos.toml and ~/.everos/ome.toml. The generated config includes a model and base URL for OpenRouter. You only need to replace the empty api_key. The README gives an example with model = "openai/gpt-4.1-mini" and base_url = "https://openrouter.ai/api/v1". After that, everos server start launches the server. You can check health with curl http://127.0.0.1:8000/health and look for "status":"ok". The setup is minimal, but it assumes you have an OpenRouter key for LLM-dependent features.
The Two-Tier Storage Trade-off
EverOS uses both SQLite and LanceDB. The README calls this a local three-part stack: Markdown plus SQLite plus LanceDB. It avoids heavy dependencies like MongoDB or Redis. That is a benefit for local-first deployments. But it also means you run two index systems. SQLite handles structured metadata, while LanceDB likely handles vector or embedding search. The README notes that embeddings and rerank are false until you configure them. So the default experience is keyword search only. That is a limitation if you need semantic retrieval out of the box. You must decide whether the added complexity of LanceDB is justified by your retrieval needs. For simple keyword search, SQLite alone might suffice, but EverOS couples them.
Reflection and Self-Evolving Memory
A distinctive feature is offline reflection. The README describes it as memory evolution that merges episode clusters and refines profiles and skills between sessions. This is not real-time. It happens offline, presumably as a batch process. The idea is that after many sessions, the system consolidates similar episodes and updates the user or agent models. This is more than retrieval-only memory. Most agent memory libraries just store and fetch. EverOS attempts to improve the memory content over time. However, the README does not specify when reflection runs or how you trigger it. That is a gap. You know it exists, but not how to operationalize it. That could be a manual command or a scheduled job. The documentation likely covers it, but the README leaves it vague.
Ecosystem Integrations and Built-In Raven
EverOS is not a standalone tool. It integrates with agent platforms like DeepSeek Harness, Hermes, OpenClaw, and Dify. The README says it comes built into Raven, which appears to be another EverMind project. Each integration has a setup guide. This is a practical approach. You can use EverOS as a library in your own Python agents, or you can plug it into an existing platform. The integrations are listed with links to the plugins repository. That suggests the project is part of a broader ecosystem. If you already use one of those platforms, EverOS may offer a drop-in memory solution. If you use a platform not listed, you will need to build your own integration using the Python API.
Limitations and Wrong Use Cases
The main limitation is the local-first design. EverOS runs as a local server and stores files on your machine. That is wrong for teams that need shared memory across distributed agents. There is no mention of multi-user sync or cloud hosting. If you need memory that is accessible from multiple machines or by multiple users, you would have to build that yourself. Another limitation is the dependency on OpenRouter for LLM features. If you prefer a different LLM provider or want to run models locally, the configuration only shows OpenRouter. The README says one OpenRouter API key is enough, but that is a constraint. Also, the cascade watcher is a background process. If it fails or misses a file edit, your indexes may become stale. The README does not describe recovery mechanisms for such events.
Alternatives and Comparison
A common alternative is a vector database like Chroma or Pinecone used directly for agent memory. Those tools store embeddings and support semantic search, but they do not provide a Markdown source of truth. You would store raw text or chunks, and the memory is opaque. Another alternative is Mem0, which is a memory layer for AI agents that uses a graph or vector store. Mem0 focuses on extracting facts and user preferences, but it does not expose the memory as editable files. The key difference is that EverOS treats memory as a human-readable artifact that you can edit and version. Alternatives treat memory as a black box that you interact with via API. If you value inspectability and Git versioning, EverOS stands out. If you only need fast semantic retrieval, a direct vector store may be simpler.
Maintenance and License Implications
EverOS is licensed under Apache-2.0. That is permissive, allowing commercial use and modification. You can fork it and integrate it into proprietary products, as long as you preserve the license notice. There is no copyleft obligation. The project is under active development, with releases v1.2.3 in August 2026 and v1.3.1 in September 2026. That suggests a fast release cadence. You should expect API changes between minor versions. The documentation site is separate, so you will need to track changes there. The dependency on OpenRouter and the two-index architecture means ongoing maintenance. You must keep the server running and the watcher healthy. Upgrades may require re-indexing or config changes. The project is not archived, which is a good sign, but you should verify that the maintainers respond to issues in a timely manner.
Editorial conclusion
Adopt EverOS if you want an agent memory system that is human-readable and versionable, and if you can live with its local-first stack and the need for an OpenRouter key for LLM features. Skip it if you need managed cloud storage or if your agents run in environments that cannot run a local server process. Before adopting, verify that the cascade watcher reliably syncs your Markdown edits in your workflow, and test whether the keyword search meets your retrieval needs without embeddings. The project's active release schedule and Apache-2.0 license are positive signals, but you must assess whether the two-tier setup (SQLite plus LanceDB) adds operational complexity you are willing to maintain.
Community notes