Das Gedächtnis

Fangen wir mit der unangenehmen Hälfte an: Ein Sprachmodell hat kein Gedächtnis. Es erinnert sich an keine einzige vergangene Sitzung, und daran ändert auch das beste Werkzeug nichts.

Was es gibt, ist etwas anderes, und es funktioniert überraschend gut: Der Agent sieht zu Beginn jeder Sitzung an denselben Stellen nach. Was dort steht, weiß er. Was nicht dort steht, ist weg.

Damit wird aus einer Frage über Erinnerung eine Frage über Orte.

Fünf Orte

Das Gespräch selbst. Alles, was Sie in dieser Sitzung gesagt haben, steht im Kontextfenster und wirkt sofort. Es ist der schnellste Ort und der einzige flüchtige: Beim nächsten Start ist er leer.

Die Projektanweisung. Was Sie einmal hineingeschrieben haben, steht in jeder Sitzung wieder da, wortgleich. Sie ist der Ort für alles, was immer gilt, und Gegenstand von Kapitel 03.

Die Notizen des Werkzeugs. Neuere Agenten schreiben sich selbst auf, was ihnen aufgefallen ist: welcher Baubefehl der richtige ist, welche Korrektur Sie zweimal getippt haben, welche Eigenart dieses Projekt hat. Der Hersteller nennt das automatisches Gedächtnis, und Sie füllen es nicht selbst.

Das Projekt. Der Code steht ohnehin da und lässt sich lesen. Dazu kommt die Historie: Branch, Zustand und die letzten Commits gehören zu dem, was der Agent beim Start vor sich hat, ohne dass jemand danach fragt. Warum das mehr ist als eine Formalie, steht in Kapitel 04.

Was daneben liegt. Notizen, Entscheidungen, eine Wissensbasis: alles, was Sie außerhalb des Projekts führen und ihm zugänglich machen. Der Ort mit der größten Reichweite und dem meisten Aufwand, siehe Kapitel 06.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Wer welchen Ort füllt

Die Aufteilung ist der praktisch wichtigste Teil dieses Kapitels, weil sie darüber entscheidet, wo Sie etwas hinschreiben.

Ort	Wer schreibt	Wie lange
Gespräch	Sie und der Agent	diese Sitzung
Projektanweisung	Sie	dauerhaft
Notizen des Werkzeugs	der Agent	dauerhaft, auf diesem Rechner
Code und Historie	beide	dauerhaft, geteilt
Wissensbasis daneben	der Agent, von Ihnen gelenkt	dauerhaft, über Projekte hinweg

Zwei Spalten lohnen einen zweiten Blick. Die Notizen des Werkzeugs sind maschinenlokal: Sie liegen außerhalb des Projekts und gehen an keinen Kollegen. Die Historie dagegen ist geteilt, weshalb eine Commit-Nachricht auch für andere lesbar sein sollte.

Was das Verdichten damit macht

Das gilt für eine Sitzung, die im Gespräch wächst, so wie es dieser Kurs durchgehend voraussetzt. Ein Agent, der stattdessen einmalig für eine Aufgabe aufgerufen wird und sich danach beendet, so wie es in einer Automatisierung üblich ist, kennt das Problem nicht: Er beginnt jedes Mal mit leerem Gespräch.

Lange Sitzungen werden irgendwann zusammengefasst, damit das Kontextfenster nicht überläuft, von selbst kurz bevor es voll ist oder von Hand, wenn Sie es anstoßen. Das Gespräch wird dabei ersetzt und geht durch die Hand desjenigen, der die Zusammenfassung schreibt.

Für die fünf Orte heißt das:

• Projektanweisung und Notizen des Werkzeugs werden neu von der Platte gelesen. Sie stehen danach wieder vollständig da.
• Code und Historie liegen ohnehin auf der Platte und lassen sich jederzeit erneut lesen.
• Das Gespräch hängt an der Zusammenfassung. Was für wichtig gehalten wurde, überlebt.

Daraus folgt die Gewohnheit, die diesem Kapitel zugrunde liegt: Wenn Sie dieselbe Sache zum zweiten Mal erklären, gehört sie an einen der vier dauerhaften Orte.

Ein Hebel, den viele nicht kennen

Das Verdichten lässt sich lenken. Man kann dem Befehl mitgeben, worauf die Zusammenfassung achten soll, und die Dokumentation beschreibt den Unterschied nüchtern:

The summary keeps what you choose instead of what the automatic pass guesses is important. (externe Seite, code.claude.com)

Wer eine lange Fehlersuche hinter sich hat und gleich weiterarbeiten will, sollte diesen Zusatz benutzen. Er kostet fünf Wörter.

Die fünf Orte aus Ebene 1 verhalten sich technisch verschieden, und der Unterschied läuft entlang einer einzigen Frage: Steht es beim Start schon im Fenster, oder muss es erst geholt werden?

Geladen oder nachschlagbar

Beim Start füllt sich das Kontextfenster ohne Ihr Zutun. Hinein gehen die Systemanweisung, die Projektanweisungen in voller Länge, die Selbstnotizen des Werkzeugs bis zu einer Grenze, Angaben zur Umgebung samt Git-Zustand, die Namen der verfügbaren Tools und die Kurzbeschreibungen der Skills.

Das ist der Teil, der jeden Schritt der Sitzung mitbezahlt wird. Alles andere liegt daneben und kommt erst herein, wenn es gebraucht wird: eine Datei, die gelesen wird, eine pfadgebundene Regel, deren Muster passt, ein Skill, der aufgerufen wird.

Naheliegende Rückfrage an dieser Stelle: Geschieht das wirklich immer, oder holt sich das Modell die Dinge, sobald es sie für nützlich hält? Der Hersteller ist da eindeutig:

Before you type anything: CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context. (externe Seite, code.claude.com)

Die Umgebungsangaben gehören dazu und stehen dort als eigener Posten mit rund 280 Token: Arbeitsverzeichnis, Plattform, Kommandozeile, Fassung des Betriebssystems und die Auskunft, ob überhaupt ein Git-Repository vorliegt. Branch, Zustand und die letzten Commits kommen als eigener Block ganz am Ende der Systemanweisung dazu. Gefragt wird vorher nichts davon.

Die Trennlinie läuft mitten durch einzelne Posten. Von angebundenen Tools kommen die Namen mit, damit der Agent weiß, was es gibt; die vollständigen Beschreibungen bleiben liegen und werden einzeln nachgeholt. Von einem Skill kommt die Kurzbeschreibung, der Inhalt erst beim Aufruf. Und ein Skill, den das Modell von sich aus gar nicht aufrufen darf, steht nicht einmal im Verzeichnis und kostet bis zum Aufruf nichts.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Daraus folgt die Kostenregel dieses Kapitels: Ein Ort ist umso teurer, je weiter oben in dieser Liste er steht. Eine Regel in der Projektanweisung zahlt sich bei jedem Schritt, eine Notiz in der Wissensbasis nur, wenn jemand nachsieht.

Zwei Gedächtnisse nebeneinander

Die Projektanweisung und die Selbstnotizen sehen von außen ähnlich aus und haben verschiedene Aufgaben. Der Hersteller stellt sie in einer Tabelle gegenüber, und die vier Zeilen sind es wert, sie zu kennen:

	Projektanweisung	Selbstnotizen
Wer schreibt	Sie	der Agent
Was steht drin	Regeln und Anweisungen	Beobachtungen und Muster
Reichweite	Projekt, Benutzer, Organisation	je Repository, geteilt über Worktrees
Wofür	Konventionen, Abläufe, Aufbau	Baubefehle, Fundstücke, Vorlieben

Die dritte Zeile ist die, die im Alltag überrascht. Die Selbstnotizen liegen außerhalb des Projekts, in einem eigenen Verzeichnis pro Repository, und sie werden nicht mit anderen geteilt. Sie gehen also nicht in die Versionsverwaltung und stehen auf einem zweiten Rechner nicht zur Verfügung.

Das ist eine Entscheidung mit Absicht. Was ein Agent sich selbst notiert, ist seine Beobachtung, nicht die Vereinbarung mit dem Team.

Der Index und die Themendateien

Die Selbstnotizen sind zweistufig aufgebaut, und wer das nicht weiß, wundert sich über den Umfang.

Es gibt eine Indexdatei, die bei jedem Start geladen wird, und daneben Themendateien, die es nicht werden. Der Index ist ein Inhaltsverzeichnis: eine Zeile je Sache, ein Verweis auf die Datei mit den Einzelheiten. Die Details holt sich der Agent, wenn er sie braucht.

Für den Index gilt eine harte Grenze: die ersten 200 Zeilen oder 25 Kilobyte, je nachdem, was zuerst erreicht ist. Was darüber steht, wird beim Start nicht geladen.

Diese Grenze ist bemerkenswert, weil sie leise ist. Eine zu lange Indexdatei erzeugt keinen Fehler, sie wird abgeschnitten, und der abgeschnittene Teil verhält sich genau wie eine Notiz, die nie geschrieben wurde. Neuere Fassungen weisen beim Schreiben darauf hin.

Wann Verdichten nötig wird

Verdichtet wird automatisch, kurz bevor das Fenster an seine Grenze stößt. Diese Grenze ist nicht bei jedem Modell gleich hoch, sie reicht von 200.000 bis zu einer Million Token, je nach Modell und Plan (externe Seite, code.claude.com). Ein größeres Fenster verschiebt den automatischen Zeitpunkt nach hinten, es hebt ihn nicht auf.

Verlässlich ist das Fenster ohnehin nur bis zu einem Punkt vor dieser Grenze. Ein Modell berücksichtigt die Mitte eines langen Kontexts schlechter als Anfang und Ende, ausführlich in Grundkurs, Kapitel 05. Eine Vereinbarung aus der Mitte einer langen Sitzung kann deshalb schon nicht mehr zuverlässig befolgt werden, während die Füllstandsanzeige des Fensters noch die Hälfte frei zeigt.

Was das Verdichten überlebt, vollständig

Ebene 1 hat die Kurzfassung gebracht. Hier die ganze Tabelle, weil zwei Zeilen darin regelmäßig für Verwirrung sorgen:

Was	Nach dem Verdichten
Systemanweisung	unverändert, sie war nie Teil des Verlaufs
Projektanweisung im Projektstamm	wird neu von der Platte gelesen
Selbstnotizen	werden neu von der Platte gelesen
Regeln mit Pfadbindung	fallen heraus, bis wieder eine passende Datei gelesen wird
Projektanweisungen in Unterverzeichnissen	dasselbe
Aufgerufene Skills	kommen zurück, gedeckelt, älteste fallen zuerst
Hooks	betrifft sie nicht, sie laufen als Programm

Die vierte und fünfte Zeile sind die Falle. Eine pfadgebundene Regel ist genau deshalb attraktiv, weil sie den Kontext schont, und genau deshalb ist sie nach dem Verdichten weg:

Path-scoped rules and nested CLAUDE.md files load into message history when their trigger file is read, so compaction summarizes them away with everything else. (externe Seite, code.claude.com)

Praktisch heißt das: Eine Regel, die unbedingt gelten muss, gehört in die Stammdatei, auch wenn sie dort teurer ist. Eine Regel, die nur beim Anfassen bestimmter Dateien zählt, ist pfadgebunden richtig aufgehoben, weil sie mit der Datei wiederkommt.

Die letzte Zeile ist die wichtigste

Hooks stehen in der Tabelle mit dem Vermerk, dass die Frage sie nicht betrifft. Das ist der Grund, warum sie in diesem Kurs ein eigenes Kapitel bekommen: Sie sind der einzige Eintrag, der von der Länge des Gesprächs unabhängig ist, weil sie kein Kontext sind.

Alles andere in dieser Tabelle ist Text, der gelesen wird oder eben nicht.

Woran man merkt, dass etwas fehlt

Ein Verdacht, der sich prüfen lässt: Wenn ein Agent mitten in einer langen Sitzung anfängt, etwas anders zu machen als vorher, war meistens eine Verdichtung dazwischen.

Die Prüfung dauert eine halbe Minute. Die Werkzeuge haben einen Befehl, der auflistet, welche Projektanweisungen geladen sind, und einen zweiten, der die Belegung des Fensters aufschlüsselt. Steht dort, was Sie erwarten, liegt es an der Formulierung. Steht es nicht dort, liegt es am Ort.

Wenn man länger mit Agenten arbeitet, kommt irgendwann diese Frage: Was von dem, was gerade im Kopf des Systems ist, kann ich für die nächste Sitzung retten, und wie?

Die Antwort besteht aus drei Hebeln. Zwei davon kennt jeder, der dritte ist der interessante.

Hebel eins: die Zusammenfassung lenken

Der billigste Eingriff. Beim Verdichten lässt sich mitgeben, worauf zu achten ist, und der Unterschied ist genau der zwischen Auswahl und Vermutung:

The summary keeps what you choose instead of what the automatic pass guesses is important. (externe Seite, code.claude.com)

Der Haken: Es wirkt nur für diese eine Verdichtung. Beim nächsten Mal fängt die Frage von vorn an, und wenn das Verdichten automatisch ausgelöst wird, kommen Sie gar nicht dazu.

Hebel zwei: auf die Platte schreiben

Der einzige Hebel, der ohne Wiederholung auskommt. Was in der Projektanweisung steht, wird nach jedem Verdichten neu gelesen und steht wortgleich wieder da. Dasselbe gilt für die Selbstnotizen des Werkzeugs.

Praktisch ist damit alles gelöst, was dauerhaft gilt. Ungelöst bleibt der Zwischenfall: der Arbeitsstand einer laufenden Sitzung, die halbfertige Entscheidung, die drei Sackgassen, in die man heute schon gelaufen ist. Das gehört nicht in die Projektanweisung, weil es morgen nicht mehr stimmt.

Hebel drei: eine Übergabe, die wieder eingelesen wird

Hier wird es interessant, und hier setzen die meisten an der falschen Stelle an.

Der naheliegende Gedanke lautet: Es gibt ein Ereignis „vor dem Verdichten“, also hängt man dort ein Programm ein, das eine Übergabe schreibt und wieder einspeist. Die erste Hälfte davon geht. Die zweite nicht.

Die Dokumentation ordnet dem Ereignis vor dem Verdichten Seiteneffekte wie Protokollieren und Aufräumen zu und ausdrücklich keine Einspeisung. Was ein solches Programm auf die Ausgabe schreibt, landet nicht im Kontext danach. Wer das annimmt, baut eine Übergabe, die nie ankommt, und merkt es nicht, weil alles fehlerfrei durchläuft.

Einspeisen kann ein anderes Ereignis: der Sitzungsstart. Es kennt vier Auslöser, und einer davon ist ausdrücklich der Start nach einer Verdichtung. Ein Programm, das dort hängt, darf Text zurückgeben, der in den Kontext übernommen wird.

Die Übergabe läuft damit über zwei Stellen:

1. Schreiben, bevor verdichtet wird. Das kann ein Programm tun, das an das Ereignis vor dem Verdichten gehängt ist, oder schlicht der Agent selbst, wenn Sie ihn darum bitten.
2. Einlesen, nachdem verdichtet wurde, über das Ereignis am Sitzungsstart.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Was in eine Übergabe gehört

Eine Übergabedatei ist etwas anderes als eine Projektanweisung, und sie wird schlecht, wenn man sie wie eine behandelt. Brauchbar sind vier Dinge:

Woran gerade gearbeitet wird, in einem Satz, mit dem Ziel dahinter.

Was schon entschieden ist, damit es nicht neu verhandelt wird. Das ist der Teil, den eine automatische Zusammenfassung am häufigsten verliert, weil eine Entscheidung im Verlauf oft nur ein Halbsatz war.

Was nicht funktioniert hat, mit Grund. Ohne diesen Teil läuft die nächste Sitzung in dieselbe Sackgasse, und zwar zuverlässig.

Der nächste Schritt, ausdrücklich benannt.

Was nicht hineingehört: eine Zusammenfassung des Codes. Der steht auf der Platte und lässt sich lesen.

Verdichten und neu anfangen sind zwei Dinge

Ein Unterschied, an dem sich Erwartungen regelmäßig brechen.

Beim Verdichten bleibt eine Zusammenfassung. Der Verlauf ist ersetzt, das Werkzeug hat aber noch eine Vorstellung davon, worum es ging, und die Projektanweisungen kommen von der Platte zurück.

Bei einer neuen Sitzung ist der Verlauf vollständig weg. Zurück bleibt ausschließlich, was auf der Platte steht.

Das klingt nach einer Feinheit und ändert die Praxis. Wer weiß, dass er morgen neu anfängt, muss vorher schreiben. Wer nur verdichtet, kann sich auf die Zusammenfassung stützen, sollte ihr aber nichts anvertrauen, das teuer war.

Ein Gedächtnis kann falsch sein

Und jetzt die Eigenschaft, die alle fünf Orte teilen und die keine Technik löst: Was einmal geschrieben wurde, bleibt stehen, auch wenn es nicht mehr stimmt.

Eine Notiz aus dem Mai, die auf eine Datei zeigt, die es seit Juni nicht mehr gibt, ist schlimmer als keine Notiz. Sie sieht aus wie Wissen, sie wird beim Start geladen, und sie ist überzeugend geschrieben, weil eine Maschine sie geschrieben hat.

Daraus folgen zwei Gewohnheiten, die sich bewährt haben:

Eine Notiz, die eine Datei, eine Funktion oder eine Einstellung nennt, wird geprüft, bevor man ihr folgt. Das gilt besonders für die Selbstnotizen, weil niemand sie durchsieht. Sie stehen als gewöhnliches Markdown auf der Platte und lassen sich lesen, ändern und löschen.

Widersprüche werden nicht gemeldet. Wenn eine alte Notiz einer neuen Regel widerspricht, entscheidet der Zufall. Das ist derselbe Befund wie bei den gestapelten Projektanweisungen in Kapitel 03, nur mit dem Zusatz, dass Sie die eine Hälfte nicht selbst geschrieben haben.

Der Aufräumtakt

Ein Gedächtnis, das nur wächst, wird unbrauchbar. Für die Indexdatei erzwingt die Grenze aus Ebene 2 das Aufräumen; für alles andere braucht es einen Anlass.

Ein brauchbarer: Immer wenn eine Notiz beim Arbeiten auffällt und nicht mehr stimmt, wird sie in derselben Minute korrigiert oder gelöscht. Das ist derselbe Grundsatz, der eine gute Projektanweisung kürzer werden lässt, und er hat denselben Grund. Zwei widersprüchliche Einträge sind schlechter als einer, der fehlt.