# Kontext & Memory: was der Agent sieht, behält und erst holt

> Kontextfenster, Memory und externes Wissen sauber trennen: Verdichten und Verdrängen, Sichtbarkeit und Haltbarkeit von Memory-Einträgen, Vorabkontext gegen Abruf, Quellenbindung und Enthaltung.

Track: [Agentic AI](https://physar.tech/learn/agentic-ai)  
Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-context-memory  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Kontext bewirtschaften: was der Agent gerade sieht, was er behält und was er erst holt

### Drei Speicher, die ständig miteinander verwechselt werden

„Der Agent erinnert sich nicht“ ist im Betrieb selten eine Aussage über ein Modell. Fast immer ist es eine Aussage darüber, dass niemand entschieden hat, welcher der drei Speicher zuständig sein sollte.

|  |  |
| --- | --- |
| Kontextfenster | Was in **diesem** Aufruf steht: Systemprompt, Werkzeugdefinitionen, Nachrichtenverlauf, Werkzeugergebnisse. Wird bei jedem Aufruf neu zusammengesetzt und ist danach weg. |
| Memory | Was der Agent selbst über Läufe hinweg **schreibt und wieder liest** — Notizen über seine eigene Arbeit, Entscheidungen, Präferenzen. Liegt in deinem Speicher, nicht im Modell. |
| Externes Wissen | Was ohnehin schon existiert und **nicht dem Agenten gehört**: Richtlinien, Tickets, Code, Handbücher. Wird abgefragt, nicht gemerkt. |

Die Zuständigkeiten überschneiden sich nicht zufällig, sondern nach einer klaren Regel: Wer die Quelle pflegt, entscheidet über den Speicher. Eine Urlaubsrichtlinie gehört der Personalabteilung — der Agent fragt sie ab und merkt sie sich nicht, sonst hat er eine veraltete Kopie. Dass ein bestimmter Kunde Rückmeldungen per E-Mail statt per Telefon will, hat der Agent selbst beobachtet — das gehört ins Memory.

> **Merksatz:** Merken ist eine Kopie. Jede Kopie kann veralten, muss gelöscht werden können und ist eine neue Stelle, an der Falsches steht.

### Das Kontextfenster ist Arbeitsspeicher, kein Gedächtnis

Das Kontextfenster ist das, worauf ein Modell beim Erzeugen einer Antwort zugreifen kann — die Antwort eingeschlossen. Es ist Arbeitsspeicher: Alles, was drinsteht, wurde in genau diesem Aufruf mitgeschickt, und nach dem Aufruf bleibt davon nichts, außer dein Code hat es aufgehoben.

Zwei Eigenschaften machen daraus eine Betriebsgröße statt einer Kapazitätsangabe. Erstens akkumuliert der Verlauf: Jede Runde schickt die bisherigen Nachrichten vollständig erneut. Zweitens wird das Fenster mit wachsender Füllung **schlechter**, nicht nur voller.

**Context Rot:** Mit steigender Tokenzahl sinkt die Fähigkeit des Modells, Information aus dem Kontext zuverlässig abzurufen. Ursache ist die Architektur: Jedes Token kann auf jedes andere aufmerken, was bei n Tokens n² paarweise Beziehungen ergibt.

Daraus folgt die Zielgröße, die dem Reflex widerspricht, möglichst viel mitzugeben: Gesucht ist der **kleinste** Satz aussagekräftiger Tokens, der das gewünschte Ergebnis wahrscheinlich macht — nicht der vollständigste. Ein größeres Fenster verschiebt die Grenze, es hebt sie nicht auf.

### Verdichten, verdrängen, auslagern

Es gibt drei Mechanismen, den Kontext eines langen Laufs klein zu halten. Sie sind nicht austauschbar, weil sie unterschiedliche Dinge verlieren.

|  |  |
| --- | --- |
| Verdichten | Ältere Teile des Verlaufs werden zusammengefasst und der Lauf mit der Zusammenfassung fortgesetzt. Erhält den roten Faden, verliert Details — und was die Zusammenfassung weglässt, ist unwiederbringlich weg. |
| Verdrängen | Alte Werkzeugergebnisse werden aus dem Verlauf entfernt und durch einen Platzhalter ersetzt, der ihre Entfernung anzeigt. Erhält die Struktur des Gesprächs, verliert die Nutzdaten. |
| Auslagern | Der Agent schreibt, was er behalten muss, in eine Datei außerhalb des Fensters und liest sie bei Bedarf zurück. Verliert nichts, kostet aber Runden für Schreiben und Lesen. |

Das Verdrängen ist der Mechanismus mit den meisten Stellschrauben und der überraschendsten Nebenwirkung. Gesteuert wird es über eine Auslöseschwelle (`trigger`), die Zahl der zuletzt erhaltenen Werkzeugpaare (`keep`), eine Mindestmenge zu entfernender Tokens (`clear_at_least`) und eine Ausnahmeliste (`exclude_tools`).

> **Überraschender Befund:** Werkzeugergebnisse zu entfernen **entwertet den zwischengespeicherten Prompt-Präfix**. Man spart Eingabetokens und bezahlt dafür einen neuen Cache-Schreibvorgang. Genau dafür gibt es `clear_at_least`: Es lohnt sich erst, wenn genug entfernt wird, um die Cache-Entwertung aufzuwiegen.

Für die Praxis heißt das: Aufräumen ist keine kostenlose Hygienemaßnahme, sondern ein Tausch. Wer bei jeder Kleinigkeit aufräumt, zahlt laufend Cache-Schreibkosten und spart wenig. Wer nie aufräumt, zahlt die volle Historie in jeder Runde.

### Memory ist eine Datei, die dein Code schreibt

Der wichtigste und meistübersehene Punkt am Agenten-Memory: Es liegt nicht beim Modellanbieter. Der Speicher arbeitet **auf der Client-Seite** — das Modell fordert eine Dateioperation nur an, deine Anwendung führt sie gegen einen Speicher aus, den du kontrollierst, und gibt das Ergebnis als `tool_result` zurück.

Das Modell fordert eine Operation an, etwa `view` auf `/memories` → **Dein Handler prüft den Pfad und lehnt alles außerhalb ab** → Dein Handler führt gegen deinen Speicher aus — Datei, Datenbank, Objektspeicher → Das Ergebnis geht als `tool_result` in den nächsten Aufruf

Die Operationen sind wenige und benennbar: `view`, `create`, `str_replace`, `insert`, `delete`, `rename`. Der Pfad `/memories` ist dabei ein **Präfix**, das dein Handler auf echten Speicher abbildet — etwa auf ein Verzeichnis je Nutzer oder auf Schlüssel in einer Datenbank. Genau hier entsteht die Sichtbarkeitsgrenze: Sie ist eine Entscheidung deines Handlers, keine Eigenschaft des Werkzeugs.

> **Merksatz:** Ein Pfad wie `/memories/../../secrets.env` erreicht Dateien außerhalb des Speichers. Jeder Pfad in jedem Befehl muss geprüft werden — kanonisch aufgelöst und gegen die Wurzel verglichen, nicht per Zeichenkettenvergleich.

Bemerkenswert ist die Annahme, unter der ein solcher Speicher entworfen wird. Die Betriebsanweisung, die mit dem Werkzeug einhergeht, formuliert sie ausdrücklich: Der Kontext könne **jederzeit zurückgesetzt** werden, weshalb jeder Fortschritt zu verlieren droht, der nicht im Speicherverzeichnis steht. Memory ist damit weniger ein Gedächtnis als ein Wiederanlaufpunkt.

Daraus folgt ein Muster für Aufgaben über mehrere Sitzungen, das sich lohnt, bevor die erste Sitzung beginnt: Eine Startsitzung legt die Dateien an — ein Fortschrittsprotokoll und eine Liste des Arbeitsumfangs. Jede folgende Sitzung liest sie zuerst und schreibt am Ende zurück, was erledigt ist. Entscheidend ist dabei eine Regel, die im Betrieb den Unterschied macht: Ein Punkt gilt erst nach **verifizierter** Fertigstellung als erledigt, nicht wenn der Code geschrieben ist. Sonst ist das Protokoll nach drei Sitzungen unbrauchbar, und der Wiederanlauf beginnt mit einer Lüge.

### Drei Achsen, die über jeden Memory-Eintrag entscheiden

Bevor etwas geschrieben wird, sind drei Fragen zu beantworten. Sie werden fast nie gestellt, weil das Schreiben technisch trivial ist.

|  |  |
| --- | --- |
| Sichtbarkeit | Wer darf diesen Eintrag später lesen: nur dieser Nutzer, alle Nutzer dieses Mandanten, oder jeder? Die Voreinstellung sollte die engste sein. |
| Haltbarkeit | Wie lange bleibt der Eintrag wahr? Eine Kundenpräferenz Monate, eine Clusterauslastung Minuten. Ohne Verfallsdatum wird aus einer Beobachtung eine falsche Tatsache. |
| Vertrauen | Woher stammt der Inhalt? Aus einer bestätigten Aktion, aus einer Modellschlussfolgerung oder aus fremdem Text? Die Herkunft muss am Eintrag stehen, nicht in der Erinnerung des Teams. |

Die drei Achsen sind unabhängig. Ein Eintrag kann eng sichtbar, lange haltbar und trotzdem aus einer unsicheren Quelle sein — dann ist er dauerhaft falsch für genau eine Person. Erst wenn alle drei bewusst gesetzt sind, ist ein Memory-Modell beschrieben.

### Die Sichtbarkeitsgrenze ist der teuerste Fehler

### Ein geteiltes Memory über 40 Firmenkunden

Ein Support-Agent bedient 40 Firmenkunden über eine gemeinsame Instanz. Ein Entwickler hat eine Memory-Funktion eingebaut: Was der Agent in einem Gespräch lernt, schreibt er nach `/memories/learnings.md`. Der Handler bildet diesen Pfad auf ein einziges Verzeichnis ab.

**Anforderungen**

- Kein Kunde darf Inhalte aus dem Gespräch eines anderen Kunden sehen
- Der Agent soll trotzdem über Läufe hinweg dazulernen
- Ein Kunde muss löschbar sein, ohne die Erkenntnisse aller anderen zu verlieren

**Schritte**

- Befund: Die Sichtbarkeit ist nicht falsch konfiguriert, sondern nie konfiguriert worden. Der Handler kennt den Mandanten gar nicht.
- Erste Korrektur: Der Mandant kommt nicht aus dem Modellkontext, sondern aus der authentifizierten Sitzung, und der Handler bildet `/memories` auf `/<mandant>/memories` ab.
- Zweite Korrektur: Der Mandantenschlüssel darf niemals aus einem Werkzeugargument stammen. Sonst kann ein Prompt ihn setzen — und die Grenze steht wieder im Text statt im Code.
- Dritte Korrektur: Gemeinsam nutzbares Wissen (Produktverhalten, bekannte Fehler) bekommt einen ausdrücklich globalen Bereich mit eigener Schreibregel, statt versehentlich im Mandantenbereich zu landen.
- Gegenprobe: Ein Testlauf als Mandant B, der nach einer Zeichenkette aus dem Gespräch von Mandant A fragt — und ein Löschtest, der nachweist, dass nach dem Entfernen von A nichts von A übrig ist.

**Merksatz:** Eine Sichtbarkeitsgrenze, die aus dem Modellkontext abgeleitet wird, ist keine Grenze. Sie muss aus der Sitzung kommen, in der Ausführungsschicht durchgesetzt und mit einem Testlauf belegt sein.

### Schreib-Policy: nicht alles Beobachtete ist wissenswert

Der verbreitetste Memory-Entwurf ist „nach jedem Lauf eine Zusammenfassung schreiben“. Er ist attraktiv, weil er keine Entscheidung verlangt, und teuer, weil er alle drei Achsen unbeantwortet lässt. Nach einigen Wochen steht dort eine Mischung aus veralteten Zahlen, Vermutungen und Wiederholungen.

- **Beständig** — der Inhalt bleibt über Tage bis Monate wahr. Eine aktuelle Clusterauslastung erfüllt das nicht und gehört in eine Abfrage.
- **Wiederverwendbar** — er wird in künftigen Läufen tatsächlich gebraucht. Was einmalig war, ist ein Protokolleintrag, kein Gedächtnis.
- **Nicht billig neu herleitbar** — was ein Werkzeugaufruf in 200 Millisekunden liefert, muss man nicht als möglicherweise veraltete Kopie halten.
- **Herkunft benennbar** — bestätigte Aktion, eigene Schlussfolgerung oder fremder Text. Ohne diese Angabe ist der Eintrag später nicht bewertbar.
- **Löschbar zurechenbar** — dem Eintrag muss anzusehen sein, zu welchem Nutzer oder Mandanten er gehört, sonst ist eine spätere Löschung unmöglich.

Die Regel greift auch in die andere Richtung: Was diese fünf Bedingungen erfüllt, sollte tatsächlich geschrieben werden. Ein Agent, der bei jedem Lauf dieselbe Erkenntnis neu erarbeitet, zahlt sie jedes Mal erneut.

### Memory ist die haltbare Form der indirekten Injection

Ein Agent, der aus fremden Inhalten lernt und das Gelernte behält, hat einen Angriffspfad mit Nachwirkung. Die zugrunde liegende Schwachstelle ist benannt: Bei **indirekter Prompt Injection** verarbeitet das Modell externe Quellen — Websites, Dateien —, deren Inhalt sein Verhalten verändert, sobald er interpretiert wird.

Der Unterschied zum bekannten Fall ist die Dauer. Eine Injection im Verlauf endet mit dem Lauf. Eine Injection, die als Erkenntnis ins Memory geschrieben wurde, wird bei jedem künftigen Lauf zu diesem Kunden erneut eingelesen — und sieht dann aus wie eine eigene, vertrauenswürdige Notiz.

**Kurzcheck:** In einer eingehenden Kunden-E-Mail steht ein Satz, der als Anweisung formuliert ist. Der Agent hat ihn als Erkenntnis ins Langzeit-Memory geschrieben. Wo setzt die wirksamste Maßnahme an?

- [x] Beim Schreiben: fremder Inhalt darf nur als zitierte Beobachtung mit Herkunft gespeichert werden, nie als Regel
- [ ] Beim Lesen: das Modell anweisen, Anweisungen aus dem Memory zu ignorieren
- [ ] Einen Filter vorschalten, der eingehende Mails auf Injection-Muster prüft
- [ ] Das Langzeit-Memory abschalten und nur den Sitzungsverlauf nutzen

> Trennt Daten von Anweisungen an der Stelle, an der die Vermischung entsteht. Externer Inhalt wird als solcher gekennzeichnet und behält diese Kennzeichnung beim späteren Lesen.

### Wissen vorab in den Kontext oder erst zur Laufzeit holen

Für externes Wissen gibt es zwei Grundformen, und die Wahl zwischen ihnen ist eine Architekturentscheidung mit Kostenfolge, keine Geschmacksfrage.

|  |  |
| --- | --- |
| Vorab in den Kontext | Das Wissen steht im Systemprompt oder im Vorspann jedes Laufs. Kein Abrufschritt, keine Fehlsuche, cachefähig — aber es wird in jedem Lauf bezahlt, auch wenn es nicht gebraucht wird. |
| Als Werkzeug zur Laufzeit | Der Agent sucht, wenn er etwas braucht. Der Kontext bleibt klein und aktuell — aber jede Suche kostet eine Runde, kann danebengreifen und macht die Antwort von der Trefferqualität abhängig. |

Die Entscheidungsregel ist eine Verteilungsfrage, keine Größenfrage. Wenn über 90 Prozent der Anfragen aus einem einzigen, stabilen Dokument beantwortbar sind, gehört dieses Dokument vorab in den Kontext — mit einem Suchwerkzeug für den Rest. Wenn sich die Anfragen breit über viele Quellen verteilen, ist der Vorabkontext eine Wette, die man in jedem Lauf verliert.

> **Preis der richtigen Wahl:** Vorabkontext ist bequem und wird zum Klotz: Er wächst mit jeder Ausnahme, die jemand „sicherheitshalber“ ergänzt — bis der Vorspann größer ist als jede Antwort und der Cache bei jeder Änderung entwertet wird.

Der Cache verschiebt die Rechnung, und zwar erheblich: Ein zwischengespeicherter Präfix wird beim Lesen mit einem Bruchteil des Eingabepreises berechnet, während das Schreiben etwas über dem Normalpreis liegt. Ein großer, **stabiler** Vorspann ist damit deutlich billiger, als die reine Tokenzahl vermuten lässt. Die Bedingung ist die Stabilität: Der Cache-Präfix hängt an einem Hash über alles bis zum Haltepunkt — ändert sich irgendetwas davor, greift er nicht mehr. Ein Vorspann mit Zeitstempel oder Nutzername an erster Stelle ist deshalb kein Vorspann, sondern eine wiederkehrende Vollzahlung.

### Suchen, belegen, und zugeben, dass nichts da war

Ein Suchwerkzeug in der Hand eines Agenten ist kein Retrieval-System mit fester Anfrage, sondern eine Schleife: Der Agent formuliert, bewertet, formuliert um. Zwei Fehlformen sind im Protokoll leicht zu erkennen.

- **Wiederholung ohne Umformulierung** — dieselbe Anfrage mehrfach. Behandelt wird das als Stillstand: Die Strategie muss sich ändern, nicht die Zahl der Versuche.
- **Aufgeben nach dem ersten Treffer** — der erste Fund wird als Antwort genommen, obwohl er die Frage nur streift. Hier fehlt ein Abbruchkriterium, das Relevanz prüft statt Existenz.

Damit die Antwort überhaupt prüfbar wird, braucht sie eine **Quellenbindung**: Jede Sachaussage verweist auf das Dokument, aus dem sie stammt. Das ist keine Formatierungsvorgabe, sondern die Voraussetzung dafür, dass ein Mensch in Sekunden feststellen kann, ob der Agent recht hat — und die einzige Möglichkeit, eine falsche Aussage auf eine falsche Quelle statt auf ein falsches Modell zurückzuführen.

Der schwierigste Fall ist der leere. Wenn nichts Relevantes gefunden wurde, ist die richtige Ausgabe die **Enthaltung**: dass nichts gefunden wurde, was gesucht wurde, und was ein Mensch als Nächstes tun kann. Ein Agent, der stattdessen aus dem Modellwissen antwortet, liefert genau dort seine schlechteste Antwort, wo das Team am wenigsten nachprüft — bei den seltenen Fragen.

### Jede Kontextmaßnahme hat einen Preis

|  |  |
| --- | --- |
| Verdichten | Hält lange Läufe am Leben — verliert Details unwiederbringlich, und was in der Zusammenfassung falsch steht, wird ab da als Tatsache weitergetragen. |
| Werkzeugergebnisse verdrängen | Senkt die Eingabetokens deutlich — entwertet den Cache-Präfix und kostet einen neuen Schreibvorgang bei jedem Aufräumen. |
| Memory schreiben | Spart Wiederholungsarbeit über Läufe hinweg — erzeugt eine Kopie, die veralten, verrutschen und vergiftet werden kann, und die gelöscht werden können muss. |
| Vorab in den Kontext | Kein Abrufschritt, kein Fehlgriff, cachefähig — wird in jedem Lauf bezahlt und wächst über die Zeit unkontrolliert. |
| Abruf zur Laufzeit | Kontext bleibt klein und aktuell — die Antwortqualität hängt an der Trefferqualität, und jede Suche kostet eine Runde. |
| Enthaltung erzwingen | Verhindert erfundene Antworten bei Wissenslücken — erhöht die Zahl der Fälle, die Menschen nacharbeiten, und wird als Qualitätsverlust wahrgenommen. |

Die Tabelle ist auch eine Reihenfolge. Wer noch keine Sichtbarkeitsgrenze im Memory hat, sollte nicht am Cache optimieren; wer noch keine Enthaltung hat, nicht an der Suchstrategie. Die Maßnahmen mit dem größten Schadenspotenzial gehören zuerst.

### Was der Check prüft

- Für einen konkreten Inhalt entscheiden, ob er ins Kontextfenster, ins Memory oder in eine Abfrage gehört.
- Eine Sichtbarkeitsgrenze so ziehen, dass sie aus der Sitzung stammt und nicht aus dem Modellkontext.
- Eine Schreib-Policy formulieren, die Beständigkeit, Wiederverwendbarkeit und Herkunft prüft.
- Eine Konfiguration zur Kontextverdrängung lesen und die Einstellung finden, die mehr kostet als sie spart.
- Vom Anhängen des Vollkontexts auf gezielten Abruf umbauen, ohne die Antwortqualität zu verlieren.
- Wiederholte Suchanfragen als Stillstand behandeln statt als Fleiß.
- Den leeren Trefferfall als Ergebnis gestalten statt als Lücke, die das Modell füllt.
- Fremden Inhalt so ins Memory schreiben, dass er beim Wiederlesen nicht als eigene Regel gelesen wird.

Der gemeinsame Nenner aller acht Punkte: Nichts davon ist eine Eigenschaft des Modells. Jede dieser Entscheidungen fällt in deinem Code, und jede lässt sich mit einem Testlauf belegen.

## Quellen

- Anthropic — Memory tool — https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool
- Anthropic — Context editing — https://platform.claude.com/docs/en/build-with-claude/context-editing
- Anthropic — Context windows — https://platform.claude.com/docs/en/build-with-claude/context-windows
- Anthropic Engineering — Effective context engineering for AI agents — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- OWASP GenAI Security Project — LLM01 Prompt Injection — https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- Anthropic — Prompt caching — https://platform.claude.com/docs/en/build-with-claude/prompt-caching