## Die Konvergenz, die niemand geplant hat

Manus ist ein verbraucherorientierter KI-Agent. Claude Code ist der Codierungsassistent von Anthropic. OpenClaw ist eine persönliche Open-Source-KI. Unterschiedliche Teams, unterschiedliche Codebasen, unterschiedliche Geschäftsmodelle.

Alle drei speichern den Agentenspeicher in Markdown-Dateien.

Manus verwendet eine „todo.md“-Checkliste, die sich nach jedem Schritt neu schreibt. OpenClaw verwendet „MEMORY.md“ plus datierte Dateien in einem „memory/“-Verzeichnis. Claude Code verwendet hierarchische „CLAUDE.md“-Dateien, die auf Verzeichnisse beschränkt sind, mit einer Obergrenze von 200 Zeilen für immer geladene Inhalte.

Keiner schien den anderen zu kopieren. [Yaohua Chen in der DEV-Community](https://dev.to/imaginex/ai-agent-memory-management-when-markdown-files-are-all-you-need-5ekk) nannte dies „konvergente Evolution“. Wenn drei unabhängige Systeme unter unterschiedlichen Einschränkungen zur gleichen Architektur gelangen, verrät Ihnen die Architektur etwas über das Problem.

Micheal Lanham [dokumentierte diese Konvergenz](https://medium.com/@Micheal-Lanham/the-markdown-file-that-beat-a-50m-vector-database-38e1f5113cbe) im März 2026. Seine Analyse aller drei Systeme ist der gründlichste öffentliche Vergleich von Speicherarchitekturen für Produktionsagenten, den ich je gesehen habe. Es lohnt sich, sich direkt mit den Daten auseinanderzusetzen.

## Warum Dateien der Standardstartpunkt sind

Die offensichtliche Erklärung ist Einfachheit. Dateien sind für Menschen lesbar, git-verfolgbar und erfordern keine Infrastruktur. Stimmt, aber unvollständig.

Der tiefere Grund liegt in der LLM-Ökonomie.

Manus-Mitbegründer Yichao „Peak“ Ji veröffentlichte die Zahlen. Manus verarbeitet 100 Eingabe-Token für jeden Ausgabe-Token. Bei Claude Sonnet kosten zwischengespeicherte Token etwa 0,30 US-Dollar pro Million. Nicht zwischengespeicherte Token kosten 3 US-Dollar pro Million. Dieser 10-fache Spread bedeutet, dass die Inputkosten dominieren. Alles, was die Trefferquote im KV-Cache erhöht, spart echtes Geld.

Dateibasierter Speicher ist stabiler, vorhersehbarer Text, der gut mit KV-Cache-Präfixen funktioniert. Nur anfügbarer Kontext, der sich zwischen Aufrufen selten ändert, bedeutet, dass das Modell zwischengespeicherte Berechnungen wiederverwenden kann. Ein datenbankgestütztes RAG-System, das jedes Mal unterschiedliche Kontextfragmente zusammenstellt, macht diese Optimierung zunichte.

Das „todo.md“-Muster von Manus ist das deutlichste Beispiel. Der Agent schreibt die Checkliste nach jedem Schritt neu. Dadurch wird der aktuelle Plan an der aktuellsten Kontextfensterposition platziert. Informationen in langen Kontexten werden ignoriert. Eine neu geschriebene Plandatei am Ende des Kontexts behebt das Problem ohne Abrufinfrastruktur.

Das wirtschaftliche Argument geht über Manus hinaus. Claude Code begrenzt den immer geladenen Speicher auf 200 Zeilen, da Speicherdateien bei jeder Sitzung Token verbrauchen. Die Einschränkung ist nicht die Speicherung. Es ist Aufmerksamkeitsbudget. Mithilfe von Dateien können Sie steuern, was das Modell sieht und wo es im Kontext angezeigt wird.

Dies sind keine zufälligen Entscheidungen. Sie sind kostenbewusste Architektur.

## Wo Dateien kaputt gehen

Lanhams Artikel ist ehrlich in Bezug auf die Fehlermodi. Diese Ehrlichkeit ist der wertvollste Teil der Analyse.

**Kontextbedingter Budgetdruck.** Claude Code warnt davor, dass große „CLAUDE.md“-Dateien die Modelltreue beeinträchtigen. Dateien funktionieren, bis sie aufgebläht und intern widersprüchlich werden. Eine Obergrenze von 200 Zeilen ist eine pragmatische Lösung, keine Lösung. Mit zunehmender Agentennutzung wächst die Datei, widerspricht sich selbst und niemand weiß, welche Version einer Tatsache aktuell ist.

**Gleichzeitigkeit.** Mehrere Agenten schreiben in den gleichen Speicher, die Datei ist beschädigt. Lanham bringt es direkt auf den Punkt: „Sobald mehrere Agenten oder Benutzer auf denselben Speicher zugreifen müssen, können gleichzeitige Dateischreibvorgänge Daten beschädigen.“ Die Obergrenze für einzelne Agenten ist real. Die meisten Agenten-Workflows bleiben nicht für immer Einzelagenten (/posts/when-agents-share-state-everything-breaks).

**Keine Versionierung.** Dateien werden überschrieben. Die Speicherkomprimierung von OpenClaw löst einen stillen Agentenwechsel aus, der dauerhafte Erinnerungen schreibt, bevor er abgeschnitten wird. Was war vor der Komprimierung in der Datei? Unbekannt. Wenn in der komprimierten Version ein Fakt weggelassen wurde, ist er verschwunden. Kein Beobachtungsprotokoll. Kein Rollback.

**Keine Herkunft.** Wenn ein Agent einen Erinnerungseintrag schreibt, gibt es keine Aufzeichnung darüber, von welcher Quelle er wann erstellt wurde oder ob er im Widerspruch zu etwas steht, das letzte Woche geschrieben wurde. Die Datei ist eine Zusammenfassung. Zusammenfassungen verschleiern ihre Inhaltsstoffe.

**Keine Unternehmensauflösung.** „Acme Corp“ in einer Sitzung und „ACME CORP“ ​​in der nächsten. Der Agent leitet die Identität jedes Mal neu aus dem Kontextfenster ab. Keine stabilen IDs. Keine Zusammenführungsregeln. Keine kanonischen Entitäten. Bei jeder Sitzung handelt es sich um eine sitzungsbezogene Inferenz.

**Keine Schemaeinschränkungen.** Jeder Agent oder jedes Tool kann alles in eine Speicherdatei schreiben. Keine Validierung. Keine Typprüfung. Keine Durchsetzung dessen, was ein Speichereintrag enthalten sollte. Schlechte Schriften verbreiten sich als Wahrheit.

Diese Fehler sind nicht hypothetisch. Sie werden von den Teams, die diese Systeme aufbauen, dokumentiert. Sie bilden die betriebliche Obergrenze des dateibasierten Speichers.

## Die Lücke im Gleichgewicht

Lanham schlägt eine „Gleichgewichtsarchitektur“ mit vier Schichten vor. Dateien als primäre Schnittstelle. Aggressives Auslagern auf die Festplatte. Abgeleitete Retrieval-Layer (Vektorindex über Dateien). Klare Eskalation zu Datenbanken, wenn Parallelität und Korrektheit dies erfordern.

Die ersten drei Schichten sind gut dokumentiert. Der vierte Teil bleibt als Übung für den Leser übrig.

„An eine Datenbank eskalieren“ setzt voraus, dass die Datenbank die Integritätsprobleme löst. Postgres liefert Ihnen standardmäßig keine versionierten Beobachtungen. Es gibt keine Herkunftsketten. Sie erhalten keine deterministische Entitätsauflösung über Dokumente hinweg. Es gibt Ihnen keine Schemaeinschränkungen für den vom Agenten geschriebenen Status. Das Verschieben von einer Markdown-Datei in eine Datenbanktabelle löst „keine Versionierung“ nicht. Es löst „kein gleichzeitiger Zugriff“. Das sind verschiedene Probleme.

Das Gleichgewicht weist eine Lücke zwischen den Schichten drei und vier auf. Zwischen „Markdown-Dateien, die für einen Agenten funktionieren“ und „vollständige Datenbankinfrastruktur“ fehlt eine Ebene. Strukturierter Staat mit Integritätsgarantien. Kein benutzerdefiniertes Datenbankschema erforderlich.

Die Architektur von OpenClaw deutet darauf hin. Sein hybrider Abruf, sqlite-vec mit konfigurierbarer Vektor-/Textgewichtung, zeitlichem Zerfall und MMR-Diversifizierung, ist anspruchsvoller als die einfache Dateisuche. Aber es behandelt die Markdown-Dateien immer noch als Quelle der Wahrheit. Der Index ist eine Leseoptimierung, keine Zustandsintegritätsschicht.

Die fehlenden Grundelemente sind die gleichen, die ich identifiziert habe [meinen eigenen Agentenstapel ausführen](/posts/agentic-search-and-the-truth-layer):

- **Versionierte Beobachtungen.** Jeder Schreibvorgang wird angehängt, nichts wird überschrieben. Zustand zu jedem Zeitpunkt rekonstruieren.
- **Herkunft.** Jede Tatsache, die auf eine Quelle, einen Zeitstempel und den Agenten oder Menschen zurückgeführt werden kann, der sie geschrieben hat.
- **Deterministische Entitätsauflösung.** Kanonische IDs basierend auf stabilen Regeln, nicht auf sitzungsspezifischer Inferenz.
- **Schemaeinschränkungen.** Validierung bei Schreibvorgängen. Fehlerhafte Daten werden abgelehnt, bevor sie in den Speicher gelangen.

Dies sind keine Datenbankfunktionen. Sie sind Merkmale der Staatsintegrität. Sie können sie auf einer Datenbank aufbauen. Postgres stellt Ihnen diese nicht sofort zur Verfügung. Und Sie können sie überhaupt nicht aus einer Markdown-Datei erhalten.

## Dateien sind der eigentliche Amtsinhaber

Die wichtigste strategische Erkenntnis aus Lanhams Analyse betrifft nicht Dateien vs. Datenbanken. Es geht darum, wie die tatsächliche Wettbewerbslandschaft aussieht.

Speicherinfrastrukturunternehmen haben Dutzende Millionen US-Dollar gegen Retrieval-Probleme aufgebracht. [Mem0](https://mem0.ai) hat 24 Millionen US-Dollar gesammelt. [Letta](https://www.letta.com) schloss einen Startwert von 10 Mio. USD bei einer Bewertung von 70 Mio. USD ab. Das Projekt [Graphiti](https://github.com/getzep/graphiti) von [Zep](https://www.getzep.com) hat 20.000 GitHub-Sterne erreicht. [MemPalace](https://github.com/MemPalace/mempalace) erreichte in den ersten zwei Wochen mit einem Local-First- und Verbatim-Storage-Ansatz 46.000 Sterne. Sie lösen echte Probleme: Haltbarkeit über Bereitstellungen hinweg, Personalisierung, skalierter Abruf und strukturierter Abruf.

Aber die Systeme, die die meisten Agenteninteraktionen verarbeiten, verwenden keine Vektordatenbanken als Speicher. Sie verwenden Textdateien. Produktionsnachweise von drei milliardenschweren Plattformen bestätigen, dass es sich bei dem tatsächlichen Standard nicht um ein bestehendes Datenbankprodukt handelt. Es ist eine Datei.

Dies verändert die Verdrängungsgeschichte. Der Upgrade-Pfad führt nicht von Vektordatenbanken zu etwas Besserem. Es reicht von Markdown-Dateien bis zum strukturierten Zustand. Die Menschen, die staatliche Integritätsgarantien benötigen, nutzen derzeit weder Mem0 noch Zep. Sie schreiben derzeit an „MEMORY.md“.

## Migration, kein Ersatz

Lanhams abschließender Ratschlag ist im Grunde richtig: „Beginnen Sie mit einer Markdown-Datei. Sie können später jederzeit eine Datenbank hinzufügen.“ Dateien sind eine rationale Ausgangsarchitektur. Die Wirtschaft unterstützt sie. Die Prüfbarkeit ist real. Die Einfachheit zählt.

Die Frage ist, wie „später“ aussieht.

Ich baue [Neotoma](https://github.com/markmhendrickson/neotoma) als diesen Upgrade-Pfad. Strukturierter Zustand mit den Integritätsgarantien, denen Dateien fehlen: Versionierung, Herkunft, Entitätsauflösung, Schemaeinschränkungen.

Die Frage der Kosteneffizienz ist wichtig. Wenn der Upgrade-Pfad die KV-Cache-Ökonomie opfert, die Dateien rationalisiert hat, handelt es sich nicht um ein echtes Upgrade. Der Lesepfad von Neotoma ist auf diese Einschränkung ausgelegt. Agenten greifen über MCP darauf zu. Die Antwort ist strukturierter Text, der in das Kontextfenster eingefügt wird, das gleiche Format, das ein Modell beim Lesen einer Datei sehen würde. Entitäts-Snapshots sind zwischen Aufrufen stabil. Dieselbe Entität, die zweimal abgefragt wird, gibt denselben Text zurück, sofern er nicht durch eine Beobachtung geändert wurde. Stabiler Text bedeutet stabile Token-Sequenzen. Stabile Token-Sequenzen bedeuten KV-Cache-Treffer.

Beim Schreibpfad unterscheiden sich die wirtschaftlichen Aspekte, und zwar dort, wo sie sich unterscheiden sollten. Das Schreiben einer Beobachtung in einen strukturierten Speicher mit Schemavalidierung ist teurer als das Anhängen einer Zeile an eine Markdown-Datei. Dieser Mehraufwand ist der Preis für Versionierung, Herkunft und Konflikterkennung. Die Frage ist, ob sich dieser Mehraufwand lohnt. Wenn Sie noch nie antworten mussten: „Was wusste mein Agent letzten Dienstag?“ oder „Welcher Schreibvorgang hat diese Entität beschädigt?“, dann nein. Der Abschlag ist korrekt. Wenn Sie diese Antworten benötigt haben und sie nicht bekommen konnten, sind die Kosten für den Schreibpfad der günstigste Teil des Problems.

Die Migrationsgeschichte ist unkompliziert. Sie haben mit „MEMORY.md“ begonnen, weil es die richtige Standardeinstellung war. Sie stoßen an die Grenze, wenn Sie Versionierung, gleichzeitigen Zugriff, Herkunft oder Entitätsauflösung über Sitzungen hinweg benötigen. Der nächste Schritt besteht nicht darin, „Postgres einzurichten und ein benutzerdefiniertes Schema zu erstellen“. Es handelt sich um eine strukturierte Ebene, die Ihnen diese Garantien bietet und gleichzeitig die bewährten Funktionen der Dateien beibehält: Überprüfbarkeit, Einfachheit, Local-First-Operation.

Die von Lanham dokumentierte konvergente Entwicklung bestätigt das Problem. Drei Teams mit einem Gesamtwert von Milliarden erreichten die gleiche Architektur und stießen auf die gleichen Herausforderungen. Die Wände definieren die nächste Schicht.