EverOS: Markdown als Speicher, SQLite und LanceDB als Index

Welches Problem EverOS adressiert und für wen

Die meisten Agenten-Memory-Bibliotheken legen ihren Zustand in einer API, einer Vektordatenbank oder einem Dashboard ab. Der Inhalt ist dann nur über den vorgesehenen Schreibpfad erreichbar. EverOS dreht das um: Die kanonische Quelle sind Markdown-Dateien, die laut README lesbar, editierbar, diffbar und Git-versioniert sind. Die Zielgruppe sind laut Selbstbeschreibung Agenten und Maker, die eine portable Memory-Schicht über Coding-Assistenten, Apps, Geräte und Workflows hinweg wollen. Der Nutzen liegt weniger in einer neuen Retrieval-Technik als in der Eigentumsfrage: Wer die .md-Dateien hat, kann den Speicher ohne EverOS lesen und bearbeiten. Für Teams, die Agenten-Erinnerungen in Code-Reviews oder Backups einbeziehen wollen, ist das ein handfestes Argument. Für reine Chat-Anwendungen, bei denen niemand den Speicher je anfassen will, ist der Dateiansatz vor allem zusätzlicher Aufwand.

Drei Speicherorte und ein Watcher als Datenfluss

Der Datenfluss ist im README als ingest -> extract -> index -> recall beschrieben. Beim Ingest landen Konversationen, Dateien und Agenten-Trajektorien als Markdown auf der Platte. Der Extract-Schritt zieht daraus Einträge, die dann in lokale Indizes wandern: SQLite und LanceDB. SQLite trägt die strukturierten Abfragen, LanceDB die Vektorsuche. Beide sind abgeleitete Artefakte, nicht die Quelle. Auffällig ist die Trennung in zwei Spuren: Nutzerdaten liegen unter episodes und profile, Agentenwissen unter cases und skills. Das sind laut README separate First-Class-Oberflächen, keine Sichten auf dieselbe Tabelle. Dazu kommt ein Watcher, der Dateiänderungen aufnimmt und die Indizes nachzieht. Genau dieser Watcher ist der riskante Teil des Designs: Er ist die Brücke zwischen der manuellen Bearbeitung und dem Index. Wer eine .md-Datei direkt ändert, verlässt sich darauf, dass die Kaskade greift. Ob und wie schnell das in der Praxis passiert, lässt sich aus dem Material nicht belegen.

Orthogonale Abfragen über fünf IDs

EverOS sucht nicht nur in einem Namespace, sondern über user_id, agent_id, app_id, project_id und session_id. Diese Achsen sind orthogonal, das heißt, dieselbe Erinnerung kann über mehrere Kontexte hinweg auffindbar sein, ohne kopiert zu werden. In der Vergleichstabelle des README steht als Gegenmodell die übliche Bindung an App, Namespace, Tenant, Thread oder Graph. Der praktische Unterschied zeigt sich bei mehreren Agenten, die denselben Nutzer betreuen: Ein Agent, der nur innerhalb seiner session_id sucht, verliert den Kontext, den ein anderer Agent im selben project_id angelegt hat. EverOS erlaubt die Abfrage über beide Achsen. Das ist ein Architekturmerkmal, kein Feature-Versprechen. Wer nur einen Agenten mit einem Thread betreibt, gewinnt daraus nichts und trägt die zusätzliche Komplexität der ID-Verwaltung mit.

Installation und der kleinste lauffähige Tier

Die Einrichtung beginnt mit Python 3.12+ und einem OpenRouter-API-Schlüssel. Die Installation läuft über uv pip install everos oder pip install everos. Ein Demo-Befehl, everos demo, benötigt laut README weder Schlüssel noch Server und zeigt den Weg durch ingest, extract, index und recall. Für die echte Nutzung folgt everos init, das ~/.everos/everos.toml und ~/.everos/ome.toml anlegt. In everos.toml steht bereits das Modell openai/gpt-4.1-mini und die base_url https://openrouter.ai/api/v1; zu ersetzen ist nur der leere api_key. Ein abweichender Speicherort ist über everos init --root <path> möglich, wobei derselbe --root bei allen Folgebefehlen mitgegeben werden muss. Der Server startet mit everos server start, die Prüfung erfolgt über curl http://127.0.0.1:8000/health mit der erwarteten Antwort "status":"ok". In dieser Tier-1-Konfiguration meldet capabilities.llm true; embedding und rerank bleiben false, bis sie konfiguriert werden. Das README bricht an dieser Stelle ab, die genauen Schlüssel für Embedding und Rerank sind dem Material nicht zu entnehmen.

Reflection als Offline-Schritt, nicht als Live-Funktion

Das README beschreibt Reflection als Offline-Evolution: Zwischen Sitzungen werden Episode-Cluster zusammengeführt und Profile sowie Skills verfeinert. Das ist ausdrücklich keine Laufzeitfunktion, sondern ein Konsolidierungsschritt außerhalb der aktiven Konversation. Der Vergleich mit anderen Bibliotheken ist an dieser Stelle am deutlichsten, denn dort steht als Gegenpol retrieval-only memory mit wenig Hintergrundkonsolidierung. Die Kehrseite: Wer Erinnerungen sofort nach dem Schreiben in verfeinerter Form erwartet, wird enttäuscht. Die Verbesserung tritt zwischen Sitzungen ein. Ob Reflection standardmäßig aktiv ist oder explizit angestoßen werden muss, geht aus dem vorliegenden README-Ausschnitt nicht hervor. Das ist eine Lücke, die man vor dem Einsatz klären sollte, weil sie bestimmt, ob das System ohne zusätzliche Automatisierung überhaupt lernt.

Der Knowledge Wiki und die Frage der doppelten Pflege

Neben der Memory-Schicht bietet EverOS einen Knowledge Wiki: editierbare, quellenbelegte Markdown-Seiten mit Taxonomie, CRUD-APIs und Themensuche. Das README stellt ihn als eigenständige Oberfläche dar, nicht als Teil der Memory-Suche. Damit entsteht eine zweite Kuratierungsebene. Wer beides nutzt, pflegt Erinnerungen und Wissensseiten getrennt, auch wenn beide auf Markdown basieren. Der Vorteil ist, dass Wissensseiten sich auf Quellen beziehen lassen und nicht in einem Dashboard eingeschlossen sind. Der Preis ist, dass die Frage offen bleibt, wann ein Episodeninhalt in den Wiki gehört und wann er einfach Erinnerung bleibt. Das README liefert dazu keine Regel. Wer den Wiki produktiv einsetzen will, muss diese Grenze selbst ziehen.

Grenzen, Lizenz und Wartungskosten

Die harte Grenze ist die Abhängigkeit von OpenRouter für den LLM-Schritt. Wer keinen externen Schlüssel einsetzen darf, kann den vollen Funktionsumfang nicht nutzen; die Demo läuft ohne Schlüssel, der produktive Pfad nicht. Die zweite Grenze ist die Umgebungsvoraussetzung Python 3.12+. Die dritte ist der Watcher: Er ist die einzige Absicherung dafür, dass direkte Dateiänderungen im Index ankommen. Wer diesen Pfad umgeht oder den Dienst nicht laufen lässt, arbeitet auf veralteten Indizes. Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung und Änderung erlaubt; die Pflichten aus der Lizenz (unter anderem Hinweise auf Änderungen und die Beibehaltung von Lizenz- und Urheberrechtshinweisen) sind im Repository selbst nachzulesen, eine rechtliche Bewertung ist hier nicht möglich. Zur Wartung: Die letzten Releases v1.3.1 und v1.3.0 liegen laut Repository im September 2026, davor v1.2.3 im August 2026. Das deutet auf einen kurzen Release-Zyklus hin, was bei einem jungen Projekt auch bedeutet, dass sich Konfigurationsschlüssel und Befehle zwischen Versionen bewegen können. Wer auf einer festen Version aufsetzt, sollte die Upgrade-Pfade vor einem Sprung prüfen.

Alternativen und wann EverOS das falsche Werkzeug ist

Als Alternative nennt das README ausdrücklich die Klasse der Agent-Memory-Bibliotheken, die ihren Zustand in API, Vektor-, Graph- oder Dashboard-Strukturen halten und auf verwaltete Dienste wie MongoDB, Elasticsearch oder Redis setzen. Der Unterschied liegt nicht in der Suchqualität, sondern im Betriebsmodell: EverOS braucht laut README keinen dieser Dienste, dafür aber ein Dateisystem, einen laufenden Prozess für den Watcher und einen LLM-Anbieter. Wer bereits eine Vektor-Datenbank im Betrieb hat und Erinnerungen nur als weitere Collection darin ablegen will, gewinnt durch EverOS wenig und verliert die Einheitlichkeit seines Stacks. Umgekehrt ist EverOS das falsche Werkzeug, wenn Erinnerungen ausschließlich maschinell geschrieben und nie inspiziert werden. Der Markdown-Zwischenlayer bringt dann nur Schreiblast und einen zusätzlichen Konsistenzpfad. Sinnvoll ist er dort, wo Menschen die Dateien lesen, ändern oder versionieren.

Redaktionelles Fazit

Wer eine lokale, diffbare und Git-versionierbare Memory-Schicht für Agenten sucht, findet in EverOS ein nachvollziehbares Modell: .md-Dateien als Quelle, SQLite und LanceDB als abgeleitete Indizes. Wer einen reinen Retrieval-Store ohne Dateisystem-Semantik braucht oder keinen OpenRouter-Schlüssel einsetzen will, sollte Abstand nehmen. Vor dem Einsatz ist zu prüfen, ob der Watcher bei direktem Editieren der .md-Dateien tatsächlich zuverlässig kaskadiert und ob die Reflection in der eigenen Konfiguration aktiv ist.

Offizielle Quellen

1. EverMind-AI/EverOS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases