Ich baue ein Gedächtnis für Agenten. Ich weiß noch nicht, ob das Sinn macht.

Alles, was ein Agent über mich und meine Arbeit wissen soll, liegt in einem Ordner voller Markdown-Dateien — nicht in einem Memory-Feature eines Anbieters. Wie das aufgebaut ist, was hakt und warum ich trotzdem weitermache.

Chris Schön
Chris Schön
Freelancer · 9. Sep 2026 · 5 min
Ich baue ein Gedächtnis für Agenten. Ich weiß noch nicht, ob das Sinn macht.

Seit ein paar Monaten liegt alles, was ein Agent über mich und meine Arbeit wissen soll, in einem Ordner voller Markdown-Dateien in iCloud Drive. Keine Datenbank, kein Vektor-Store, kein Memory-Feature eines Anbieters. Ich nenne es me-os, und ich bin mir bis heute nicht sicher, ob das die richtige Idee ist. Hier steht, was es ist, wie es aufgebaut ist, was daran hakt und warum ich es trotzdem weitermache.

Warum überhaupt

Der eigentliche Grund ist unspektakulär: Sachen gingen verloren. Eine Deploy-Konvention, die ich einem Agent vor drei Wochen erklärt hab. Ein Rezept, das ich mal in einem Chat ausgearbeitet hatte. Wie ich Tickets schreibe, was ich nicht will. Das lag alles in Chatverläufen, die ich nie wieder aufmache. Und jedes Mal, wenn ich ein Tool gewechselt hab, war der Moment da, in dem man merkt, dass das Wissen mit dem Tool geht. Fuck.

Die Anbieter bauen dafür gerade alle eigene Memory-Features. Die haben alle denselben Haken: Das Gedächtnis gehört dann dem Agent, nicht mir. Ich wollte es andersrum. Das Wissen liegt bei mir, in Dateien, die ich selbst lesen kann, und jeder Agent, der Dateien lesen kann, darf rein. Der Witz an der Sache ist mir bewusst: Ich dezentralisiere Informationen, die mir sowieso gehören.

Es ist auch nicht nur Arbeit. Kunden-Setups liegen da genauso wie Eisrezepte. Es ist ein Ort für alles, was ich nicht noch mal erklären will.

Wie es aufgebaut ist

Vorab: Ja, ich öffne das in Obsidian. Aber nur, weil ich damit vom iPhone gut drankomme und mir die Aufmachung gefällt. Obsidian ist die Hülle. Der Kern sind Markdown-Dateien, und die sind universell — jeder Editor, jedes Tool, jeder Agent kann sie lesen. Daran hängt mein Herz, nicht an der App.

Die Ordnerstruktur ist kein System, das ich irgendwo gelesen hab. Es ist einfach eine, die sich für mich richtig anfühlt. Zwei Dateien sind trotzdem Pflicht-Einstieg für jeden Agent, bevor er irgendwas anderes anfasst: index.md ist die Karte — was liegt wo, welche Projekte sind aktiv. Kern/CLAUDE.md sind die Betriebsregeln — wie abgelegt wird, was nie gemischt wird. Daneben Kern/Me.md: wer ich bin und wie mit mir zu arbeiten ist.

Darunter ist es simpel: Arbeit/ und Privat/, beide mit Werke/ (was ich baue) und Wissen/ (was zeitlos ist). Chronik/ für alles Datierte. Trash/ für alles, was weg soll — hart gelöscht wird nichts.

Die Regeln, auf die es ankommt, passen auf eine Hand: Arbeit und Privat nie mischen, im Zweifel Privat. Zeitgebundenes in die Chronik, Zeitloses ins Wissen, nie beides in eine Datei. Ein Fakt gehört an genau einen Ort. Ein neues Projekt existiert erst, wenn es in der index steht. Ändert sich die Struktur, wird die Karte nachgezogen.

Das klingt nach wenig. Es ist aber genau das, was ein Agent braucht, um nicht wild Dateien anzulegen. Die Regeln sind für den Leser geschrieben, nicht für mich — ich weiß ja, wo meine Sachen liegen.

Die zwei MCPs

Zugriff läuft über zwei lokale MCP-Server, beide von der Stange:

"me-os-memory-smart-rag": {
  "command": "npx",
  "args": ["-y", "mcp-server-markdown", "~/…/Obsidian/Ideaverse"]
},
"me-os-memory-write-bridge": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "~/…/Obsidian/Ideaverse"]
}

Der erste liest: Volltextsuche, Dateiliste, einzelne Abschnitte nach Überschrift, Frontmatter. Der zweite schreibt: Datei anlegen, bearbeiten, verschieben. Getrennt, damit ich das Schreiben abschalten kann, ohne das Lesen zu verlieren. Dazu ein eigener Skill fürs Ablegen, der die Regeln von oben erzwingt: erst lesen, dann schreiben, Frontmatter setzen, index pflegen.

Was nicht rund läuft

Das “rag” im Namen ist eine Lüge. Es ist keine semantische Suche, es ist grep. Für ein paar hundert Dateien reicht das, und ich bin ehrlich unsicher, ob ich je einen echten Vektor-Index will — dann hätte ich wieder einen Build-Schritt und Embeddings, die zu einem Anbieter gehören.

Lesen und Schreiben sind langsam, weil die Dateien in iCloud Drive liegen. Manchmal ist ein Ordner noch nicht synchronisiert, und der Agent sieht eine Karte, die auf Dateien zeigt, die er nicht findet.

Und heute Morgen hat der Write-Server gar nicht funktioniert: Der Filesystem-Server liefert ein Output-Schema im Draft-07-Format, der Client validiert nur 2020-12. Ergebnis: Lesen ging, Schreiben nicht. Das ist der Preis für Standardteile — man erbt deren Kanten.

Der größte Punkt aber: Gerade kann nur ein Agent gut damit umgehen. Ich habe das ganze Ding bewusst so gebaut, dass es keinem Agent gehört — und praktisch hängt es an einem. Das ist ein Widerspruch, den ich noch nicht aufgelöst habe. Die Wette ist, dass MCP als Schnittstelle bleibt und andere nachziehen. Ob die aufgeht, weiß ich nicht.

Ob das Sinn macht

Ich weiß es nicht. Was ich weiß: Wenn ich einem Agent heute sage “leg das ab”, landet es an der richtigen Stelle, mit Frontmatter, ohne Duplikat. Und wenn ich morgen ein anderes Tool nehme, ist das Wissen noch da, in Dateien, die ich öffnen kann. Das reicht mir gerade als Grund, weiterzumachen. Wenn es in einem Jahr noch so wackelig ist wie heute, schreibe ich das auch auf.

Ein Punkt ist kein Ende, der nächste Satz Drupal 10 läuft aus. Wir haben das genutzt, um Altlasten loszuwerden. Studio · weiterlesen →