Your Agent's Memory Shouldn't Be Trapped in a Database
If you've ever tried to debug why your agent "remembers" something wrong, you know the pain. The memory lives in some vector store or dashboard you can't easily inspect, let alone edit. You end up poking at API endpoints just to fix a bad fact. EverOS takes a different approach: it stores agent memory as plain Markdown files you can open, read, and edit like any other doc.
What It Does
EverOS is a Python library and local-first memory runtime for agents and makers. It gives you one portable memory layer across coding assistants, apps, devices, and workflows. Conversations, files, and agent trajectories get stored as readable Markdown, and then it syncs local SQLite and LanceDB indexes underneath for fast retrieval.
The architecture is deliberately simple: Markdown is the source of truth, with SQLite and LanceDB handling the indexing. No MongoDB, Elasticsearch, or Redis required. It separates user memory (episodes and profiles) from agent memory (cases and skills) as distinct first-class surfaces, and lets you retrieve across several dimensions—user_id, agent_id, app_id, project_id, and session_id.
Why It's Cool
The Markdown-as-source-of-truth decision is the whole ballgame. Because your memory is just .md files, it's readable, editable, diffable, and versionable in Git. That means you can actually inspect what your agent knows, fix a bad entry by hand, and see changes in a diff. Most memory libraries bury this in vector state or a dashboard; here it's a text file.
Direct file editing with cascade sync. You don't need an SDK or API call to update memory. Edit the .md file, and a watcher syncs the changes down into the indexes. That's a small detail with big implications for debugging and manual curation.
A genuinely local stack. Markdown plus SQLite plus LanceDB means you can run the whole thing on your machine without standing up managed services. For local-first workflows and single-developer projects, that's a meaningful reduction in operational overhead.
Separate tracks for users and agents. Splitting user episodes/profile from agent cases/skills is a thoughtful design choice. These are different kinds of knowledge, and treating them as separate surfaces rather than mashing everything into one chat-history blob makes retrieval and reasoning cleaner.
Reflection as offline evolution. EverOS includes offline memory evolution that merges episode clusters and refines profiles and skills between sessions. That's consolidation happening in the background rather than retrieval-only memory that never improves—a nice nod to how long-horizon memory should actually work.
A Knowledge Wiki tied back to sources. There's an editable, source-backed Markdown knowledge wiki with taxonomy, CRUD APIs, and topic search. Unlike wikis trapped in a dashboard, these pages stay connected to the underlying files.
How to Try It
EverOS is a Python library, so you'll want a Python environment ready. Start by grabbing the repo and checking the documentation for setup specifics:
git clone https://github.com/evermind-ai/everos
cd everos
From there, the project points you to its documentation and quick start guide for installation and basic usage. Since the runtime is local-first, you won't need to provision external databases—the SQLite and LanceDB indexes are managed for you.
The README also lists ecosystem integrations for adding durable memory to various agent and workflow platforms, and notes that EverOS comes built into Raven. If you're wiring it into an existing assistant, check those integration guides first.
Full details and the latest setup instructions live in the repo: github.com/evermind-ai/everos.
Final Thoughts
EverOS is aimed at developers who want their agent's memory to be inspectable and editable—people who'd rather open a Markdown file than query a vector database when something goes wrong. The local-first three-part stack keeps things simple to run, and the user/agent split plus offline reflection show real thought about how memory should evolve over time. If you're building agents and tired of opaque memory backends, this is worth a look.
Follow @githubprojects for more developer tools and open source projects.