Entwicklung eines Agentenspeichers, der das Gespräch überdauert, ohne Daten anzuhäufen.

Eine Szene, die sich bei fast jedem Agenten, der in die Produktion kommt, wiederholt, sieht so aus.

Am Montag sagt ein Nutzer, er verwalte die Nordwest-Region, kümmere sich nur um aktive Projekte und ertrage lange Antworten nicht. Der Agent antwortet mit „Verstanden“, und für den Rest der Sitzung bedeutet das: Die Antworten sind kurz, beschränken sich auf die Nordwest-Region und enthalten keine Entwürfe. Der Nutzer ist zufrieden.

Am Dienstag startet dieselbe Person ein neues Chat-Gespräch und fragt nach dem Fortschritt ihrer Projekte. Der Agent fragt fröhlich, über welche Region er mehr erfahren soll.

Der Gesichtsausdruck dieses Nutzers ist der Grund, warum man gründlich über das Speichern von Informationen nachdenken muss.

Warum das Speichern aller Daten fehlschlägt

Fast jeder Entwickler greift zum gleichen Lösungsansatz: Die gesamte Konversation speichern und sie morgen wieder laden. Das scheint offensichtlich, ist aber eine Falle. Die Art und Weise, wie dieser Ansatz scheitert, lehrt mehr über die Gestaltung von Agenten als die meisten Tutorien.

Nehmen wir an, die gesamte Historie wird gespeichert und jedes Mal wiedergegeben, wenn der Benutzer zurückkehrt. Die Ereignisse verlaufen in einer vorhersehbaren Reihenfolge.

In Woche eins funktioniert es. Der Agent erinnert sich tatsächlich an alles, und man fühlt sich klug. Das ist die gefährliche Phase, denn es scheint das Design zu bestätigen.

In Woche drei wird es langsam und kostspielig. Jeder Schritt beinhaltet nun Tausende von Tokens aus alten Chats. Man zahlt für Smalltalk vom Montag, während man eine Frage vom Freitag beantwortet. Das Kontextfenster ist der Schreibtisch des Agents – man hat es bereits mit den Unterlagen von letzter Woche bedeckt, bevor die heutige Arbeit beginnt.

In Woche sechs nimmt die Situation eine schlechte Wendung. Niemand warnt einen vor dieser Phase. In alten Gesprächen finden sich Aussagen, die nicht mehr zutreffen. Der Nutzer konzentrierte sich auf den Nordwesten, bis eine Beförderung ihn für das ganze Land verantwortlich machte. Das Projekt verzögerte sich, bis es schließlich veröffentlicht wurde. Wenn alles nochmals abgespielt wird, muss der Agent alte und aktuelle Fakten gleichermaßen berücksichtigen. Das Problem ist nicht mehr, dass zu wenig in Erinnerung bleibt – vielmehr erinnert sich der Agent an zu viel, ohne zu wissen, was bereits veraltet ist.

Das Wiederabspielen vollständiger Historien ist im Grunde eine Maschine zur Erzeugung veralteter Kontexte. Deshalb war die Frage „Wie speichere ich alles?“ nie die richtige Frage. Die richtigen Fragen lauten:

Welche Informationen lohnt es sich aufzubewahren, welche sollten bei Bedarf abgerufen werden und welche sollten verworfen und von vorne erstellt werden?

Wenn man diese Fragen beantwortet, ergibt sich automatisch die passende Speicherverwaltung.

Ein dreistufiges Design

Vergleichen Sie das mit der Art und Weise, wie Sie im Beruf mit Informationen umgehen. Manche Dinge behalten Sie während eines Meetings im Kopf und vergessen sie anschließend gerne wieder. Andere schreiben Sie in ein Notizbuch, weil Sie sie im nächsten Monat benötigen. Wieder andere merken Sie sich nie, da sie sich ändern und Sie sie jedes Mal überprüfen. Auch Agenten benötigen diese drei Ebenen.

Ebene 1: Sitzungsspeicher, der verschwinden soll

Diese Ebene enthält alles, was mit dem aktuellen Gespräch zusammenhängt: die Nachrichtenhistorie, die Ergebnisse von Zwischenschritten mit Werkzeugen, eine halb fertige mehrstufige Aufgabe sowie den LangGraph-Zustand beim Wechsel zwischen Knoten.

Sobald die Sitzung endet, darf diese Ebene verschwinden. Das ist keine vergessene Speicherung – sie ist dazu konzipiert, zu verschwinden, und das ist sogar ein Vorteil.

Anfänger fühlen sich deswegen schuldig, obwohl das nicht nötig ist. Die detaillierte Aufzeichnung eines Gesprächs ähnelt einem Treffen: Es zählt nicht die Transkription, sondern die Schlussfolgerungen. Die interessante Frage ist daher, was nach Abschluss einer Sitzung in die zweite Ebene überführt wird.

Nicht die Transkription. Ein kleiner, expliziter Extraktionsschritt ermittelt drei Kategorien:

1. Stabile Fakten über den Benutzer, wie zum Beispiel „verantwortlich für die Northwest-Region“, gültig bis zur Aufhebung.
2. Präferenzen, wie zum Beispiel „kürzere Antworten wünscht“ und „Entwurfsprojekte ausschließen“.
3. Entscheidungen, wie zum Beispiel „Einverständnis mit einem wöchentlichen Zusammenfassungsformat“.

Das Gespräch an jenem Montag könnte bis zu viertausend Token umfassen. Was dauerhaft erhalten bleiben sollte, sind etwa vierzig Token mit strukturierten Fakten – das entspricht einer Kompression um das Hundertfache. Im Gegensatz zu einem Zusammenfassung bleibt nichts Wichtiges unklar, denn man hat benannte Kategorien extrahiert statt nur einen allgemeinen Eindruck. Zusammenfassungen entfernen heimlich Einschränkungen, während die Extraktion die Lösung ist: Eine Präferenz landet entweder Wort für Wort in der Liste oder nicht, und dafür kann man einen Test schreiben.

Ebene 2: Langzeitgedächtnis – klein, strukturiert und editierbar

Das ist der kompakte Speicher, der über Sessions hinweg bestehen bleibt – das Notizbuch des Benutzers. Widerstehen Sie dem Drang, clever zu sein. Genau ein langweiliges Format sorgt dafür, dass es funktioniert:

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Eine Handvoll Dutzend JSON-Sätze pro Benutzer, die zu Beginn jeder Sitzung in den Kontext geladen werden. Sie sind kostengünstig genug, um stets enthalten zu werden, und klein genug, um keine Überlastung zu verursachen.

Drei Regeln sorgen dafür, dass alles funktionsfähig bleibt.

Gestrukturierte Informationen sind besser als Prosa. Unklare Beschreibungen wie „Diese Person kümmert sich wahrscheinlich um den Nordwesten und mag Kürze“ sind später nutzlos. Im Gegensatz dazu können getrennte Fakten dem Benutzer gezeigt, korrigiert und einzeln entfernt werden.

Markieren Sie alles mit einem Zeitstempel und ersetzen Sie statt hinzuzufügen. Wenn der Benutzer vom Nordwesten zum National- Bereich wechselt, fügen Sie keinen zweiten Faktor neben den ersten hinzu – Sie überschreiben ihn. Sobald der Speicher sowohl „kümmert sich um den Nordwesten“ als auch „kümmert sich um den National- Bereich“ enthält, entsteht ein Problem mit veralteten Daten, das durch eine verbundene Datenbank noch schlimmer wird, weil die Informationen dann für immer veraltet bleiben.

Lassen Sie den Benutzer es sehen und korrigieren. Schon ein einfacher Befehl wie „So erinnere ich mich an Sie“ verändert die Situation. Erinnerungen, die ein Benutzer nicht überprüfen kann, werden letztendlich zu Erinnerungen, denen er nicht mehr vertraut – meist in dem Moment, in dem der Assistent mit voller Überzeugung etwas erwähnt, das bereits vor Monaten veraltet ist.

Alles, was man nachschlagen kann, bleibt außerhalb von Tier 2. Das gehört zu Tier 3, und Teams verschwenden dort am häufigsten ihre Energie an die falschen Dinge.

Tier 3: Nachfragebasierte Regeneration, absichtlich nicht gespeichert

Hier befindet sich alles, was von selbst ändert: Projektstatus, Zahlen, Daten, Organigramme, aktuelle Werte sowie der Inhalt von Datenbanken und APIs.

Die Regel lautet, dass diese Ebene niemals auswendig gelernt werden darf. Zitieren Sie sie nicht, speichern Sie sie nicht im Gedächtnis und übertragen Sie sie nicht aus einem früheren Chat. Im Bedarfsfall ruft der Agent ein Tool auf, um den aktuellen Wert zu erhalten.

Schriftlich ausgedrückt klingt das offensichtlich. Es handelt sich dabei auch um die am stärksten missbrauchte Regel im Agenten-Gedächtnis, denn das Speichern aktueller Daten als Gedächtnisinhalt erscheint wie eine Optimierung. Tatsächlich handelt es sich dabei um eine Zeitbombe mit langsam brennendem Zünder:

• Es wird „Projekt Falcon ist verzögert“ gespeichert, obwohl Falcon anschließend doch fertiggestellt wird. Wochenlang spricht der Agent über ein Projekt, das bereits geliefert wurde.
• Es wird „das Team hat 8 Mitglieder“ gespeichert, obwohl anschließend zwei Personen hinzukommen. Jede Angabe zur Kapazität ist somit falsch.

Die präziseste Zusammenfassung der gesamten Architektur ist vermutlich diese:

Nutzen Sie das Gedächtnis für Fakten über die Person. Nutzen Sie Tools für Fakten zu allem anderen.

Die Präferenzen der Benutzer ändern sich selten, und die Benutzer informieren einen, wenn das der Fall ist. Die Welt ändert sich ständig, sagt einem aber nichts. Denken Sie daher an den Benutzer und befragen Sie die Welt.

Fehlerfall: „Alles teilen“ trifft auf mehrere Agenten

Das ist die vereinfachte Version. Der Weg dorthin führte über einen Vorfall in einem fiktiven Zwei-Agenten-System bei einem Grid-Dienstleister.

Agent A sprach mit den Benutzern und sammelte deren Berichtsanforderungen ein. Agent B erstellte die Berichte. Als A die Arbeit an B weitergab, wiederholte das Team den Anfängerfehler in größerem Maßstab: Sie übergaben B den gesamten Kontext von A – inklusive des gesamten Gesprächsverlaufs, aller Tool-Ausgaben sowie des gesamten Zustands. Die Begründung schien schlüssig zu sein. Bedeutet doch mehr Kontext sicherlich einen besser informierten B, oder?

Die Art und Weise, wie es schiefging, ist der nützliche Teil. Während einer Sitzung überlegte ein Benutzer laut vor sich hin gegenüber Agent A: Was wäre, wenn die archivierten Projekte mit einbezogen würden? Nach weiterem Nachdenken entschied er jedoch, dass das die Gesamtwerte verfälsche, und schlug vor, sie auszulassen. Es handelte sich dabei um ganz normales laut gedachtes Überlegen, und A handhabte die Situation korrekt.

Dann wurde die Übertragung gestartet und B erhielt den gesamten Transkriptinhalt, einschließlich der Nebenthemen. Doch B hatte keinen Teil des Gesprächskontextes von A, um dies beurteilen zu können. Im Übertragungsinhalt stand nirgends, dass die Idee mit den archivierten Projekten abgelehnt worden war, und außerhalb des Kontexts sah es wie eine Anweisung aus. B fügte den archivierten Projekten treu hinzu, wodurch die Werte in einem offiziellen Bericht aus einem Grund falsch waren, den niemand durch das Lesen von Bs Code herausfinden konnte – obwohl Bs Code in Ordnung war.

Das ist die mehragentenbasierte Version von allem oben: Eine Übergabe stellt eine Sitzungsgrenze dar. Wenn Agent B mit seiner Aufgabe beginnt, handelt es sich um das neue Chat-Dialog vom Dienstag. Das Team hatte denselben Fehler begangen, indem es „alles speichern“ versuchte – allerdings zwischen den Agenten und nicht über mehrere Tage hinweg.

Die Lösung war dieselbe. Anstelle des Übermittelns von Transkripten kam ein strukturiertes Übergabepaket zum Einsatz, im Grunde eine einmalige Hilfsschicht, die A für B erstellt.

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

Das sind etwa fünfzig Token ohne Ambiguität. B erhält die Schlussfolgerungen, nicht den umständlichen Weg dorthin. Die Kategorie „archived-projects“ für Fehler wurde unmöglich – sie konnten weder erfasst noch behandelt werden, denn aufgegebene Ideen können physisch nicht überleben, wenn sie in eine Anforderungsliste aufgenommen werden.

Nehmen Sie einen Satz in jedes Mehr-Agenten-Design: Die Agenten sollten einander Schlussfolgerungen weitergeben, niemals Transkripte.

Eine Checkliste für diese Woche

Fünf Entscheidungen, die Sie bezüglich eines bestehenden Agenten treffen können:

1. Lassen Sie das Sitzungsgedächtnis verschwinden. Fügen Sie am Ende der Sitzung oder nach N Schritten einen Extraktionsschritt hinzu, der nur Fakten, Präferenzen und Entscheidungen übernimmt und den Rest zusammen mit dem Chat verfallen lässt.
2. Behalten Sie Tier 2 als langweiliges JSON bei. Diskrete Elemente, Zeitstempel, Erneuerungen. Niemals ein wachsender Prosa-Block und niemals nur für Anhänge geeignet.

Geben Sie den Nutzern einen Einblick in ihre Erinnerungen. Ein „Was erinnern Sie sich an mich?“-Ansatz, auch wenn er noch rudimentär ist, schafft Vertrauen und identifiziert automatisch veraltete Informationen.

Führen Sie eine Stufe 2-Prüfung für Fakten über die Welt durch. Alles, was ein Tool aktuell abrufen kann – wie Statusangaben, Zahlen, Daten und Mengen – sollte ersetzt werden. Die Erinnerung dient dem Nutzer, Tools dienen der Welt.

Übergeben Sie Schlussfolgerungen strukturiert. Verwenden Sie eine strukturierte Übertragung mit Aufgabe, Anforderungen und Einschränkungen. Wenn Ihre Übertragung eine unstrukturierte Transkription enthält, haben Sie bereits das oben genannte Problem übertragen, ohne es zu bemerken.

Die Schlussfolgerung

Der Glaube, dass Erinnerung bedeutet, mehr zu speichern, ist völlig falsch. Jedes der oben genannten Probleme – von verlockenden Lösungen für Amnesie bis hin zu veralteten Fakten oder Berichten über archivierte Projekte – hat seine Wurzel darin, zu unvorsichtig zu viel gespeichert zu haben.

Eine gute Agentenmemorierung beruht hauptsächlich auf der Fähigkeit, zu vergessen. Der Sitzungszustand kann verloren gehen, langfristige Notizen bleiben kurz genug, um sie auf einen Blick zu lesen, und nichts, was die Welt neu mitteilt, wird gespeichert. Die Agenten, die sich wirklich persönlich anfühlen, sind nicht diejenigen, die alles behalten. Sie merken sich die richtigen vierzig Token.