Headerpicture

Das Gedächtnis eines KI-Agenten liegt im Projekt, nicht im Chat

KI-Agenten haben kein dauerhaftes Gedächtnis, sondern ein kleines Arbeitsgedächtnis, das mit jeder Sitzung leer beginnt. Wie man Wissen so ablegt, dass zur richtigen Aufgabe die passenden Informationen verfügbar sind und der Rest im Hintergrund bleibt, ist weniger eine Frage des Speicherns als der Informationsarchitektur.

Abonniere meinen Newsletter!


Wöchentliche Updates zu Tools, KI und digitalem Alltag. Ohne Buzzword-Bingo. E-Mail eintragen und los.

Das Gedächtnis eines KI-Agenten liegt im Projekt, nicht im Chat

Wer länger mit einem KI-Agenten arbeitet, kennt zwei Arten von Frust. Der erste: Der Agent vergisst alles. Man erklärt ihm am Montag, wie das Projekt funktioniert, und am Dienstag fängt man wieder bei null an. Der zweite stellt sich ein, sobald man das Vergessen abstellen will. Dann packt man ihm das gesamte Wissen in eine große Anleitung, und auf einmal wird er langsam, teuer und ungenau, weil er bei jeder Kleinigkeit den ganzen Wust mitliest.

Beide Probleme haben dieselbe Wurzel. Ein KI-Agent hat kein dauerhaftes Gedächtnis im üblichen Sinn. Er hat ein Arbeitsgedächtnis, das mit jeder neuen Sitzung leer ist. Und dieses Arbeitsgedächtnis ist klein. Genau das ist die knappe Ressource, nicht der Speicherplatz.

Den Punkt übersehen die meisten. Es geht nicht darum, dass sich der Agent möglichst viel merkt. Es geht darum, dass das Richtige im richtigen Moment vor ihm liegt. Die eigentliche Frage lautet, wie ich dafür sorge, dass genau das Passende auftaucht, wenn es gebraucht wird. Viel speichern hilft dabei nicht weiter.

Der Ablageort fürs Wissen

Die erste Hälfte der Antwort ist unspektakulär. Das Wissen gehört ins Projekt. Konkret heißt das, es lebt als Textdateien neben dem Code, im selben Repository, das ohnehin schon alles versioniert.

Bei Claude Code gibt es dafür einen festen Ort. Eine Datei namens CLAUDE.md im Projektordner wird beim Start jeder Sitzung automatisch mitgelesen. Sie ist der Einstiegspunkt. Daneben existiert eine globale Variante für Dinge, die maschinen- oder nutzerweit gelten, und man kann Regeln per Verweis in andere Dateien auslagern, statt sie überall zu wiederholen. Erkenntnisse, die über einzelne Sitzungen hinaus bestehen sollen, lassen sich in eigene Gedächtnisdateien legen, getrennt von der Einstiegsdatei.

In der Praxis sieht diese Einstiegsdatei winzig aus. Sie verweist weiter, statt das Wissen selbst zu halten:

Die Zeile mit dem @ zeigt das Auslagern per Verweis. Die Commit-Regeln stehen nicht hier, sondern in einer eigenen Datei, auf die nur gezeigt wird.

So weit die Mechanik. Sie ist schnell erklärt und führt direkt zur eigentlichen Schwierigkeit.

Der Reflex, alles in eine Datei zu kippen

Sobald man weiß, dass die Einstiegsdatei immer mitgelesen wird, kommt der Reflex: dann schreibe ich da eben alles rein. Jede Regel, jede Konvention, jeden Sonderfall. Das System hat es dann ja parat.

Genau das geht schief. Was immer mitgelesen wird, kostet bei jeder einzelnen Nachricht. Eine Anleitung mit siebzig Regeln liegt auch dann im Arbeitsgedächtnis, wenn der Agent gerade eine Aufgabe bearbeitet, für die nur drei davon zählen. Der Rest ist Ballast. Er macht den Agenten nicht klüger, er lenkt ihn ab und verteuert jeden Schritt.

Daraus folgt das Prinzip, das mein ganzes Setup trägt. Was immer geladen ist, muss winzig bleiben. Bewusst minimal. In meinem eigenen Agent OS, dem versionierten Regelwerk, mit dem ich täglich entwickle, steht dieser Satz fast wörtlich drin. Immer aktiv ist nur ein knapper Wegweiser plus die paar Regeln, die wirklich überall gelten. Wie ich committe, wie ich mich auf einen Server einlogge, wie ich das System sauber halte. Mehr nicht.

Alles andere lädt erst, wenn es dran ist. Eine Regel, die nur das Frontend betrifft, hat im Arbeitsgedächtnis nichts verloren, solange niemand am Frontend arbeitet. Sie wartet, bis sie gebraucht wird.

Damit das Passende von selbst auftaucht

Bleibt die zweite Hälfte, und die ist kniffliger. Wenn das meiste Wissen schläft, wie wacht es zum richtigen Zeitpunkt auf?

Der Mechanismus dahinter ist simpel. Jede Fähigkeit, jede Regel trägt einen kurzen Satz, der beschreibt, wann sie gilt. Der Agent sieht dauerhaft nur diese kurzen Sätze, eine Art Speisekarte. Passt einer davon zur aktuellen Aufgabe, klappt er den vollen Inhalt dahinter auf. Passt er nicht, bleibt er zu. So zieht sich der Agent das Detailwissen selbst heran, im Moment, in dem es passt, und ignoriert den Rest.

Ein Frontend-Regelwerk trägt dann oben genau diesen einen Satz, an dem der Agent erkennt, wann es zählt:

Solange niemand am Frontend arbeitet, sieht der Agent nur die eine Beschreibungszeile. Der Rest bleibt geschlossen.

Dasselbe Muster nutze ich auch außerhalb des Codes. Mein Content-Lager, aus dem dieser Text stammt, hat eine schlanke Einstiegsdatei, die nur den Überblick gibt. Was liegt wo, welche Quelle gehört wohin. Die Tiefe steckt in einer eigenen Gedächtnisstruktur daneben und wird erst nachgelesen, wenn ein Thema konkret wird. Die Einstiegsdatei bleibt ein Index.

Eine Frage der Informationsarchitektur

Wer das einmal durchdacht hat, merkt: hier wird nichts programmiert, hier wird sortiert. Was gehört dauerhaft präsent, was schläft bis zum Stichwort, woran erkennt das System den richtigen Moment. Das sind die klassischen Fragen der Informationsarchitektur, nur für ein neues Gegenüber.

Und genau das wird unterschätzt. Die meisten behandeln das Gedächtnis eines Agenten als Speicherproblem und kippen alles in eine große Datei. In Wirklichkeit ist es ein Ordnungsproblem. Eine Design-Disziplin mit eigenen Regeln, kein Behälter, den man möglichst voll macht.

Ein Agent wird nicht dadurch gut, dass er alles weiß. Er wird gut, wenn zur richtigen Frage die richtige Antwort vor ihm liegt und der ganze Rest aus dem Weg ist.