Memory

Das ist das erste Bauteil in Block II - und damit der erste Schritt aus dem Harness heraus. Alles bisher (Call, Message-History, System-Prompt, Tools & Loop, Guardrails) war Bordmittel: Code in deinem eigenen Prozess, ein paar Dateien, ein Loop. Memory ist das erste Bauteil, das als eigener Dienst neben dem Agenten stehen kann - mit eigener Datenhaltung, eigenem Container, eigenen Kosten. Bevor wir über solche Dienste reden, muss aber die Mechanik sitzen. Sonst kauft man ein Produkt für ein Problem, das man noch nicht verstanden hat.

Es gibt kein Erinnern. Es gibt nur Mitschicken.

Der LLM-Call ist zustandslos, und die Message-History hat gezeigt, was daraus folgt: Das Modell weiß beim zweiten Aufruf nicht, dass es einen ersten gab. Der Eindruck, dass sich „das Modell" etwas merkt, entsteht ausschließlich dadurch, dass wir bei jedem Aufruf das ganze Gespräch erneut in den Request legen.

Das gilt für Memory genauso - nur eine Stufe größer gedacht. „Der Agent erinnert sich, dass ich Markus heiße und Docker bevorzuge" heißt technisch immer: Irgendwo steht dieser Satz als Text, und irgendjemand hat ihn vor dem Call in den Prompt geschrieben. Es gibt kein Gedächtnis im Modell, keine Datenbank hinter der API, kein Konto auf der Gegenseite. Es gibt nur Text, der mitfährt.

Daraus folgt die Leitfrage dieses ganzen Bauteils - und sie hat nichts mit Produktnamen zu tun:

Wie kommen Informationen überhaupt in den Kontext?

Und die Nachfrage, an der sich alles Weitere entscheidet: Was schicken wir einmal pro Session mit, und was pro Anfrage?

Einmaliges Kontext-Gepäck: was immer dabei ist

Das ist der statische Teil - er wird beim Start des Agenten geladen und liegt danach in jedem Call an. Drei Sorten Dateien tauchen in der Praxis immer wieder auf:

SOUL.md - wer der Agent ist. Identität, Haltung, Rolle, Tonfall, was er ablehnt. Das ist die Datei, aus der der System-Prompt entsteht - bei einem Agenten mit Charakter oft der längste Einzelbrocken im Kontext. Wie man so eine Seele schreibt, ohne dass sie zu Kitsch verkommt, zeigt das Tutorial Die Seele in einer Datei.

AGENTS.md / CLAUDE.md - was der Agent über seine Umgebung wissen muss. Kein Charakter, sondern Betriebswissen: Wo läuft was, welche Befehle gelten, welche Randbedingungen sind nicht verhandelbar. Dieses Projekt fährt genau so. In seiner CLAUDE.md stehen Sätze wie „Alles läuft in Docker - immer. Keine Host-Node-Umwege", „asChild existiert im base-nova-Preset nicht", „messages/de.json und messages/en.json müssen synchron bleiben". Jeder dieser Sätze steht dort, weil sein Fehlen einmal einen Build gekostet hat. Der Agent liest sie zu Beginn jeder Sitzung - sie sind sein Gedächtnis für Dinge, die er sonst in jeder Sitzung neu falsch machen würde.

Skills und Instruktionsdateien, die nur bei Bedarf nachgeladen werden. Der Trick gegen ein überquellendes Kontext-Gepäck: Nicht alles Wissen ist immer nötig. Ein Agent kennt vorab nur eine kurze Liste („es gibt eine Anleitung Release, eine Video erstellen, eine Issue anlegen") und lädt die vollständige Anleitung erst, wenn die Aufgabe danach ruft. Der Katalog kostet ein paar Zeilen, der Inhalt kostet nur im Ernstfall.

Die Rechnung dazu, unromantisch: Dieses Gepäck liegt in jedem Call an, bevor der Nutzer ein Wort gesagt hat. Eine Seele plus Betriebswissen plus Werkzeugbeschreibungen sind schnell einige Tausend Tokens - bei jedem einzelnen Aufruf, in jeder Runde der Tool-Schleife. Wer sein Kontext-Gepäck nie nachwiegt, zahlt an einer Datei, die er vor drei Monaten geschrieben hat, in jeder Sekunde Laufzeit mit. Deshalb ist die Frage „muss das wirklich immer mit?" keine Sparsamkeitsmarotte, sondern die wichtigste Designfrage dieses Bauteils.

Kontext pro Anfrage: was zur Frage passt

Der dynamische Teil. Hier wird pro Anfrage entschieden, welche Bruchstücke aus einem großen Vorrat mitfahren. Drei Wege, und sie unterscheiden sich vor allem darin, wer entscheidet:

1. Retrieval - der Harness sucht. Vor dem Call werden zur Frage passende Stücke gesucht (per Ähnlichkeit, Stichwort oder beides) und in den Prompt eingesetzt. Der Agent merkt nichts davon; für ihn steht das Wissen einfach da. Klassisch, verlässlich, aber blind gegenüber allem, was die Suchanfrage nicht trifft.
2. Tool-Call - der Agent holt sich, was er braucht. Der Agent bekommt Werkzeuge wie search_memory oder get_facts und entscheidet selbst, ob und wonach er sucht. Das kostet eine zusätzliche Runde im Loop, ist aber ehrlicher: Der Agent weiß besser als eine Vorab-Suche, was ihm gerade fehlt - und er kann nachfragen, wenn das erste Ergebnis nichts hergibt.
3. Injektion durch den Dienst - der Memory-Dienst schreibt mit. Ein externes System hängt sich vor den Call, holt sich selbst, was es für relevant hält, und schiebt es in den Prompt. Das ist der Weg, den Dienste wie Honcho oder Mem0 typischerweise anbieten: eine Zeile Integration, und der Kontext ist „angereichert".

Diese Tabelle ist der Kern des ganzen Bauteils. Alles, was danach kommt - Vektor-Stores, Fakten-Extraktion, Wiki-Seiten -, sind bloß verschiedene Antworten auf die eine Frage, wer entscheiden darf, was in den Kontext kommt. Und sie hat keine allgemein richtige Antwort: Beim Retrieval ist die Relevanz reproduzierbar, beim Tool-Call situativ, bei der Injektion bequem. Wer Fehlern nachgehen muss, wird die Reihenfolge genau umdrehen wollen.

Der Bruch: ab hier verlassen wir den Harness

Alles bis hierhin war Harness - Dateien, die du selbst schreibst, und Code, den du selbst kontrollierst. Für viele Agenten ist damit Schluss, und das ist kein Mangel: Eine Markdown-Datei plus Message-History ist ein vollwertiges Gedächtnis. Dieses Repo führt sein Projekt-Memory genau so - als Verzeichnis mit einer Datei pro Fakt und einer Index-Datei, die in jede Sitzung geladen wird.

Ab jetzt geht es um Memory-Systeme außerhalb des Harness: eigene Dienste mit eigener Datenhaltung, eigenen Containern, eigenem Betrieb. Der Preis dafür ist nicht der Code - der ist meist erschreckend kurz. Der Preis ist, dass ein zweites System entsteht, das laufen, wachsen, altern, migriert und gelöscht werden muss. Deshalb die Landkarte zuerst.

Die Landkarte: vier Ansätze in je zwei Sätzen

RAG - Retrieval über Dokumente. Ein Korpus wird in Stücke geschnitten, eingebettet und zur Frage durchsucht; das Ergebnis landet im Prompt. Das ist auch Memory, nur über Handbücher statt über Gespräche - und bei uns schon vollständig erklärt, im RAG-Tutorial.

Honcho - ein Modell vom Nutzer, nicht von Dokumenten. Es speichert nicht nur, was gesagt wurde, sondern was daraus über die Beteiligten folgt: Peers, Sessions und im Hintergrund abgeleitete Repräsentationen, die man in natürlicher Sprache befragen kann („was weißt du über die Arbeitsweise dieses Nutzers?").

Mem0 - der klassische Einstieg: Aus dem Gesprächsverlauf werden per LLM Fakten extrahiert und als kurze Sätze in einem Vektor-Store abgelegt, die spätere Anfragen wieder hochholen. Als Bibliothek in wenigen Zeilen eingebaut, als Server selbst gehostet, als Cloud gemietet.

LLM Wiki - kein Produkt, sondern ein Muster: Der Agent pflegt seine Wissensseiten selbst, als verlinkte Markdown-Dateien. Statt einer Ähnlichkeitssuche über Textbrocken navigiert er Verweise zwischen Seiten - und das Ergebnis bleibt für Menschen lesbar und korrigierbar.

Ein Agent erinnert sich nicht - er schickt mit. Jede Form von Gedächtnis endet damit, dass Text vor dem Call in den Prompt geschrieben wird; die einzige Frage ist, wer ihn auswählt: der Harness (Retrieval), der Agent (Tool-Call) oder ein externer Dienst (Injektion).

Trenne dabei einmaliges Gepäck (SOUL.md, AGENTS.md, Skill-Katalog - liegt in jedem Call an und kostet in jedem Call) von Kontext pro Anfrage (das Wenige, das gerade zur Frage passt).

Und: Ein Memory-Dienst ist ein zweites System mit eigenem Betrieb. Eine Markdown-Datei plus Message-History ist erstaunlich weit tragfähig - der Dienst lohnt sich erst, wenn du mehr Gespräche hast, als du selbst überblicken kannst.