Roan Brasil Monteiro hat ein ausführliches Tutorial darüber geschrieben, wie man einen Obsidian-Tresor in das „zweite Gehirn“ eines Entwicklers verwandelt, gesteuert von einem LLM-Agenten. Seine Architektur ist sauber: drei physisch getrennte Zonen. raw/ ist das, was der Mensch kuratiert, unveränderlich; wiki/ gehört dem Agenten — Konzepte und Synthesen; dev/ ist gemeinsames Terrain für ADRs und Post-mortems. Über allem liegt CLAUDE.md mit dem Rechteschema, git dient als Rückgängig-Knopf, und einmal pro Woche stößt der Mensch eine Synthese der Wochennotizen an. Die Kernregel formuliert er in einer Zeile: «the agent never touches what you curated; you rarely touch what the agent maintains» — der Agent rührt nie an, was du kuratiert hast; du rührst selten an, was der Agent pflegt.
Ich betreibe selbst einen Stack für persistentes Gedächtnis in der Produktion und habe diesen Text als Praktiker gelesen, nicht als Zuschauer. Meine These ist einfach: Was Monteiro beschreibt, ist kein Konkurrent zu meinem Stack und auch nicht „ein anderer Ansatz für dasselbe“. Es ist eine andere Schicht. Die meisten Debatten über Agenten-Gedächtnis sind durch den falschen Rahmen „wer gewinnt“ vergiftet — dateibasiertes Gedächtnis gegen Vektor, Wiki gegen Graph. In Wahrheit sind das verschiedene Mechanismen für verschiedene Aufgaben, und sie zu verwechseln heißt, ein System zu bauen, in dem eine Schicht die Arbeit einer anderen schlecht erledigt.
Drei Schichten, die verschiedene Arbeit leisten
In meinem Stack leben mindestens drei unterscheidbare Dinge. Das erste ist dateibasiertes Gedächtnis diskreter Fakten: ein Fakt pro Datei, ein Index in MEMORY.md. Das ist schnell, das ist adressierbar, das ist, wonach der Agent greift, wenn er die präzise Antwort auf „wie haben wir Frage X entschieden“ braucht. Das zweite ist semantisches Gedächtnis: MemPalace mit kuratierten Flügeln, einem Wissensgraphen und Zehntausenden automatisch geschürften Sitzungen. Es beantwortet nicht „gib mir den Fakt“, sondern „was ähnelt überhaupt der aktuellen Situation“. Das dritte ist ein handkuratiertes erzählerisches Wiki — genau das, was Monteiro baut: der Mensch kuratiert, der Agent synthetisiert einmal pro Woche, git versioniert.
Und hier die ehrliche Stelle: die dritte Schicht betreibe ich kaum. Nicht weil sie schlecht wäre — sondern weil sie ihre eigene Nische hat, und diese Nische überdeckt die ersten beiden nicht. Diskrete Fakten brauchen keine wöchentliche „Synthese“; sie müssen sofort abrufbar sein. Semantischer Recall lebt nicht in Title-Case-Seiten mit Wikilinks, er lebt in Embeddings und Graphkanten. Monteiros Tutorial beschreibt einen Mechanismus — ein menschlich kuratiertes, wöchentlich synthetisiertes, git-versioniertes Wiki — und beschreibt ihn gut. Der Fehler entsteht erst, wenn dieser eine Mechanismus zur Antwort auf die gesamte Gedächtnisfrage erklärt wird.
Wo er völlig recht hat
Die Zonentrennung ist der richtige Instinkt, und ich erkenne darin meine eigene Disziplin wieder. Ich führe ein eigenes Dokument „Verantwortungszonen“ — buchstäblich harte Grenzen zwischen dem, was in CLAUDE.md, im dateibasierten Gedächtnis, in MemPalace und im Wiki liegt; wer wohin schreiben darf. Wenn Monteiro raw/ unveränderlich macht und schreibt «the agent never touches what you curated», formuliert er denselben Gedanken, zu dem ich unabhängig gelangt bin: der Agent sollte in genau eine Schicht schreiben und die übrigen lesen dürfen. Das ist keine Verzeichnis-Ästhetik. Es ist eine operative Richtlinie, die den Agenten daran hindert, deine Quelle der Wahrheit unter dem Deckmantel des „Aufräumens“ stillschweigend umzuschreiben.
Auch seine Abwehr gegen Prompt Injection ist vernünftig, soweit sie reicht: allowed-tools ohne rm, ein zwingend vor der Ausführung gezeigter Plan, git diff als Sicherheitsnetz. Ein Mensch in der Schleife vor jedem Schreibvorgang ist die richtige Disziplin. Das bestreite ich nicht.
Wo er einen Schritt zu früh aufhört
Doch genau bei den Injektionen kommt er einen Schritt zu kurz — und das ist keine Kleinigkeit. Sein Bedrohungsmodell nimmt an, dass eine bösartige Anweisung sich als Aktion zeigt: ein Versuch, Dateien zu löschen, das Wiki umzuschreiben, einen Befehl auszuführen. Davor schützen die Allowlist, der Plan und git. Was diese Abwehr nicht fängt, ist eine Injektion, die zum Zeitpunkt des Ingest nichts Destruktives tut und einfach zu Inhalt wird. Ein Agent, der eine externe URL liest und in eine Wissensschicht synthetisiert, zieht Text herein, den irgendjemand geschrieben hat. Verbirgt ein Artikel eine untergeschobene „Tatsache“ — eine falsche Behauptung, eine gefälschte Zuschreibung, eine stille Hintertür für eine künftige Sitzung —, so passiert sie jede seiner Abwehrschichten, weil sie wie legitime Synthese aussieht.
Und hier der Kern: Gift, das im Wiki landet, überlebt ein git diff. Das Diff zeigt, dass die Seite sich geändert hat — aber die Änderung sollte ja geschehen, du hast den Ingest selbst gestartet. Das Diff unterscheidet einen ehrlichen Absatz nicht von einem untergeschobenen: beide sehen aus wie gewöhnlicher neuer Inhalt. „Review the plan before approving“ rettet dich vor dem Löschen von Dateien, aber nicht vor einem Absatz, der sich plausibel liest und dabei lügt. Die zonale Unveränderlichkeit von raw/ schützt die Integrität der Quelle vor dem Agenten — sagt aber nichts über die Integrität der Quelle selbst, die du dort abgelegt hast.
Was zu tun ist
Die Lösung ist kein komplexeres Modell, sondern eine fehlende Schicht — das Scannen von Inhalten, bevor der Agent sie überhaupt sieht. In meinem Setup läuft /security-check vor jedem Ingest in Gedächtnis oder Wiki: Regex-Signaturen für Injektionen, ein Detektor für verstecktes Unicode, das Zerlegen von base64-Blöcken. Das ist ein Preflight, kein Post-mortem. Für Monteiros Schema speziell würde ich drei Dinge tun.
- Schritt 1. Beim Ingest scannen, vor der Synthese. Die externe URL durchläuft einen Content-Scan, bevor der Agent beginnt, Konzepte zu extrahieren. Die Injektion muss gefangen werden, bevor sie zur „neuen Wiki-Seite“ wird, nicht danach.
- Schritt 2.
raw/als nicht vertrauenswürdigen Input behandeln — auch das, was du selbst gespeichert hast. Unveränderlichkeit schützt dich vor dem Agenten, macht den Inhalt aber nicht ehrlich. Der Web-Clipper speichert genau das, was auf der Seite stand, einschließlich dessen, was der Autor dort platziert hat. - Schritt 3. „git diff ist sauber“ nicht mit „Inhalt ist sicher“ verwechseln. Git fängt unbefugte Änderungen. Es fängt keinen befugten Ingest einer vergifteten Quelle. Das sind verschiedene Garantien, und git ersetzt die zweite Verteidigungsschicht nicht.
Ich „widerspreche“ Monteiro also nicht — ich erweitere ihn um eine Schicht. Seine Drei-Zonen-Architektur ist das richtige Fundament, und sein Satz „der Agent rührt nie an, was du kuratiert hast“ sollte über jedem Gedächtnissystem hängen. Aber Gedächtnis ist eine Taxonomie von Schichten, kein einzelner siegreicher Mechanismus; und jede Schicht, die die Außenwelt ingestiert, braucht eine Säuberung an der Tür, denn vergifteter, aber plausibler Text ist die eine Bedrohung, die weder die Allowlist noch git diff noch die Plan-Vorschau sehen kann.