@yyyole: Agent memory entrepreneurship is booming! Many teams are working on it, with several mainstream approaches: The first, most brute-force: context expansion. The second, most common: RAG/vector database route, embedding historical content into a vector store for retrieval. The third is product-oriented: memory API route, packaging memory as an API for direct calls. Each approach has its clear pros and cons!

X AI KOLs Timeline Tools

Summary

Introduces several mainstream approaches to Agent memory entrepreneurship, recommends the EverMind team's open-source project EverOS, which provides a Markdown-sourced local memory OS supporting dual-track memory, multimodal ingestion, and self-evolution capabilities.

Agent memory entrepreneurship is booming! Many teams are working on it, with several mainstream approaches: The first, most brute-force: context expansion — simply growing the context window. The second, most common: RAG/vector database route — connecting a vector store to embed and retrieve historical content. The third is product-oriented: memory API route — packaging memory as an API for direct use. Each approach has its clear pros and cons! The direction I increasingly favor is EverOS, recently open-sourced by the EverMind team on GitHub. Well worth watching — I hit star early! GitHub repo: https://github.com/EverMind-AI/EverOS… They propose a fourth approach, with this solution: Turn memory into a readable, editable, version-managed knowledge layer that both humans and agents can maintain together. Not by building another agent, but by building the infrastructure that agents truly lack: a memory layer. I think EverOS has several practical and standout features: First, it uses Markdown as the memory source. Memories are stored as Markdown, so you can open, read, edit, and manage them directly — even put them in Obsidian. Both humans and agents can read it, making it auditable! Second, two parallel memory tracks. - User memory answers: "Who is this person, what are their preferences, what has happened in the past?" - Agent memory answers: "What tasks have I done, which workflows are effective, what mistakes should I avoid repeating?" This design is crucial! Separating these two types of memory makes permissions, retrieval, migration, and reuse much smoother, with almost no surprises. Third, a very practical local stack. Local trilogy: "Markdown + SQLite + LanceDB" — runs locally yet supports structured filtering, BM25, and vector search. Fourth, multimodal ingestion. This is far more practical than supporting only chat history, because user context never lives just in chat windows. It can be in text, images, web pages, meeting recordings, emails, and code repos — all formats can be unified into searchable memory. Fifth, self-evolution capability. This is my favorite. Many teams end up making it a standalone product! EverOS doesn't just "store and retrieve" memories. It extracts common cases and skills from real-world usage, turning recurring work patterns into reusable capabilities — so the agent doesn't have to rediscover everything each time. EverOS's overall approach feels like the direction next-generation agents will go: Memory isn't just recall; it should make the system gradually understand tasks, users, and itself better. Of course, Agent memory still has many challenges: What to remember, what to forget, how to avoid false memories, permission isolation, measuring memory quality, handling privacy and synchronization, etc. These still need better solutions — and precisely because these problems aren't fully solved yet, open-source projects deserve more builders to participate, try them out, file issues, and build demos. So if you're a capable developer, keep an eye on this. The world needs more builders ~
Original Article
View Cached Full Text

Cached at: 06/22/26, 07:39 AM

The entrepreneurial direction of Agent memory is booming! Many teams are working on it, with roughly the following mainstream approaches:

The first, most brute-force: the context route, simply growing the context window.

The second, most common: the RAG / vector database route, connecting a vector store to embed historical content and then retrieve it.

The third, a product mindset: the memory API route, packaging memory as an API for direct calls.

All three directions have obvious pros and cons!

The direction I increasingly agree with is the project recently open-sourced by the EverMind team on GitHub: EverOS. It’s very worth paying attention to — I starred it early on!
GitHub repo: https://github.com/EverMind-AI/EverOS…

They propose a fourth approach, with the solution being:
Make memory a readable, editable, version-managed knowledge layer that can be maintained by both humans and agents.
It’s not about building another Agent — it’s about building the infrastructure layer that Agents truly lack: the memory layer.

I think EverOS has several particularly practical and standout features:

First, using Markdown as the memory source.
Memory is saved as Markdown. You can open, read, edit, and manage it directly, even put it in Obsidian. Both humans and agents can read it — it’s inspectable!

Second, two parallel memory tracks.
User memory answers: “Who is this person, what are their preferences, what happened in the past?”
Agent memory answers: “What tasks have I done, which processes are effective, which mistakes should I avoid repeating?”
This design is important! Separating these two types of memory makes permissions, retrieval, migration, and reuse much smoother, and almost never causes issues.

Third, a very pragmatic local stack.
The local triad — “Markdown + SQLite + LanceDB” — can run locally while supporting structured filtering, BM25, and vector retrieval.

Fourth, multimodal ingestion.
This is far more practical than only supporting chat history, because user context never exists solely in the chat box. It may be in text, images, web pages, meeting recordings, emails, and code repositories. Different formats can all be unified into searchable memory.

Fifth, self-evolving capability.
This is my favorite part — many teams have turned this into a standalone product!
EverOS doesn’t just “store and retrieve” memory. It can also extract common cases and skills from real usage, turning recurring work patterns into reusable capabilities instead of making the Agent figure everything out from scratch each time.

EverOS as a whole feels like it will become the direction for next-generation Agent deployment:
Memory is not just recall — the system should gradually become more knowledgeable about tasks, users, and itself.

Of course, Agent memory still has many challenges:
For example, what to remember and what not to remember, how to avoid false memories, permission isolation, measuring memory quality, handling privacy and synchronization, and so on.
These still need better solutions. And precisely because these problems aren’t fully solved yet, open-source projects deserve more builders to participate, try them out, file issues, and create demos.

So, to all capable developers out there — feel free to keep an eye on it.
The world needs more builders ~


EverMind-AI/EverOS

Source: https://github.com/EverMind-AI/EverOS

EverOS banner

Website (https://evermind.ai) · Documentation (https://docs.evermind.ai) · Blog (https://evermind.ai/blogs) · 中文

Table of Contents

EverOS 1.0.0

EverOS 1.0.0 is a major release for self-evolving memory. It brings a
local-first runtime, Markdown as the source of truth, hybrid retrieval,
multimodal ingestion, user and agent memory scopes, and modular algorithms
through EverAlgo (https://github.com/EverMind-AI/EverAlgo).
Coming next: Knowledge Wiki will turn memory into editable,
source-backed Markdown knowledge pages. Reflection will run when the
system is idle or offline to connect signals, compress
history, and improve profiles and skills between sessions.

Why Ever OS

EverOS is the local memory operating system for agents and makers. It gives one portable memory layer across coding assistants, apps, devices, and workflows. Today it stores conversations, files, and agent trajectories as readable Markdown, then syncs local SQLite and LanceDB indexes for fast retrieval and self-evolving reuse.

TitleEverOSOther Agent Memory Libraries
Markdown source of truth✅ Canonical .md files that are readable, editable, diffable, and Git-versioned❌ Usually API, vector, graph, dashboard, or database state
Direct file editing✅ Edit .md files; cascade watcher syncs❌ Usually SDK, API, dashboard, or backend update paths
Local three-part stack✅ Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required❌ Often depends on managed services, vector DBs, graph DBs, or server stacks
User + agent tracks✅ User episodes/profile and agent cases/skills are separate first-class surfaces❌ Usually centered on chat history, profiles, entities, facts, or retrieval records
Orthogonal retrieval✅ Search by user_id, agent_id, app_id, project_id, and session_id❌ Usually app, namespace, tenant, thread, or graph scoped
Knowledge Wiki✅ Coming next: editable, source-backed Markdown knowledge pages built from memory❌ Usually retrieval, graph, dashboards, or generated summaries instead of editable source-backed pages
Reflection✅ Coming next: Reflection that runs when the system is idle or offline to connect signals, compress history, and improve profiles and skills between sessions❌ Usually online read/write APIs, retrieval records, or summaries rather than idle-time memory consolidation

Quick Start

Goal: start EverOS, write one memory, and search it back.

0. Prerequisites

  • Python 3.12+
  • API keys for the default providers: OpenRouter for chat / multimodal, and DeepInfra for embedding / rerank. You can use other OpenAI-compatible providers by changing the matching *__BASE_URL fields in .env.

1. Install

``bash
uv pip install everos

or: pip install everos

``

2. Configure

Generate a starter .env file, then fill the four API key slots shown in the generated comments. Only two distinct keys are needed with the defaults: OpenRouter for LLM / MULTIMODAL, and DeepInfra for EMBEDDING / RERANK.
``bash
everos init

or, from a source checkout:

cp .env.example .env
``
everos init writes ./.env by default. Use everos init --xdg to write ${XDG_CONFIG_HOME:-~/.config}/everos/.env instead.

3. Start EverOS

bash everos server start
Keep the server running, then open a second terminal and check it:
bash curl http://127.0.0.1:8000/health
Expected response:
json {"status":"ok"}
everos server start searches for .env in this order: --env-file <file>./.env (cwd) → ${XDG_CONFIG_HOME:-~/.config}/everos/.env~/.everos/.env.
The endpoint stack is OpenAI-protocol compatible (OpenAI / OpenRouter / vLLM / Ollama / DeepInfra) - override *__BASE_URL in the generated .env to point at any of them.

4. Try Your First Memory

Add a tiny conversation:
bash TS=$(($(date +%s)*1000)) curl -X POST http://127.0.0.1:8000/api/v1/memory/add \ -H 'Content-Type: application/json' \ -d "{ \"session_id\": \"demo-001\", \"app_id\": \"default\", \"project_id\": \"default\", \"messages\": [ {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $TS, \"content\": \"I love climbing in Yosemite every spring.\"}, {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $((TS+10000)), \"content\": \"My favorite coffee shop is Blue Bottle in SOMA.\"} ] }"
Force extraction for the local demo:
bash curl -X POST http://127.0.0.1:8000/api/v1/memory/flush \ -H 'Content-Type: application/json' \ -d '{"session_id":"demo-001","app_id":"default","project_id":"default"}'
Search it back:
bash curl -X POST http://127.0.0.1:8000/api/v1/memory/search \ -H 'Content-Type: application/json' \ -d '{ "user_id": "alice", "app_id": "default", "project_id": "default", "query": "Where do I like to climb?", "top_k": 5 }'
You should see the Yosemite memory in the response. If the result is empty on the first try, wait a moment and retry; Markdown is written synchronously, while the local index catches up in the background.

First memory unlocked.
You just gave EverOS a fact, flushed it into durable Markdown-backed memory,
and searched it back through the local index. That is the core loop.
Want to see the source of truth? Open ~/.everos and inspect the generated
Markdown files.

For annotated responses and the Markdown files EverOS creates, see QUICKSTART.md.

Optional: Ingest Multimodal Files

To ingest non-text content (image / pdf / audio / office documents) through /api/v1/memory/add content items, install the optional extra:
``bash
uv pip install ‘everos[multimodal]’

or: pip install ‘everos[multimodal]’

``
This pulls in everalgo-parser (with the [svg] bundle for SVG support via cairosvg) and wires up the multimodal LLM client (EVEROS_MULTIMODAL__* fields in .env, defaults to google/gemini-3-flash-preview via OpenRouter).

Office document support requires LibreOffice as a system dependency. The parser shells out to soffice (LibreOffice’s headless renderer) to convert .doc / .docx / .ppt / .pptx / .xls / .xlsx to PDF before feeding the result into the multimodal LLM. Without LibreOffice, office uploads return HTTP 415 with a clear error message; PDF / image / audio / HTML / email parsing is unaffected. Install on the host before serving office documents:
bash brew install --cask libreoffice # macOS sudo apt-get install -y libreoffice # Debian / Ubuntu

For Contributors

bash git clone https://github.com/EverMind-AI/EverOS.git cd EverOS uv sync # creates ./.venv and installs deps source .venv/bin/activate # or prefix commands with `uv run` everos init # fill the four API key slots in .env (two distinct keys) everos --help make test

Use Cases

Now that you have had your first successful EverOS moment, explore what people are building with persistent memory across agents, apps, and community integrations. Use cases show what persistent memory makes possible in real products and workflows. Some examples are packaged in this repository; others point to external demos or integrations you can study and adapt.

  • banner-gif (https://evermind.ai/usecase_reunite)

Reunite - Find With EverOS

Parents describe what they remember. Children describe what they recall. Reunite uses semantic memory to surface the connections. Learn more

  • banner-gif (https://github.com/tt-a1i/hive)

Hive Orchestrator

Browser-native hive-mind for CLI coding agents - Claude Code, Codex, Gemini, and OpenCode collaborate as real PTY processes via a team protocol. Code

  • banner-gif (https://github.com/tt-a1i/evermemos-mcp)

AI Coding Assistants With EverOS

Universal long-term memory layer for AI coding assistants, powered by EverOS. Code

  • banner-gif (https://github.com/yuansui123/AI-Data-Technician-EverMemOS)

AI Data Technician

An agentic AI system that learns from scientist interaction to inspect, analyze, and classify high-dimensional time series data - with persistent memory that improves across sessions. Code

  • banner-gif

Rokid AI Assistant With EverOS

Connect to EverOS within Rokid Glasses enabling long-term memory for all of your smart activities. Coming soon

  • banner-gif

Creative Assistant With Memory

Creative assistant with long-term memory, so your creative context stays available across sessions. Coming soon

  • banner-gif (https://github.com/xunyud/Earth-Online)

Earth Online Memory Game

Earth Online is a memory-aware productivity game that turns everyday planning into a living quest log. Code

  • banner-gif (https://github.com/golutra/golutra)

Multi-Agent Orchestration Platform

Golutra presents a multi-agent workforce for engineering teams, extending the IDE model from a single assistant to coordinated agents. Code

  • banner-gif (https://github.com/Yangtze-Seventh/taste-verse)

Your Personal Tasting Universe

Record, visualize, and explore your tasting journey through an immersive 3D star map. Code

  • banner-gif (https://github.com/kellyvv/OpenHer)

EverOS Open Her

Build AI that feels. Open-source persona engine - personality emerges from neural drives, not prompts. Inspired by Her. Code

  • banner-gif (https://chromewebstore.google.com/detail/ruminer-browser-agent/lbccjohfpdpimbhpckljimgolndfmfif)

Browser Agent For Personal Memory

Ruminer brings persistent memory to a browser agent so it can carry personal context across web tasks. Plugin

  • banner-gif (https://github.com/nanxingw/EverMem)

EverMem Sync With EverOS

One command to connect any AI coding CLI to EverMemOS long-term memory. Code

  • banner-gif (https://github.com/mco-org/mco)

MCO - Orchestrate AI Coding Agents

MCO equips your primary agent with an agent team that can work together to solve complex tasks. Code

  • banner-gif (https://github.com/onenewborn/StudyBuddy-public)

Study Buddy With Self-Evolving Memory

Study proactively with an agent that has self-evolving memory. Code

  • banner-gif (https://github.com/TonyLiangDesign/MemoCare)

Alzheimer’s Memory Assistant

Empowering individuals with advanced memory support and daily assistance. Code

  • banner-gif (https://github.com/AlexL1024/NeuralConnect)

Memory-Driven Multi-Agent NPC Experience

An iOS sci-fi mystery game where players explore and uncover the truth. Code

  • banner-gif (https://github.com/elontusk5219-prog/Mobi)

Mobi Companion

An iOS app where users create, nurture, and live with a personalized AI companion called Mobi. Code

  • banner-gif (https://github.com/JaMesLiMers/EvermemCompetition-Spiro)

AI Wearable With Memory

A context-native AI wearable that listens to everyday life and converts conversations into memory. Code

Legacy OpenClaw Agent Memory

Archived pre-1.0.0 plugin reference. New integrations should use the EverOS 1.0.0 API. Learn more

  • banner-gif (https://github.com/TEN-framework/ten-framework/tree/04cb80601374fa9e35b4e544b2dbd23286ca7763/ai_agents/agents/examples/voice-assistant-with-EverMemOS)

Live2D Character With Memory

Add long-term memory to a real-time Live2D character, powered by TEN Framework (https://github.com/TEN-framework/ten-framework). Code

  • banner-gif (https://screenshot-analysis-vercel.vercel.app/)

Computer-Use With Memory

Run screenshot-based analysis with computer-use and store the results in memory. Live Demo

Game Of Thrones Memories

A demonstration of AI memory infrastructure through an interactive Q&A experience with A Game of Thrones. Code

Claude Code Plugin

Persistent memory for Claude Code. Automatically saves and recalls context from past coding sessions. Code

  • banner-gif (https://main.d2j21qxnymu6wl.amplifyapp.com/graph.html)

Memory Graph Visualization

Explore stored entities and relationships in a graph interface. Frontend demo; backend integration is in progress. Live Demo

Architecture At A Glance

┌───────────────────────────────────────────────┐ │ entrypoints/ (CLI + HTTP API) │ presentation ├───────────────────────────────────────────────┤ │ service/ (use cases: memorize/retrieve) │ application ├───────────────────────────────────────────────┤ │ memory/ (extract + search + cascade) │ domain ├───────────────────────────────────────────────┤ │ infra/ (markdown / sqlite / lancedb) │ infrastructure └───────────────────────────────────────────────┘ ↑ ↑ component/ core/ (LLM/Embedding) (observability/lifespan)
DDD 5 layers, single-direction dependency. See docs/architecture.md.

Storage Layout

``
~/.everos/
├── default_app/ # app_id (“default” → “default_app” on disk)
│ └── default_project/ # project_id (“default” → “default_project”)
│ ├── users/<user_id>/
│ │ ├── user.md # profile
│ │ ├── episodes/ # daily-log episodes (visible)
│ │ ├── .atomic_facts/ # nested facts (dotfile-hidden)
│ │ └── .foresights/ # predictive memory (dotfile-hidden)
│ └── agents/<agent_id>/
│ ├── agent.md
│ ├── .cases/ # one task case per entry
│ └── skills/ # named procedural memories
├── .index/ # derived indexes (rebuildable from md)
│ ├── sqlite/system.db # state +

Similar Articles

@9hills: After trying many Agent Memory implementations, I found only two that are somewhat useful: 1. Hermes-style strictly length-limited entry-level memory and session recall, used to address personal assistant memory needs. But this has nothing to do with coding. 2. Skills precipitated from trajectories and skill evolution...

X AI KOLs Timeline

The author shares insights after trying various Agent Memory implementations, concluding that only strictly length-limited entry-level memory (like Hermes) and skill evolution based on trajectory precipitation are somewhat useful, while other graph-based or card-based methods are ineffective.

@WY_mask: Build persistent memory engine for all kinds of AI coding assistants http://github.com/rohitg00/agentmemory… Silently records code changes and context in the background, automatically extracts and compresses into structured memory, saves Token consumption from long context, associates past information, as…

X AI KOLs Timeline

agentmemory is an open-source tool that provides persistent memory for AI coding assistants. It silently records code changes and context, automatically extracts and compresses them into structured memory, reduces Token consumption, and supports multiple mainstream platforms such as Claude Code and Codex.

@RookieRicardoR: MemOS has made new progress. There are quite a few AI Memory solutions now, but many are still at the level of storing chat history. It looks like memory, but it's essentially adding a semantic search to markdown. @MemOS_dev has been working on a memory system for a while, from 1.0 all the way...

X AI KOLs Timeline

MemOS Local Plugin 2.0 update has been released, introducing the "Learn by Doing" feature, which allows the agent to convert key steps during task execution into reusable, scorable cognitive assets, thereby achieving continuous learning and memory in the local environment.