How to Use EverOS: A Local Framework for Long-Term AI Agent Memory

EverMind-AI/EverOS is an open-source Python framework for adding long-term memory to AI agents and chat applications. Its goal is not to build yet another chatbot, but to organize conversations, agent trajectories, and file knowledge into structured, retrievable, evolving memory.

The most interesting part is its storage design: EverOS does not lock memory into a black-box database. Instead, it treats Markdown as the Source of Truth. You can open it, edit it, grep it, version it with Git, or even view it in Obsidian.

What Problem It Solves

For many agents, “memory” is really just short-term context:

It remembers today and forgets tomorrow;
One tool knows something another tool does not;
User preferences, project experience, and failure cases are scattered across chat logs;
RAG can search files, but does not necessarily preserve lived experience;
Once the memory system depends on complex databases, maintenance costs rise for small teams.

EverOS aims to be a lighter long-term memory substrate. It separates user-side memory from agent-side memory: users have Profiles, Episodes, Facts, and Foresights; agents have Cases and Skills. This is more than remembering a sentence. It allows people, tasks, experience, and procedures to accumulate over time.

Technical Structure

The README states EverOS’s core principles clearly:

Markdown as Source of Truth: all memory eventually lands in .md files;
Lightweight three-piece storage: Markdown + SQLite + LanceDB;
EverAlgo handles memory extraction algorithms, while EverOS orchestrates and persists.

The storage layout roughly looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


~/.everos/
├── default_app/
│   └── default_project/
│       ├── users/<user_id>/
│       │   ├── user.md
│       │   ├── episodes/
│       │   ├── .atomic_facts/
│       │   └── .foresights/
│       └── agents/<agent_id>/
│           ├── agent.md
│           ├── .cases/
│           └── skills/
└── .index/
    ├── sqlite/system.db
    └── lancedb/*.lance/

Markdown is the source of truth, SQLite manages state and queues, and LanceDB manages vectors, BM25, and scalar filters. This stack is much lighter than a full MongoDB, Elasticsearch, Milvus, Redis, and Kafka setup, and it is better suited to individual developers and small teams.

Quick Start

Installation is straightforward:

1
2
3


uv pip install everos
# or
pip install everos

Initialize the configuration:

1

everos init

Then start the service:

1

everos server start

EverOS has an OpenAI-protocol-compatible endpoint stack, so it can connect to OpenAI, OpenRouter, vLLM, Ollama, DeepInfra, and similar services. You only need to adjust the relevant BASE_URL and API keys in .env.

For non-text content such as images, PDFs, audio, and Office documents, install the multimodal extra:

1

uv pip install 'everos[multimodal]'

Office document conversion depends on LibreOffice. Without LibreOffice, PDF, image, and audio processing are unaffected, but .doc, .docx, .ppt, .pptx, .xls, and .xlsx Office files will fail to process.

Suitable Scenarios

EverOS is better suited to:

AI coding assistants remembering project conventions, past mistakes, and common workflows;
Sharing long-term memory across multiple agents;
Personal chat assistants remembering preferences, experiences, and long-term goals;
Internal knowledge assistants that combine file knowledge with conversational experience;
Research, data analysis, and operations tasks that need case accumulation across sessions;
Keeping memory in local files instead of handing it entirely to a cloud platform.

It is less suitable for simple FAQs. A normal RAG system is enough for that. The value of EverOS is that memory grows richer through use, rather than only searching static documents.

Usage Boundaries

Long-term memory sounds beautiful, but it has traps:

Remembering wrong is more dangerous than forgetting, so memory extraction needs human verification;
User privacy and sensitive information must be viewable, deletable, and exportable;
Agents should not blindly trust old conclusions just because memory exists;
Isolation between users, projects, and agents must be designed carefully;
Editable Markdown is an advantage, but it also means you need to handle index sync after manual edits.

So EverOS is better treated as infrastructure than as a final product. At the application layer, you still need to decide what can be remembered, when it is remembered, how long it is kept, who can read it, and how mistakes are corrected.

Summary

EverOS has a very appealing design: use Markdown as the source of truth, use SQLite and LanceDB as indexes, and pull long-term memory back from black-box databases into a readable, editable, versionable file system.

If you are building AI agents, personal assistants, coding assistants, or multi-agent platforms, and you have already hit the problem of “the conversation ends and everything is forgotten,” EverOS is worth studying. It is not a universal brain, but it provides a practical prototype of a memory operating system.

References

EverMind-AI/EverOS - GitHub