Gedächtnisverfall bei KI-Agenten: Warum LLMs im Mehrrunden-Dialog zusammenbrechen

Neunzig Minuten lang hatte ich an meinem Deliberationssystem⁹ gebaut, dann hörte der Agent auf, sich auf Architekturentscheidungen zu beziehen, die er eine halbe Stunde zuvor selbst besprochen hatte. Die Sitzungsprotokolle zeigten: Claude hatte den Abhängigkeitsgraphen der Module wegkomprimiert, um Platz für neue Tool-Ausgaben zu schaffen. Der Agent schrieb weiter Code, doch dieser Code bildete die modulübergreifenden Verträge nicht mehr ab, die er in der ersten Stunde festgelegt hatte. Die Tests liefen durch. Die Integration scheiterte. Der Agent hatte sein eigenes Design vergessen.

Dieser Fehlschlag hat mich einen ganzen Tag Fehlersuche gekostet. Die Forschung erklärt inzwischen, warum er passiert ist.

TL;DR

Microsoft Research und Salesforce haben 15 LLMs in über 200.000 simulierten Gesprächen getestet und dabei einen durchschnittlichen Leistungsabfall von 39 % festgestellt, sobald aus einer einzelnen Anfrage ein Dialog über mehrere Runden wird.¹ Der Verfall setzt bereits nach zwei Runden ein. Drei voneinander unabhängige Mechanismen führen zum Zusammenbruch: Die Kontextkompression verwirft kritischen Zustand, die Kohärenz der Schlussfolgerungen zerfällt, während das Token-Budget schrumpft, und die Koordination zwischen Agenten bricht ohne gemeinsame Faktenbasis zusammen. Größere Kontextfenster beheben nichts davon. Das Muster der Ralph-Schleife – frischer Kontext pro Iteration, Zustand im Dateisystem – umgeht den Kompressionsverlust, bringt aber eigene Kosten mit. Im Folgenden: die Forschung, die drei Mechanismen, Erkennungsmethoden, die Sie sofort einsetzen können, und ein Vorgehen für Robustheit über viele Runden.

Die 90-Minuten-Klippe

Mein Beitrag über Kontext als Architektur⁸ dokumentierte ein siebenschichtiges Kontextsystem über 650 Dateien. Der Aufbau dieses Systems verlangte lange Programmiersitzungen, in denen der Agent komplexen Architekturzustand halten musste: Modulgrenzen, Abhängigkeitsketten, die Ausführungsreihenfolge der Hooks und dateiübergreifende Verträge.

Im Januar und Februar 2026 habe ich die Sitzungsqualität über 30 Iterationen der Ralph-Schleife gemessen.⁷ Die Daten zeigten ein durchgängiges Muster:

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

Die Qualitätsklippe trat unabhängig vom Aufgabentyp auf. Lange Refactoring-Sitzungen, der Aufbau von Test-Suites und Dokumentationsdurchläufe fielen alle entlang derselben Kurve ab. Unterschiedlich war nur die Schwere: Aufgaben mit viel dateiübergreifendem Zustand traf die Klippe härter als isolierte Arbeit an einer einzelnen Datei.

Ich führte das Muster auf den Druck des Kontextfensters zurück und baute die Ralph-Schleife, um ihn zu umgehen: pro Iteration eine frische Claude-Instanz starten, den Zustand aus dem Dateisystem einspeisen und sich niemals über eine Iteration hinaus auf das Gesprächsgedächtnis verlassen. Das Muster funktioniert. Doch die im Mai 2025 veröffentlichte Studie von MSR und Salesforce zeigte, dass das Problem struktureller ist, als die Größe des Kontextfensters allein erklären kann.

Drei Mechanismen des Mehrrunden-Zusammenbruchs

Laban et al. haben den Verfall über mehrere Runden in unabhängige Mechanismen zerlegt, und diese Unterscheidung ist wichtig, weil jeder Mechanismus einen strukturell anderen Eingriff verlangt.¹

Mechanismus 1: Kontextkompression

Jedes Gespräch mit einer KI läuft innerhalb eines endlichen Token-Budgets. Wächst das Gespräch, komprimiert das System frühere Runden, um Platz für Neues zu schaffen. Diese Kompression ist verlustbehaftet. Architekturentscheidungen, die in Runde 3 festgehalten wurden, überleben womöglich nicht bis Runde 15.

Beim Bau des Deliberationssystems habe ich das direkt beobachtet. In den ersten 20 Minuten legte der Agent einen Abhängigkeitsgraphen der Module fest: deliberation_engine.py hängt von consensus_calculator.py ab, das wiederum von vote_aggregator.py. Bis Minute 75 hatte er die Abhängigkeitskette wegkomprimiert und einen Importzyklus geschrieben. Syntaktisch war der Code gültig. Der zirkuläre Import führte zur Laufzeit zum Absturz.

Erkennung: Verfolgen Sie über die Zeit, wie hoch der Anteil dateiübergreifender Verweise in den Ausgaben des Agenten ist. Sobald er Dateien nicht mehr erwähnt, über die er zuvor gesprochen hat, hat die Kompression den zugehörigen Kontext vermutlich verworfen.

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

Mechanismus 2: Verlust der Kohärenz beim Schlussfolgern

Die Studie von MSR und Salesforce zeigte, dass sich der Verfall über mehrere Runden in zwei Bestandteile zerlegen lässt: einen geringen Verlust an Leistungsfähigkeit und eine erheblich gestiegene Unzuverlässigkeit.¹ Die Leistungsfähigkeit misst, ob das Modell überhaupt eine korrekte Antwort hervorbringen kann. Die Zuverlässigkeit misst, ob es das durchgängig tut.

Bei einer einzelnen Anfrage erreichten die Modelle über sechs Generierungsaufgaben hinweg im Schnitt rund 90 % Leistung. Im Mehrrunden-Dialog fiel der Wert auf etwa 65 % – ein absoluter Rückgang um 25 Punkte. Der entscheidende Befund: „Wenn LLMs im Mehrrunden-Dialog einmal falsch abbiegen, verlieren sie den Faden und finden ihn nicht wieder.”¹

Der Kohärenzverlust zeigt sich darin, dass der Agent seinen eigenen früheren Entscheidungen widerspricht. Nicht weil das System den Kontext wegkomprimiert hätte (Mechanismus 1), sondern weil die Schlusskette des Modells über die Runden hinweg zerfallen ist. Jede einzelne Runde argumentiert lokal schlüssig, im Ganzen aber widersprüchlich.

Die Arbeit von Du et al. zum kognitiven Entscheidungs-Routing setzt genau hier an.² Inspiriert von Kahnemans Zwei-System-Theorie – schnelle intuitive Antworten gegenüber langsamem, bewusstem Denken – passt ihr System die Denktiefe an die Anforderungen der Aufgabe an. Die Einsicht dahinter: Nicht jede Runde eines Agenten braucht dieselbe Tiefe, und eine einheitliche Tiefe verschwendet Budget an trivialen Schritten, während sie bei kritischen Entscheidungen zu wenig investiert.

Erkennung: Suchen Sie nach Widersprüchen zwischen frühen und späten Ausgaben einer Sitzung. Wirbt der Agent in Minute 15 für Ansatz A und in Minute 60 für Ansatz B, ohne den Wechsel zu benennen, hat die Kohärenz gelitten.

Mechanismus 3: Koordinationsversagen

In Multi-Agenten-Systemen kommt zum Verfall über die Runden noch das Koordinationsversagen hinzu. Arbeiten zwei oder mehr Agenten an derselben Aufgabe, verfällt der Kontext jedes Agenten für sich. Ein Agent, der eine gemeinsame Randbedingung vergessen hat, kann sich auch nicht mehr an ihr ausrichten.

Die Agent Context Protocols von Bhardwaj et al. begegnen dem mit strukturierten Kommunikationskanälen zwischen den Agenten.³ Ihr Framework erreichte 28,3 % Genauigkeit auf AssistantBench, indem es explizite Protokolle für den Kontextaustausch, die Fehlerweitergabe und den Zustandsabgleich festlegt. Krishnans Unified Agent Communication Protocol erweitert das um Zero-Trust-Sicherheitsgrenzen zwischen den Agenten.⁴

Erlebt habe ich Koordinationsversagen bei einer Deliberation mit zehn Agenten, in der drei Reviewer dieselbe Codeänderung bewerteten. Ab der vierten Review-Runde gingen die Vorstellungen der Agenten darüber auseinander, wie die „aktuelle Fassung” des Codes überhaupt aussah. Jeder Agent hielt einen anderen Schnappschuss in seinem Kontext. Ihre Reviews widersprachen einander nicht deshalb, weil sie unterschiedlicher Meinung waren, sondern weil sie unterschiedlichen Code begutachtet hatten.

Erkennung: Vergleichen Sie in Arbeitsabläufen mit mehreren Agenten, welche Annahmen über den Zustand jeder Agent trifft. Verweisen sie auf unterschiedliche Fassungen desselben Artefakts, ist die Koordination gescheitert.

Warum größere Kontextfenster das Problem nicht lösen

Die naheliegende Antwort auf den Verfall über mehrere Runden lautet: „Das Modell braucht einfach mehr Token.” Die Studie von MSR und Salesforce widerlegt diese Intuition mit einem klugen Versuchsaufbau.

Getestet wurde eine „Concat”-Bedingung: Das vollständige Mehrrunden-Gespräch wurde als ein einziger, aneinandergehängter Prompt vorgelegt. In dieser Bedingung erreichten die Modelle 95,1 % der Leistung aus dem Einrunden-Fall.¹ Die Kontextlänge war identisch, der Informationsgehalt ebenfalls. Der einzige Unterschied lag in der Struktur der Interaktion – eine Runde statt vieler.

Der Verfall um 39 % ist kein Problem der Kontextlänge. Eine Verdoppelung des Kontextfensters von 200.000 auf 400.000 Token würde daran nichts ändern, denn der Verfall entsteht an den Rundengrenzen selbst und nicht daran, dass der Platz ausgeht.

Der Concat-Befund deckt sich mit meinen Produktionsdaten. Claude arbeitet mit rund 200.000 Token Kontext. Meine Messungen zum Umgang mit dem Kontextfenster zeigten, dass die längsten Einzelsitzungen – über drei Stunden, mit intensivem Tool-Einsatz – etwa 180.000 Token verbrauchen, bevor die Verdichtung greift. Die Qualität bricht aber lange vor dem Volllaufen des Fensters ein. Die 90-Minuten-Klippe liegt bei rund 60 bis 70 % Kontextauslastung, nicht an der Obergrenze. Die daraus entstehenden kognitiven Schulden häufen sich weiter an, weil der Agent schneller Code produziert, als ein Entwickler ihn prüfen kann. Es ist dasselbe Problem des zusammengesetzten Kontexts in anderem Maßstab: Jede Runde fügt Information hinzu, die nichtlinear mit allem Bisherigen zusammenwirkt.

Du et al. rahmen das Problem mit ihrem kognitiven Entscheidungs-Routing neu: Es geht nicht darum, wie viele Token ein Modell halten kann, sondern wie effizient es seine Denkressourcen über diese Token verteilt.² Indem sie einfache Entscheidungen über schnelles und komplexe über bewusstes Denken leiteten, senkten sie die Rechenkosten um 34 % und verbesserten die Konsistenz um 23 %.

Die Lösung mit frischem Kontext – und ihr Preis

Die Ralph-Schleife löst Mechanismus 1 (Kompression) und teilweise Mechanismus 2 (Kohärenz), indem sie ein Gespräch nie lange genug laufen lässt, dass eines von beiden auftreten kann. Jede Iteration startet eine frische Claude-Instanz mit vollem Kontext von 200.000 Token. Der Zustand bleibt im Dateisystem erhalten, nicht im Gesprächsgedächtnis.

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

Jede Iteration bekommt das volle Kontextbudget. Keine Kompressionsartefakte aus früheren Runden, keine Bruchstücke aus älteren Schlussketten. Das Dateisystem dient dem Agenten als externes Gedächtnis: jiro.state.json hält die aktuelle Story fest, jiro.progress.json verzeichnet die über die Iterationen hinweg erledigte Arbeit, und git diff liefert die Faktenbasis dafür, was sich tatsächlich geändert hat.

Die Recursive Language Models von Zhang, Kraska und Khattab gehen einen ergänzenden Weg: Statt frische Instanzen zu starten, lagert das Modell den Kontext in eine Python-REPL-Umgebung aus und denkt über den Kontext in Code statt im Tokenraum nach.⁵ RLM-Qwen3-8B übertraf seine Referenz bei Aufgaben mit langem Kontext um 28,3 %, indem es lange Prompts als externe Datenstrukturen behandelte statt als internes Gedächtnis. Wo die Ralph-Schleife den Zustand in Dateien auslagert, lagern RLMs ihn in Code aus. Beide Muster lösen dasselbe Kompressionsproblem über unterschiedliche Mechanismen.

Das System Wink von Nanda et al. setzt dort an, wo der Verfall bereits im Gange ist.⁶ Bei der Auswertung von über 10.000 realen Agentenverläufen zeigte sich, dass Fehlverhalten – Abweichen von der Spezifikation, sich wiederholende Schleifen, fehlgeschlagene Tool-Aufrufe – in rund 30 % aller Sitzungen auftritt. Wink beobachtet den Verlauf des Agenten und steuert gezielt gegen; 90 % der Fälle, die sich mit einem einzigen Eingriff beheben lassen, bekommt es so in den Griff. Die Erkennung läuft in Echtzeit: Wink erkennt Verfallsmuster im Entstehen, statt zu warten, bis sich ein Fehler durch die Codebasis zieht.

Der Preis

Iterationen mit frischem Kontext gibt es nicht umsonst. Drei Kostenpunkte:

1. Aufwand für die Orientierung. Jede Iteration verbraucht Token dafür, Zustand erneut zu lesen, den die vorige bereits verstanden hatte. Meine Messungen zeigen: 15 bis 20 % des Token-Budgets einer Iteration gehen an den Orientierungsschritt – Zustandsdateien lesen, die jüngste Git-Historie durchsehen, so viel Kontext wiederherstellen, dass die Arbeit weitergehen kann. Eine Iteration mit 200.000 Token startet damit effektiv mit etwa 160.000 bis 170.000 Token nutzbarer Kapazität.

2. Verlorenes implizites Wissen. Der Gesprächskontext trägt implizites Wissen mit, das der Zustand im Dateisystem nicht einfangen kann: die Begründung hinter einer Designentscheidung, die erwogenen und verworfenen Alternativen, die Feinheit, warum Ansatz A gegenüber Ansatz B den Vorzug bekam. Der Orientierungsschritt liefert Fakten – was sich geändert hat, was als Nächstes ansteht. Die Begründung, das Warum, verdunstet zwischen den Iterationen.

3. Koordinationskosten. Laufen mehrere Ralph-Schleifen gleichzeitig, etwa um Stories parallel umzusetzen, hält jede Schleife ihren eigenen Zustand. Die Abstimmung zwischen ihnen verlangt explizite Zusammenführungslogik und Konfliktauflösung – etwas, das eine einzelne lange Sitzung implizit erledigt.

Die Rechnung fällt eindeutig aus: Unter 60 Minuten ist ein einzelnes Gespräch effizienter. Jenseits von 90 Minuten liefert das Muster mit frischem Kontext trotz des Orientierungsaufwands die bessere Qualität. Wo genau der Umschlagpunkt liegt, hängt von der Komplexität der Aufgabe ab: Viel dateiübergreifender Zustand zieht ihn nach vorn, isolierte Arbeit an einer einzelnen Datei schiebt ihn nach hinten.

Verfall messen, bevor er zuschlägt

Sie müssen nicht auf einen Produktionsausfall warten, um den Verfall über mehrere Runden zu erkennen. Drei Methoden, von der einfachsten bis zur gründlichsten:

Methode 1: Kontextdruck überwachen

Verfolgen Sie die Auslastung des Kontexts in Echtzeit. Mein Hook context-pressure.sh läuft nach jedem Tool-Aufruf und warnt, sobald die Auslastung 60 % übersteigt:

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

Methode 2: Querverweise verfolgen

Beobachten Sie, auf wie viele verschiedene Dateien sich der Agent je Ausgabe bezieht. Ein sinkender Trend deutet auf Kompressionsverlust hin:

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

Methode 3: Widersprüche aufspüren

Vergleichen Sie die Architekturaussagen des Agenten über die Zeit. Behauptet er in Minute 20 „Modul A hängt von Modul B ab” und in Minute 70 „Modul A hat keine externen Abhängigkeiten”, hat die Kohärenz gelitten. Automatisiert geht das so: die EXPLAIN-Aussagen des Agenten (oder seine Designkommentare) aus frühen und späten Ausgaben einer Sitzung per Diff gegenüberstellen.

Ein Vorgehen für Robustheit über viele Runden

Drei Stufen, jede gegen einen anderen Mechanismus. Beginnen Sie mit Stufe 1 und ergänzen Sie die weiteren nach Bedarf.

Stufe 1: Zustand sichern

Schreiben Sie alle 30 Minuten das aktuelle Architekturverständnis des Agenten in eine Datei. Nicht das ganze Gespräch, sondern den strukturellen Zustand: welche Module existieren, wie sie zusammenhängen, welche Randbedingungen gelten.

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

Verschlechtert sich das Verhalten des Agenten, setzen Sie auf dem Sicherungspunkt neu auf, statt mit verschlechtertem Kontext weiterzumachen.

Stufe 2: Iterationen mit frischem Kontext

Bei Sitzungen jenseits von 60 Minuten wechseln Sie auf das Muster der Ralph-Schleife. Entscheidend ist der Orientierungsschritt: gerade so viel Zustand einspeisen, dass der neue Kontext produktiv weiterarbeiten kann, ohne den gesamten Gesprächsverlauf noch einmal zu lesen.

Erforderlicher Zustand für den Orientierungsschritt: 1. Aktuelle Aufgabe und Abnahmekriterien 2. In der vorigen Iteration geänderte Dateien (aus git diff) 3. Architekturentscheidungen und ihre Begründung 4. Bekannte Randbedingungen und Fehlerbilder

Stufe 3: Protokolle für die Agentenkoordination

Richten Sie für Arbeitsabläufe mit mehreren Agenten ein gemeinsames Zustandsdokument ein, das alle lesen und schreiben. Es dient als Faktenbasis und verhindert das Auseinanderdriften, das ich bei den Deliberations-Reviews beobachtet habe.

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

Jeder Agent liest dieses Dokument zu Beginn seiner Runde und schreibt es am Ende fort. Konflikte lösen eine Koordinationspause aus, statt in stilles Auseinanderdriften zu münden. Die besten Agenten arbeiten dabei unsichtbar – wie in Der unsichtbare Agent beschrieben, ist das Ziel eine Infrastruktur, die funktioniert, ohne dass die Entwickler sie überhaupt bemerken.

Das Wichtigste in Kürze

• Der Verfall über mehrere Runden ist strukturell, kein Problem der Kontextlänge. Die Studie von MSR und Salesforce zeigte 39 % Verfall selbst bei gleichbleibender Kontextlänge. Ausgelöst wird der Zusammenbruch von den Rundengrenzen, nicht von der Token-Obergrenze.¹
• Drei unabhängige Mechanismen verlangen drei verschiedene Eingriffe. Gegen Kompressionsverlust hilft das Sichern des Zustands, gegen Kohärenzverlust der frische Kontext je Iteration, gegen Koordinationsversagen ein Protokoll für gemeinsamen Zustand.
• Die 90-Minuten-Klippe ist real und messbar. Verfolgen Sie Kontextauslastung, die Vielfalt der Querverweise und Widersprüche in der Architektur, um den Verfall zu erkennen, bevor er als Produktionsausfall sichtbar wird.
• Frischer Kontext je Iteration funktioniert, kostet aber 15 bis 20 % Mehraufwand. Das Muster der Ralph-Schleife tauscht Orientierungsaufwand gegen ein volles Kontextbudget pro Durchlauf. Jenseits von 60 bis 90 Minuten geht dieser Tausch auf.
• Denkressourcen adaptiv zu verteilen, schlägt eine einheitliche Tiefe. Das kognitive Entscheidungs-Routing von Du et al. senkte die Kosten um 34 % und steigerte die Konsistenz um 23 %, indem es die Denktiefe an die Anforderungen der Aufgabe anpasste.²

FAQ

Quellen