Ein Memory-Plugin liest die Protokolle vergangener Sitzungen, zerlegt sie in rund tausend kleine Ausschnitte und legt diese als Vektoren in einer Datenbank ab. Bei jedem neuen Prompt zieht es die fünf ähnlichsten Ausschnitte zurück, hängt sie an den Kontext und hofft, dass die entscheidenden darunter sind. Zerlegt man diese Kette, bleibt kein Gedächtnis übrig, sondern ein Losverfahren mit anschließender Nachsuche, dessen Trefferquote niemand garantieren kann. Der Entwickler Kevin Liao, der seit über einem Jahr mit KI programmiert und dafür ein eigenes Werkzeug gebaut hat, formuliert daraus einen harten Vorwurf: Die Memory-Plugins lösen das falsche Problem.
Seine Antwort lautet: Agenten brauchen kein Gedächtnis, sie brauchen Dokumentation. Das klingt zunächst nach Wortklauberei, denn beides dient demselben Ziel – der Agent soll wissen, woran er arbeitet. Zwischen den beiden Wegen liegt jedoch ein Unterschied, der die gesamte Architektur eines Werkzeugs verändert, nicht nur seine Feinabstimmung. Wer das für Spitzfindigkeit hält, sollte sich ansehen, wie Memory-Plugins konkret arbeiten und woran sie scheitern. Die entscheidende Frage ist nicht, ob ein Agent sich erinnert, sondern ob er nachschlagen kann.
Fast alle Memory-Plugins arbeiten nach demselben Muster
Die Architektur ist auffällig gleichförmig: Transkripte durchgehen, daraus Erinnerungen in Snippetform erzeugen, diese in eine RAG-Vektordatenbank schreiben, bei jedem Prompt die fünf ähnlichsten Treffer einblenden und dem Agenten zusätzlich ein Suchwerkzeug auf dieselbe Datenbank in die Hand geben. Alles Weitere ist Verzierung. Manche Systeme trennen Kurz- und Langzeitgedächtnis, andere lassen Hintergrundprozesse Erinnerungen zusammenführen oder über Nacht neu schreiben, wieder andere schieben einen Reranker zwischen Suche und Ausgabe. Jede dieser Funktionen kostet Tokens und Rechenzeit, ohne die Grundannahme zu berühren, dass Wissen aus der Vergangenheit rekonstruiert werden muss.
Als Bild hilft ein Aktenschrank, in dessen Fächer jemand einen Stapel loser Zettel geworfen hat. Bei jeder Frage werden fünf Zettel herausgezogen, und wenn der Agent ratlos wirkt, darf er selbst weiterwühlen. Was dabei entsteht, ist kein geordnetes Wissen, sondern eine Momentaufnahme, die von der Formulierung des Prompts abhängt. Deshalb arbeiten diese Systeme unzuverlässig, egal wie viel Aufwand in die Zusatzfunktionen fließt.
Ähnlichkeit ist kein Maß für Richtigkeit
Alle Varianten beantworten letztlich eine einzige Frage: Wie nah liegen zwei Textausschnitte im Vektorraum beieinander? Das sagt nichts darüber, welcher Stand korrekt oder aktuell ist, und erst recht nichts über das, was fehlt. Ein Ausschnitt ist zudem zu klein, um Kontext, Motivation, Umgebung und die Lehren aus einem gescheiterten Versuch mitzutragen. Dazu kommt die stillschweigende Annahme, dass die Vergangenheit die Wahrheit sei. In einer Codebasis, die sich täglich ändert, ist das eine riskante Grundlage: Wie viele der fünfhundert Ausschnitte zur Authentifizierung sind heute noch gültig?
Ein zweites Problem liegt im Suchen selbst. Selbst wenn der Agent ein Suchwerkzeug bekommt, weiß er nicht, wann er es benutzen soll, denn er weiß nicht, was er nicht weiß. Er kann nicht nach einer Entscheidung suchen, von deren Existenz er nichts ahnt. Hinzu kommt, dass solche Speicher kaum prüfbar sind. Zehntausend Embeddings in einer SQLite-Datei beantworten keine der Fragen, die ein Team stellen müsste: Welche Erinnerungen gibt es überhaupt, welche sind veraltet, welche wurden nie abgerufen, und welche verzerren still die Arbeit des Agenten?
Auffällig ist, dass niemand außerhalb der KI-Welt so mit Wissen umgeht. Kein Team sieht sich ein Meeting von vor drei Jahren erneut an, um die Rahmenbedingungen eines Features zu rekonstruieren. Menschen schreiben Dinge auf und arbeiten danach mit diesen Aufzeichnungen. Der Vorschlag lautet deshalb, den Speicher nicht als Datenbank an den Agenten zu schrauben, sondern als Arbeitsbereich, den man lesen, ändern und teilen kann.
AGENTS.md war ein Anfang, eine Datei reicht aber nicht
Dass Agenten Kontext brauchen, war früh klar, deshalb entstanden AGENTS.md-Dateien, damit ein Agent nicht blind in eine fremde Codebasis springt. Das funktioniert. In vielen Projekten ist diese eine Datei aber die einzige Dokumentation, die überhaupt existiert. Sie kann die Anforderungen eines echten Projekts nicht tragen: Wie der Codereview abläuft, was mit dem Auftraggeber besprochen wurde, welche Bibliothek warum verworfen wurde, welche Entscheidung gilt und welche überholt ist.
Was Liao stattdessen beschreibt, ist ein strukturierter Arbeitsbereich – Markdown-Dateien, in die der Agent ohne Aufforderung schreibt: Anweisungen für Prozesse, Spezifikationen aus Gesprächen, wiederverwendbare Recherche zu fremden APIs, Register, die den Einstieg erleichtern. Vor der Arbeit liest der Agent die passenden Dokumente und sieht den Zusammenhang statt eines Flickenteppichs. Nach der Arbeit aktualisiert er, was überholt ist, und legt neue Dokumente an, solange das Gesamtbild noch in seinem Kontext liegt.
Der Arbeitszyklus verschiebt sich: erst nachschlagen, dann bauen
Damit ändert sich der Ablauf: Aus prompt, bauen, vergessen wird prompt, nachschlagen, bauen, aktualisieren. Das Gedächtnis ist nicht mehr eine Datenbank, die man an den Agenten anschraubt, sondern ein Arbeitsmittel, das im Projekt selbst liegt. Weil alles einfache Textdateien sind, lässt sich der Wissensstand versionieren, in einem Commit nachvollziehen und im Team teilen. Der Zettelstapel bekommt Register und Beschriftungen, und jeder darf hineinschreiben.
Der wichtigere Gewinn ist nicht Geschwindigkeit, sondern Prüfbarkeit. Einen falschen Satz in einer Markdown-Datei findet und korrigiert man in einer Minute. Ein falsch gewichtetes Embedding bleibt unsichtbar und wirkt trotzdem auf jede Antwort. Wer schon einmal versucht hat, einer Vektordatenbank eine falsche Erinnerung auszutreiben, kennt den Unterschied zwischen einem Fehler, den man sieht, und einem, den man nur vermutet.
Aus einem internal-Ordner wurde das Plugin Operator Memory
Liao beschreibt, wie er vor über einem Jahr beim Programmieren mit KI anfing und einen Weg suchte, Arbeit über Sitzungen hinweg zu erhalten. Er legte zunächst einen Ordner namens internal an, in den der Agent alles schreiben sollte: Spezifikationen, Pläne, Indizes. Dazu die Anweisung, vor der Arbeit die passenden Dokumente zu lesen und sie danach zu aktualisieren. Aus diesen Regeln wurde mit der Zeit ein Plugin namens Operator Memory, das er in allen seinen Projekten einsetzt. Der Essay ist damit auch Werbung in eigener Sache: Die Kritik an den Memory-Plugins mündet in Liaos eigenes Werkzeug.
Technisch ist der Ansatz bewusst unspektakulär. Keine Vektordatenbank, keine Embeddings, keine Zusammenfasser, Kuratoren oder nächtlichen Hintergrundprozesse, keine Blackbox-Suche. Alles ist ein Markdown-Dokument, das man lesen, ändern, committen und mit dem Team teilen kann. Das Werkzeug ist kostenlos und quelloffen unter github.com/aerovato/operator-memory verfügbar.
Was das im Alltag bedeutet
Der Vorschlag klingt selbstverständlich und verlangt trotzdem Disziplin. Dokumente müssen gepflegt werden, und ein Agent, der selbst schreibt, produziert auch Unsinn, den ein Mensch lesen und aussortieren muss. Wer diese Disziplin nicht aufbringt, tauscht ein sichtbares Problem gegen ein unsichtbares. Für kurze Unterhaltungen mit einem Chatmodell braucht es all das nicht; dort reicht der Kontext der laufenden Sitzung.
Wo Agenten aber über Wochen an einem Projekt arbeiten, verschiebt sich die Frage. Es geht dann nicht mehr darum, ob Dokumentation wichtiger ist als Erinnerung, sondern darum, wie viel Pflege ein Team investieren will. Ein Stapel loser Zettel, aus dem fünf zufällige gezogen werden, oder ein Register, in dem nachlesbar steht, was gilt – die Wahl ist nicht schwer. Wer KI-Agenten dauerhaft einsetzt, sollte ihnen ein Archiv geben, in das sie hineinschreiben dürfen, statt ein Gedächtnis.
Quelle: liao.gg
