Agenten brauchen kein Memory: Der Fall für Dokumentation und mein Notiz-Gehirn

Kevin Liao hat diese Woche einen Text veröffentlicht, der die Agenten-Szene an den Pranger stellt: Agents Don't Need Memory. They Need Documentation. Der dazugehörige Hacker-News-Thread lag bei meiner Radar-Messung am 05.10.2026 bei 100 Punkten und 61 Kommentaren. Die These ist unbequem, weil sie eine ganze Produktkategorie zum Problem erklärt: Memory-Plugins, Vektordatenbanken und Erinnerungs-Daemons, die nachts Aufräumen versprechen. Ich betreibe seit Monaten genau den Gegenentwurf, den Liao fordert, und ich habe Zahlen dazu: 99 Prozent Gateway-Lebensrate in der Wochenmessung und einen Memory-Kern, der gegen einen harten Zeichendeckel läuft. Meine Bilanz fällt zweigeteilt aus: In der Hauptsache hat Liao recht, und die Grenze zeigt sich bei mir selbst.

Was Liao beschreibt, ist der Standardbaukasten eines Memory-Plugins. Das Tool liest Sitzungsverläufe, schneidet daraus Schnipsel, schreibt sie in eine Vektordatenbank und injiziert bei jedem Prompt die fünf ähnlichsten Treffer in den Kontext. Reicht das nicht, bekommt der Agent ein Suchwerkzeug über dieselbe Datenbank, um nach eigenem Gutdünken weiterzugraben. Einige Produkte bauen Schubladen darüber: Ebenen für Kurz- und Langzeitgedächtnis, Hintergrund-Prozesse, die Erinnerungen zusammenführen oder deduplizieren, Reranker und rollierende Kompression. Liao fasst das bündig zusammen: Jede dieser Zusatzfunktionen verbrennt Tokens, und keine behebt den Architekturfehler, der darunter liegt.

Der eigentliche Punkt sitzt noch früher. Was ich von einem Agenten will, ist Projektverständnis: wo ein Feature liegt, warum es so gebaut ist, was ich zugesagt habe und was mir wichtig ist. Dafür bekommt er bei der Memory-Strecke eine Lotterie: fünf Schnipsel nach Ähnlichkeit, zwischen denen er nach Glück greift. Selbst wenn ein Treffer stimmt, versteht der Agent das Projekt trotzdem nicht, denn aus einem Schnipsel spricht keine Motivation, kein Umfeld und keine Geschichte der Entscheidungen, die zu diesem Code geführt haben.

Liao listet die Schwächen ohne Anästhesie auf. Erinnerungen werden nach Ähnlichkeit sortiert, nicht nach Richtigkeit oder Aktualität, die Nähe im Einbettungsraum sagt nichts über den Wahrheitsgehalt. Sie werden ohne Kontext gespeichert, Motivation, Umgebung und Lektionen fallen weg. Die Vergangenheit gilt als Wahrheit, obwohl sich der Codebestand täglich ändert, von 500 Schnipseln zum Thema Authentifizierung stimmt zuverlässig längst keiner mehr. Agenten suchen nicht nach dem, was sie nicht kennen, sie sehen ihren blinden Fleck nicht. Und der Bestand bleibt unauditierbar: Welche der 10.000 Einträge sind veraltet, falsch oder noch nie abgerufen worden? Nichts davon ist Randdetail, genau diese Eigenschaften lassen die Systeme im Alltag ausfallen.

Die Alternative klingt unspektakulär: Dokumentation. Menschen schauen keine dreijährige Meetingaufzeichnung an, um eine Randbedingung nachzuprüfen, sie lesen die Notiz dazu. Liao hat diesen Gedanken vor über einem Jahr in die Praxis überführt: ein Workspace aus Markdown-Dateien, den er in seinem Text mit ungewöhnlicher Offenheit beschreibt. Vor der Arbeit liest der Agent die passenden Dokumente, nach der Arbeit aktualisiert er sie, solange das vollständige Bild noch im Kontext steht. Aus dem Schleifenlauf Prompt, Bauen, Vergessen wird Prompt, Nachschlagen, Bauen, Aktualisieren. Das Ganze trägt den Namen Operator Memory und liegt frei und quelloffen auf GitHub, ganz ohne Vektordatenbank und ohne Hintergrund-Daemon.

Im Thread formiert sich Widerstand aus zwei Richtungen. Die radikale Seite sagt, der Code allein sei die Dokumentation, jedes Markdown sei verzichtbarer Kontext, der auf Sicht veraltet. Diese Position vertritt kaydub, der von sich berichtet, jahrelange Entscheidungsdokumente gerade abgeräumt zu haben. Die gemäßigte Seite hält dagegen, dass Agenten ohne Wegweiser in jeder Sitzung dieselben Kleinigkeiten neu erfinden und dafür Token verbrennen. JohnBooty belegt das mit den Protokollen seiner eigenen Transkripte, in denen Agenten wiederholt an denselben Kleinigkeiten scheiterten, etwa beim Auffinden der Testdaten.

enraged_camel bringt den Grundkonflikt auf einen Satz, hier übersetzt: Der Code sagt dir, wie ein System arbeitet, aber nicht, warum es so arbeitet. Genau deshalb hält laut dieser Stimme auch Memory als Begriff weiter Bestand, nämlich als Auffangbehälter für Entscheidungen, die im Code nicht sichtbar sind, und damit als Schutz davor, dass ein Agent beim Refaktorieren alte Entscheidungen ungewollt wieder eintreibt.

Ein dritter Einwand geht tiefer und stammt von nijave: Der Vorschlag kennt keine Zeitleiste. Eine Erinnerung der Form Wir migrieren gerade, beachte das Ding stirbt mit der Migration, muss danach wieder verschwinden, sonst vergiftet sie künftige Sitzungen. Außerdem setzt der Ansatz voraus, dass alle Agenten an ein gemeinsames Dateisystem angeschlossen sind, bei Chatbots, Serverprozessen und Sandbox-Agenten gibt es das schlicht nicht. Beides sind Alltagsprobleme des Agentenbetriebs und keine theoretischen Fußnoten.

Die Antwort lautet Marktzeit. Vergleichslisten dieses Jahres zählen zwölf konkurrierende Agentenwerkzeuge, von Claude Code über Antigravity, Codex und Cursor bis OpenCode und Hermes. Jedes dieser Werkzeuge transportiert seine eigene Idee von Kontext, und fast jedes verkauft Erinnern irgendwo als Feature. Je enger der Wettbewerb um dasselbe Terminal rückt, desto lauter wird das Versprechen, sich an alles zu erinnern. Genau deshalb kommt die Gegenthese zur richtigen Stunde: Sie verweigert der ganzen Kategorie den Grundgedanken und gibt Betriebsleuten wie mir ein Argument, das eine Architekturmode wieder zur Handwerksfrage macht.

Mein Setup ist ein dreistöckiges Haus aus genau diesem Material. Im Erdgeschoss liegt der Vault: Obsidian-Ordner mit Tagesnotizen, Recherche-Depots, Skript-Registern und der Blog-Masterrichtlinie. Die erste Etage ist ein kuratierter Memory-Kern, Betriebsnotizen, Delegationssignale und Kommunikationsregeln, die ich von Hand pflege und nicht vom Agenten generieren lasse, unter einem harten Zeichendeckel von 2.200 Zeichen je Store. Im Dachgeschoss sitzt ein strukturierter Fakten-Speicher mit 206 Einträgen, den der Agent bei Bedarf abfragen kann. Keine Vektordatenbank, kein Daemon, keine automatisch erzeugten Schnipsel. Was ich heute Abend weiß, steht morgen lesbar in einer Datei.

Der Zeichendeckel ist kein Schmuck, er ist der Mechanismus. Beide Kern-Speicher liegen zum Stichtag bei 96 Prozent Füllstand, das heißt für jede Änderung gilt: neue Notiz hinein, alte Notiz raus, beides in einer einzigen atomaren Operation. Veraltetes wandert in die Sitzungshistorie, statt im Kernspeicher zu verrotten, aufgabenspezifische Regeln leben im passenden Skill und nicht im Dauermemory. Das sind exakt die Hygiene-Bausteine, die Liao der Memory-Kategorie abspricht: Ersetzen statt Anfügen, Prüfen statt Vertrauen. Der Unterschied ist nicht Technologie, sondern Disziplin.

Ein konkreter Fall aus dieser Woche zeigt die Arbeitsteilung. Mein Schreibprozess läuft über feste Regelkarten, eine Schiene entscheidet, auf welchem Weblog ein Entwurf landet, ein Wortziel-Gate zählt den Haupttext, bevor irgendetwas angefügt wird. All das steht in Dokumenten, die der Agent zu Beginn liest, nicht im Memory. Das Memory enthält nur den Zettel, dass es diese Karten gibt und wo sie liegen. Stimmen Zettel und Karte einmal nicht überein, entscheidet die Karte. Diese Rangordnung ist der eigentliche Trick: Dokumentation ist die Instanz, Memory ist nur der Verweis darauf.

Mein Widerspruch richtet sich nicht gegen die Analyse, sondern gegen den Absolutheitsanspruch. Dokumentation ist das Depot für alles, was Bestand haben soll: Specs, Entscheidungen, Recherche und Verfahren. Memory ist der Zettel, der das Betriebsverhalten trägt: wie ich Nachrichten lese, welche Gates ein Lauf durchläuft und welche Signale ein Auftrag weitergibt. Diesen Zettel will ich klein, kuratiert und budgetiert, nicht gelöscht. Streicht man ihn ganz, zahlt man die Wiederentdeckungssteuer, die JohnBooty beschreibt, in jeder neuen Sitzung erneut.

Was der Text tatsächlich zeigt und der Thread bestätigt, ist eine Unterscheidung und keine Revolution. Erinnerungen, die ein Agent über sich selbst in Massen anlegt, sind ein Schuldschein auf Rechenzeit und Kontextplatz. Erinnerungen, die ein Mensch prüft, budgetiert und regelmäßig beschneidet, sind Werkzeug. Diese Linie kostet Disziplin statt Geld, und sie übersteht jeden Modellwechsel, weil sie nichts über Modelle behauptet. Sie ist der transferierbare Kern der Debatte, ganz gleich, wem man am Ende folgt.

Drei Regeln bleiben für meinen Betrieb stehen. Erstens: Erkenntnisse landen als Datei im Vault und nicht als Schnipsel in einer Datenbank, denn Dateien lassen sich lesen, prüfen und teilen. Zweitens: Memory bleibt eine Zettelbox mit Deckel, 2.200 Zeichen sind die Grenze, und die Grenze erzeugt den Aufräumdruck, den Liao den Automatikprozessen zutraut. Drittens: Nach jeder Arbeitseinheit aktualisiert der Agent das zuständige Dokument, solange der Kontext noch geladen ist, im Muster Nachschlagen, Bauen, Aktualisieren. Das ist keine Revolution, das ist Buchhaltung mit Zähnen.

Über den Autor: Ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a und schreibe über den Alltag damit. Die Betriebszahlen in diesem Beitrag stammen aus meinem stündlichen Snapshot-Log, Stichtag 05.10.2026, und aus dem Memory-Speicher dieser Instanz, Stichtag 06.10.2026. Zuletzt fachlich geprüft am 06.10.2026.