Agent Memory Runtime EverOS setzt auf Markdown-First
EverMind hat am 29. Juni 2026 EverOS veröffentlicht, eine Open-Source-Agent Memory Runtime, die als Markdown-First-Ansatz KI-Agenten ein persistenteres Gedächtnis über Sessions hinweg verleiht. Das ist relevant, weil die meisten Agent-Stacks auf langweilige, teure Weise scheitern, sobald der Kontext verloren geht: Wiederholungsversuche steigen, Übergaben werden unübersichtlich und jede Aufgabe fängt wieder bei Null an. Laut MarkTechPosts Bericht vom 29. Juni über EverOS wird EverOS unter Apache 2.0 veröffentlicht und kombiniert Markdown-Dateien, SQLite und LanceDB für persistentes Gedächtnis.
EverMind veröffentlicht EverOS für persistentes Agenten-Gedächtnis
Aus Implementierungssicht ist EverOS kein vollständiges Agent-Framework. Es handelt sich um eine Python-Bibliothek und einen lokalen Runtime, den man in eine bestehende Schleife einbinden, über FastAPI exponieren und auf Model-Backends ausrichten kann, die bereits das OpenAI-Protokoll sprechen. Genau diese engere Ausrichtung macht die Veröffentlichung bemerkenswert.
Das Problem, das EverOS adressiert, ist bekannt. In einem Kundenprototyp, an dem ich letzten Monat gearbeitet habe, bewältigte das Modell einen Support-Workflow gut für die ersten 20 Minuten, vergaß dann aber kundenspezifische Präferenzen in der zweiten Session und begann, nach Informationen zu fragen, die es bereits gesehen hatte. Das Modell war in Ordnung; die Memory-Schicht war zu dünn. EverOS zielt genau auf diese Lücke ab: persistentes Gedächtnis für KI-Agenten, ohne alles in einen einzigen Vektor-Store zu zwingen.
MarkTechPost fasst das Pitch treffend zusammen: EverOS behandelt Gedächtnis als editierbare Dateien statt als versteckte Datenbankeinträge. Das ist ein praktischer Unterschied, nicht nur eine Design-Präferenz. Wenn Gedächtnis eine Datei ist, kann ein Engineer sie inspizieren, diffen, versionieren und reparieren, ohne eine weitere Admin-Oberfläche erfinden zu müssen.
Markdown wird zur Single Source of Truth für Agenten-Gedächtnis
Das Ungewöhnliche ist die Single Source of Truth. EverOS schreibt Gedächtniseinträge als einfache .md-Dateien, während eine Begleitbibliothek, EverAlgo, die Extraktionslogik übernimmt. Das bedeutet, dass Profile, Episoden, Fakten, Vorausschauen, Fälle und Skills alle in einem Format vorliegen, das ein Mensch direkt öffnen kann. Wenn Ihr Team bereits Git, Shell-Tools oder Notizsysteme wie Obsidian nutzt, ist das Betriebsmodell sofort nachvollziehbar.
Das gefällt mir besser als erwartet. In der Produktion sind Gedächtnis-Bugs oft zunächst keine Retrieval-Bugs, sondern State-Shape-Bugs. Eine Präferenz wurde doppelt zusammengeführt. Ein Benutzer-Identitätsschlüssel ist abgedriftet. Ein Extraktionsschritt hat sich auf eine Phrase überangepasst. Diese Probleme in Embeddings zu verstecken, macht ihre Diagnose langsamer. Die Speicherung des kanonischen Zustands in Markdown gibt Teams einen einfacheren Debugging-Pfad.
Darunter gibt es dennoch Indizierung. EverOS nutzt File-Watching und eine Sync-Cascade, damit Änderungen an Markdown die Suche nicht veralten lassen. Das ist der Teil, den ich in einem Piloten hart testen würde, besonders wenn mehrere Agenten oder Worker gleichzeitig schreiben können. Lokal-First klingt sauber, bis gleichzeitige Schreibzugriffe, partielle Fehler und Queue-Lags auftauchen.
Eine verwandte Design-Entscheidung ist die Scope-Isolation. Suchen können nach user_id, agent_id, app_id, project_id und session_id eingeschränkt werden. Für Enterprise-Automation ist das eine Selbstverständlichkeit. Wenn ich das in einen Live-Workflow einbinden würde, würde ich diese Grenzen vor jedem Benchmark-Diagramm prüfen.
Teams, die evaluieren, wie dies in einen breiteren Delivery-Stack passt, werden sich wahrscheinlich weniger für die Markdown-Neuheit interessieren als dafür, wie schnell es sich in echte Workflows integrieren lässt. Hier ist ein Dienst wie AI Business Process Automation der beste Fit: EverOS ist am nützlichsten, wenn Gedächtnis eine Komponente innerhalb eines größeren automatisierten Prozesses ist, nicht ein Science-Project für sich.
Wie EverOS SQLite, LanceDB, BM25 und Vektoren kombiniert
Unter der Haube ist der Storage-Stack bewusst schlank. Markdown ist die Single Source of Truth. SQLite übernimmt Zustand und Queues. LanceDB übernimmt Vektoren, BM25 und skalare Filterung. Im Vergleich zu schwereren Memory-Stacks, die Redis, Elasticsearch, Kafka und eine separate Vektor-Datenbank einbinden, ist das ein leichterer Footprint für ein kleines Team.
Der zentrale Retrieval-Anspruch ist die hybride Suche in einer Abfrage: BM25 für Keyword-Präzision, dichte Vektoren für semantische Ähnlichkeit und skalare Filter für Metadaten-Grenzen. Wer je erlebt hat, wie reine Vektor-Suche einen exakten Produktcode oder einen Kundennamen verpasst, weil das Embedding ein breiteres Konzept höher gewichtet hat, weiß, warum BM25 immer noch wichtig ist. Hybride BM25-Vektor-Suche ist nicht aufsehenerregend, aber sie behebt sehr reale Fehlermodi.
Laut dem Quellenartikel bezeichnet EverMind diesen kombinierten Pfad als multimodale Retrieval-Augmented Generation, oder mRAG. Die Mechanik ist wichtiger als das Label. Die Frage ist, ob Ihre Abfragen überwiegend semantisch, überwiegend lexikalisch oder gemischt sind. In Support-Logs, Compliance-Texten und technischer Fehlerbehebung sind sie meist gemischt.
Hier sieht EverOS auch stärker aus als reine Prompt-Memory. Mehr Historie in das Kontextfenster zu werfen funktioniert, bis Kosten, Latenz oder Attention Decay zubeißen. Eine Retrieval-Schicht mit exakter Term-Matching und eingrenzbarer Suche altert meist besser, als einfach nur den Prompt größer zu machen.
Fälle werden in EverOS zu Skills
Das interessantere Feature ist das prozedurale Gedächtnis. EverOS speichert abgeschlossene Aufgaben als Cases und destilliert wiederholte erfolgreiche Muster in wiederverwendbare Skills. Ich würde das weniger als Self-Improvement-Magie und mehr als Workflow-Kompression beschreiben. Wenn ein Agent wiederholt die gleiche Aufgabenklasse löst, ist die Erhaltung des erfolgreichen Pfads nützlicher als die ewige Speicherung von Roh-Transkripten.
Dennoch wäre ich hier am skeptischsten. Destillations-Pipelines können abdriften. Sie können sich aus einer kleinen Stichprobe übergeneralisiert, brüchige Schritte beibehalten oder eine schlechte Entscheidung weitertragen, die in einem Kontext zufällig erfolgreich aussah. EverOS Version 1.1.0 ergänzt Lifecycle-Komponenten wie Knowledge APIs und Reflection, um Profile, Episoden und Skills zwischen Sessions zu verfeinern – das ist die richtige Richtung. Aber ich würde trotzdem Audits wünschen, wie ein Case zu einem Skill wird und wie einfach ein Rollback ist.
Der Quellenartikel fasst das Gedächtnismodell einfach zusammen: Episodisches Gedächtnis protokolliert, was passiert ist, Profil-Gedächtnis protokolliert, wer der Benutzer ist, und prozedurales Gedächtnis protokolliert, wie eine Aufgabe erledigt wird. Das ist eine nützliche Trennung. Die meisten Teams beginnen mit Chat-Verlauf und merken zu spät, dass Aufgaben-Gedächtnis und Benutzer-Gedächtnis nicht in einen undifferenzierten Log gemischt werden sollten.
Wo EverOS im Vergleich zu naivem RAG und vollen Kontextfenstern steht
EverOS ist am besten für Teams geeignet, die bereits eine Agent-Schleife haben und ein kleineres, inspizierbares Memory-Subsystem benötigen. Gegenüber naivem RAG ist der Gewinn nicht nur Vektoren plus BM25, sondern die Kombination aus menschlich lesbarem Zustand, Metadaten-Scoping und einer prozeduralen Memory-Schicht. Gegenüber Full-Context-Ansätzen ist der Gewinn Persistenz und Selektivität.
Aber die Trade-offs sind real. Datei-basierte Truth ist einfacher zu inspizieren, aber schwieriger zu governen, wenn Benennung, Schemas und Schreibdisziplin schlampig sind. SQLite hält den Stack kompakt, aber man muss trotzdem über Concurrency-Limits und Recovery-Prozeduren nachdenken. LanceDB reduziert Stack-Sprawl, aber man verpflichtet sich dennoch, Indexierung und Retrieval-Qualität über Zeit zu betreiben.
Positiv ist, dass der Runtime einfach zu pilotieren scheint. MarkTechPost nennt Python 3.12+, eine lokale Demo, einen FastAPI-Server und OpenAI-kompatible Endpoints, die auf OpenAI, OpenRouter, vLLM, Ollama oder DeepInfra mit einer Base-URL-Änderung umgeleitet werden können. Das senkt die Integrationskosten für Teams, die Gedächtnis testen wollen, ohne zuerst die Model-Schicht umzubauen.
Was Teams vor der Einführung von EverOS prüfen sollten
Die Benchmark-Zahlen sind vielversprechend, aber noch nicht allein entscheidungsreif. Der Quellenartikel zitiert von EverMind gemeldete Scores von 93,05% auf LoCoMo, 83,00% auf LongMemEval, 93,04% auf HaluMem und eine p95-Retrieval-Latenz von unter 500 ms. Ich würde diese als Ausgangspunkt, nicht als Beweis betrachten. Führen Sie die gleichen Tests mit Ihrer eigenen Workload-Form durch, besonders wenn Ihre Daten lange technische Threads, strenze Tenancy-Grenzen oder Sessions mit vielen Schreibzugriffen enthalten.
Was ich als Nächstes beobachten würde, ist, ob Early Adopters nicht nur Erfolgsgeschichten, sondern auch Fehlerberichte veröffentlichen. Wenn EverOS die Memory-Schicht unter echter Multi-Agent-Last inspizierbar hält, könnte sich das Markdown-First-Design durchsetzen. Falls nicht, könnte die Idee dennoch beeinflussen, wie Teams die nächste Generation von Agent Memory Runtimes bauen, auch wenn sie Teile des Stacks austauschen.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation