KI-Agent-Gedächtnisverlust: Warum Multi-Turn-LLMs kollabieren

Neunzig Minuten nach Beginn meines Deliberation-Systems hörte der Agent auf, Architekturentscheidungen zu referenzieren, die er dreißig Minuten zuvor besprochen hatte. Die Sitzungsprotokolle zeigten, dass Claude den Modul-Abhängigkeitsgraphen komprimiert hatte, um Platz für neue Tool-Ausgaben zu schaffen. Der Agent schrieb weiter Code — doch dieser Code spiegelte nicht mehr die modulübergreifenden Verträge wider, die er in der ersten Stunde etabliert hatte. Tests bestanden. Die Integration schlug fehl. Der Agent hatte sein eigenes Design vergessen.

Dieser Fehler kostete mich einen vollen Tag Debugging. Die aktuelle Forschung erklärt jetzt, warum das passierte.

TL;DR

Microsoft Research und Salesforce testeten 15 LLMs in über 200.000 simulierten Gesprächen und stellten einen durchschnittlichen Leistungsabfall von 39 % zwischen Single-Turn- und Multi-Turn-Interaktion fest.¹ Die Degradation beginnt bereits nach zwei Turns. Drei unabhängige Mechanismen treiben den Kollaps: Kontextkompression verwirft kritische Zustände, die Kohärenz des Schlussfolgerns fragmentiert bei schrumpfendem Token-Budget, und die Koordination zwischen Agenten bricht ohne gemeinsame Wahrheitsquelle zusammen. Längere Kontextfenster beheben keinen dieser Mechanismen. Das Ralph-Loop-Muster (frischer Kontext pro Iteration mit Dateisystem-Zustand) umgeht den Kompressionsverlust, bringt jedoch eigene Kosten mit sich. Im Folgenden: die Forschung, die drei Mechanismen, sofort anwendbare Erkennungsmethoden und ein Protokoll für Multi-Turn-Resilienz.

Die 90-Minuten-Klippe

Mein Context-is-Architecture-Beitrag dokumentierte ein siebenschichtiges Kontextsystem über 650 Dateien. Der Aufbau dieses Systems erforderte ausgedehnte Coding-Sitzungen, in denen der Agent komplexen Architekturzustand halten musste: Modulgrenzen, Abhängigkeitsketten, Hook-Ausführungsreihenfolge und dateiübergreifende Verträge.

Über 30 Ralph-Loop-Iterationen im Januar und Februar 2026 habe ich die Sitzungsqualität gemessen. Die Daten zeigten ein konsistentes 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, Test-Suite-Aufbauten und Dokumentationsdurchgänge degradierten auf derselben Kurve. Was variierte, war die Schwere: Aufgaben mit mehr dateiübergreifendem Zustand erreichten die Klippe früher als isolierte Einzeldatei-Arbeit.

Ich führte das Muster auf Kontextfensterdruck zurück und baute den Ralph-Loop als Gegenmaßnahme. Eine frische Claude-Instanz pro Iteration erzeugen; den Zustand aus dem Dateisystem injizieren; sich nie über eine einzelne Iteration hinaus auf konversationelles Gedächtnis verlassen. Das Muster funktioniert. Allerdings zeigte die im Mai 2025 veröffentlichte MSR/Salesforce-Studie, dass das Problem struktureller ist als die bloße Kontextfenstergröße.

Drei Mechanismen des Multi-Turn-Kollapses

Laban et al. zerlegten die Multi-Turn-Degradation in unabhängige Mechanismen — und diese Unterscheidung ist entscheidend, weil jeder eine strukturell andere Intervention erfordert.¹

Mechanismus 1: Kontextkompression

Jedes KI-Gespräch operiert innerhalb eines begrenzten Token-Budgets. Mit wachsendem Gesprächsverlauf komprimiert das System frühere Turns, um Platz für neue Inhalte zu schaffen. Die Kompression ist verlustbehaftet. In Turn 3 dokumentierte Architekturentscheidungen überleben möglicherweise nicht bis Turn 15.

Beim Bau des Deliberation-Systems erlebte ich dies direkt. Der Agent etablierte in den ersten 20 Minuten einen Modul-Abhängigkeitsgraphen: deliberation_engine.py hängt von consensus_calculator.py ab, das wiederum von vote_aggregator.py abhängt. Nach 75 Minuten hatte der Agent die Abhängigkeitskette wegkomprimiert und einen Import-Zyklus geschrieben. Der Code war syntaktisch korrekt. Der zirkuläre Import verursachte einen Laufzeitfehler.

Erkennung: Verfolgen Sie das Verhältnis dateiübergreifender Referenzen in der Agentenausgabe über die Zeit. Wenn der Agent aufhört, zuvor besprochene Dateien zu referenzieren, hat die Kompression wahrscheinlich den relevanten Kontext 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 Schlussfolgerungskohärenz

Die MSR/Salesforce-Studie ergab, dass sich die Multi-Turn-Degradation in zwei Komponenten zerlegen lässt: einen geringfügigen Eignungsverlust und eine signifikante Zunahme der Unzuverlässigkeit.¹ Eignung misst, ob das Modell überhaupt eine korrekte Antwort produzieren kann. Zuverlässigkeit misst, ob es dies konsistent tut.

Im Single-Turn-Modus erreichten Modelle eine durchschnittliche Leistung von etwa 90 % über sechs Generierungsaufgaben. Im Multi-Turn-Modus sank die Leistung auf ungefähr 65 %: ein absoluter Rückgang von 25 Punkten. Die entscheidende Erkenntnis: „Wenn LLMs in einem Multi-Turn-Gespräch einen falschen Weg einschlagen, verlieren sie die Orientierung und erholen sich nicht.”¹

Verlust der Schlussfolgerungskohärenz äußert sich darin, dass der Agent seinen eigenen früheren Entscheidungen widerspricht. Nicht weil das System den Kontext wegkomprimiert hat (Mechanismus 1), sondern weil die Schlussfolgerungskette des Modells über Turns hinweg fragmentierte. Jeder Turn ist lokal schlüssig, aber global inkonsistent.

Du et al. adressieren diesen Mechanismus direkt mit ihrem Ansatz des kognitiven Entscheidungsroutings.² Inspiriert von Kahnemans Dual-Prozess-Theorie (schnelle intuitive Reaktionen vs. langsames bewusstes Schlussfolgern) passt ihr System die Schlussfolgerungstiefe an die Aufgabenanforderungen an. Die Kernidee: Nicht jeder Agent-Turn erfordert dieselbe Schlussfolgerungstiefe — einheitliche Tiefe verschwendet Budget für triviale Schritte und investiert zu wenig in kritische Entscheidungen.

Erkennung: Achten Sie auf Widersprüche zwischen früher und später Sitzungsausgabe. Befürwortet der Agent Ansatz A in Minute 15 und Ansatz B in Minute 60, ohne die Änderung zu erwähnen, hat sich die Kohärenz verschlechtert.

Mechanismus 3: Koordinationsversagen

Multi-Agent-Systeme verstärken die Multi-Turn-Degradation durch Koordinationsversagen. Wenn zwei oder mehr Agenten an einer Aufgabe zusammenarbeiten, degradiert der Kontext jedes Agenten unabhängig. Ein Agent, der eine gemeinsame Einschränkung vergessen hat, kann sich nicht daran koordinieren.

Bhardwaj et al. adressieren dies mit Agent Context Protocols, die strukturierte Kommunikationskanäle zwischen Agenten etablieren.³ Ihr Framework erreichte 28,3 % Genauigkeit auf AssistantBench durch die Definition expliziter Protokolle für Kontextaustausch, Fehlerpropagation und Zustandssynchronisation. Krishnans Unified Agent Communication Protocol erweitert dies um Zero-Trust-Sicherheitsgrenzen zwischen Agenten.⁴

Koordinationsversagen erlebte ich während einer 10-Agenten-Deliberation, bei der drei Reviewer dieselbe Code-Änderung evaluierten. In der vierten Review-Runde hatten die Agenten divergierende Vorstellungen davon, wie die „aktuelle Version” des Codes aussah. Jeder Agent hielt einen anderen Snapshot in seinem Kontext. Ihre Reviews widersprachen einander — nicht weil sie unterschiedlicher Meinung waren, sondern weil sie unterschiedlichen Code reviewten.

Erkennung: Vergleichen Sie in Multi-Agent-Workflows die Zustandsannahmen der einzelnen Agenten. Referenzieren Agenten unterschiedliche Versionen desselben Artefakts, ist die Koordination gescheitert.

Warum längere Kontextfenster das Problem nicht lösen

Die intuitive Reaktion auf Multi-Turn-Degradation lautet: „Gib dem Modell mehr Tokens.” Die MSR/Salesforce-Studie widerlegt diese Intuition mit einem eleganten experimentellen Design.

Sie testeten eine „Concat”-Bedingung: Das gesamte Multi-Turn-Gespräch wurde als einzelner verketteter Prompt präsentiert. Die Concat-Bedingung erreichte 95,1 % der Single-Turn-Leistung.¹ Die Kontextlänge war identisch mit der Multi-Turn-Bedingung. Der Informationsgehalt war identisch. Der einzige Unterschied lag in der Interaktionsstruktur: ein Turn statt vieler Turns.

Die 39 %-Degradation ist kein Kontextlängenproblem. Eine Verdopplung des Kontextfensters von 200K auf 400K Tokens würde die Degradation nicht beseitigen, weil sie von den Turn-Grenzen selbst herrührt — nicht von fehlendem Platz.

Die Concat-Erkenntnis deckt sich mit meinen Produktionsdaten. Claude arbeitet mit etwa 200.000 Tokens Kontext. Meine Messungen zum Kontextfenster-Management zeigten, dass die längsten Einzelsitzungen (3+ Stunden, intensive Tool-Nutzung) etwa 180.000 Tokens verbrauchen, bevor die Kompaktierung einsetzt. Dennoch degradiert die Qualität weit vor dem Füllen des Fensters. Die 90-Minuten-Klippe tritt bei etwa 60–70 % Kontextauslastung auf, nicht an der Grenze. Die daraus resultierende kognitive Schuld akkumuliert sich, da der Agent schneller Code produziert, als ein Entwickler ihn verifizieren kann. Es handelt sich um dasselbe Compound-Context-Problem in anderem Maßstab: Jeder Turn fügt Informationen hinzu, die nichtlinear mit dem Vorherigen interagieren.

Du et al. formulieren das Problem mit ihrem kognitiven Entscheidungsrouting neu: Die Frage ist nicht, wie viele Tokens das Modell halten kann, sondern wie effizient es Schlussfolgerungsressourcen über diese Tokens verteilt.² Ihr System erreichte eine 34 %-Reduktion der Rechenkosten bei 23 % Verbesserung der Konsistenz, indem einfache Entscheidungen durch schnelles Schlussfolgern und komplexe Entscheidungen durch bewusstes Schlussfolgern geroutet wurden.

Die Frischkontext-Lösung (und ihre Kosten)

Der Ralph-Loop löst Mechanismus 1 (Kompression) und teilweise Mechanismus 2 (Kohärenz), indem ein Gespräch nie lang genug läuft, damit sich einer der beiden manifestiert. Jede Iteration erzeugt eine frische Claude-Instanz mit vollem 200K-Token-Kontext. Zustand wird über das Dateisystem persistiert, nicht über konversationelles Gedä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 erhält das volle Kontextbudget. Keine Kompressionsartefakte aus vorherigen Turns. Keine Kohärenzfragmente aus früheren Schlussfolgerungsketten. Das Dateisystem dient als externes Gedächtnis des Agenten: jiro.state.json verfolgt die aktuelle Story, jiro.progress.json zeichnet abgeschlossene Arbeit über Iterationen hinweg auf, und git diff liefert die Wahrheitsquelle darüber, was sich tatsächlich geändert hat.

Zhang, Kraska und Khattab verfolgen mit ihren Recursive Language Models einen komplementären Ansatz: Statt frische Instanzen zu erzeugen, lagert das Modell Kontext in eine Python-REPL-Umgebung aus und schlussfolgert über Kontext in Code statt im Token-Raum.⁵ RLM-Qwen3-8B übertraf seine Baseline um 28,3 % bei Long-Context-Aufgaben, indem lange Prompts als externe Datenstrukturen statt als internes Gedächtnis behandelt wurden. Wo der Ralph-Loop Zustand in Dateien externalisiert, externalisieren RLMs Zustand in Code. Beide Muster lösen dasselbe Kompressionsproblem über unterschiedliche Mechanismen.

Nanda et al. adressieren mit ihrem Wink-System, was geschieht, wenn die Degradation bereits begonnen hat.⁶ Bei der Analyse von über 10.000 realen Agent-Trajektorien stellten sie fest, dass Fehlverhalten (Spezifikationsdrift, repetitive Schleifen, Tool-Call-Fehler) in etwa 30 % aller Sitzungen auftritt. Wink beobachtet die Trajektorie des Agenten und bietet gezielte Kurskorrektur — 90 % der Einzelinterventions-Fehlverhalten werden behoben. Die Erkennung erfolgt in Echtzeit: Wink identifiziert Degradationsmuster, sobald sie auftreten, statt auf eine Fehlerfortpflanzung durch die Codebasis zu warten.

Die Kosten

Frischkontext-Iteration ist nicht kostenlos. Drei Kostenfaktoren:

1. Orient-Overhead. Jede Iteration verbraucht Tokens für das erneute Lesen von Zuständen, die die vorherige Iteration bereits verstanden hatte. Meine Messungen zeigen, dass 15–20 % des Token-Budgets jeder Iteration auf den Orient-Schritt entfallen: Zustandsdateien lesen, aktuelle Git-Historie scannen, genug Kontext aufbauen, um fortzufahren. Eine 200K-Token-Iteration startet mit etwa 160.000–170.000 Tokens nutzbarer Kapazität.

2. Verlorenes implizites Wissen. Konversationskontext trägt implizites Wissen, das der Dateisystem-Zustand nicht erfassen kann: die Begründung hinter einer Designentscheidung, die erwogenen und verworfenen Alternativen, die Nuancen, warum Ansatz A gegenüber Ansatz B gewählt wurde. Der Orient-Schritt injiziert Fakten (was sich geändert hat, was als Nächstes kommt). Das Warum verdampft zwischen den Iterationen.

3. Koordinationskosten. Laufen mehrere Ralph-Loops gleichzeitig (parallele Story-Implementierung), pflegt jeder Loop unabhängigen Zustand. Die Koordination zwischen Loops erfordert explizite Merge-Logik und Konfliktlösung, die eine einzelne lange Sitzung implizit handhabt.

Die Kosten-Nutzen-Rechnung ist klar: Für Sitzungen unter 60 Minuten ist ein einzelnes Gespräch effizienter. Jenseits von 90 Minuten produziert das Frischkontext-Muster trotz Orient-Overhead qualitativ hochwertigeren Output. Der Kreuzungspunkt hängt von der Aufgabenkomplexität ab: Hoher dateiübergreifender Zustand verschiebt ihn nach vorne; isolierte Einzeldatei-Arbeit verschiebt ihn nach hinten.

Degradation erkennen, bevor sie zuschlägt

Sie müssen nicht auf einen Produktionsfehler warten, um Multi-Turn-Degradation zu erkennen. Drei Methoden, vom einfachsten zum gründlichsten Ansatz:

Methode 1: Kontextdruck-Monitoring

Verfolgen Sie die Kontextauslastung in Echtzeit. Mein context-pressure.sh-Hook läuft nach jedem Tool-Aufruf und warnt, wenn 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: Querverweis-Tracking

Überwachen Sie, wie viele verschiedene Dateien der Agent pro Ausgabe referenziert. Ein abnehmender Trend signalisiert Kompressionsverlust:

# 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: Widerspruchserkennung

Vergleichen Sie die Architekturaussagen des Agenten über die Zeit hinweg. Behauptet der Agent in Minute 20 „Modul A hängt von Modul B ab” und in Minute 70 „Modul A hat keine externen Abhängigkeiten”, hat sich die Kohärenz verschlechtert. Die automatisierte Variante: Vergleichen Sie die EXPLAIN-Aussagen (oder Design-Kommentare) des Agenten zwischen früher und später Sitzungsausgabe per Diff.

Ein Protokoll für Multi-Turn-Resilienz

Drei Stufen, die jeweils einen anderen Mechanismus adressieren. Beginnen Sie mit Stufe 1 und fügen Sie bei Bedarf weitere Ebenen hinzu.

Stufe 1: Zustandssicherung

Serialisieren Sie alle 30 Minuten das aktuelle Architekturverständnis des Agenten in eine Datei. Nicht das gesamte Gespräch, sondern den strukturellen Zustand: welche Module existieren, wie sie verbunden sind, welche Einschränkungen 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

Wenn das Verhalten des Agenten degradiert, stellen Sie vom Checkpoint wieder her, anstatt mit degradiertem Kontext fortzufahren.

Stufe 2: Frischkontext-Iterationen

Für Sitzungen über 60 Minuten wechseln Sie zum Ralph-Loop-Muster. Entscheidend ist der Orient-Schritt: Genug Zustand injizieren, damit der neue Kontext produktiv fortfahren kann, ohne die gesamte Gesprächshistorie erneut zu lesen.

Erforderlicher Zustand für den Orient-Schritt: 1. Aktuelle Aufgabe und Akzeptanzkriterien 2. In der vorherigen Iteration geänderte Dateien (aus git diff) 3. Architekturentscheidungen und ihre Begründungen 4. Bekannte Einschränkungen und Fehlermodi

Stufe 3: Agent-Koordinationsprotokolle

Für Multi-Agent-Workflows etablieren Sie ein gemeinsames Zustandsdokument, das alle Agenten lesen und beschreiben. Das Dokument dient als Wahrheitsquelle und verhindert die Divergenz, die ich bei den Deliberation-Reviews beobachtete.

{
  "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 seines Turns und aktualisiert es am Ende. Konflikte lösen eine Koordinationspause aus statt stiller Divergenz. Die besten Agenten arbeiten so unsichtbar — wie in The Invisible Agent untersucht, ist das Ziel eine Infrastruktur, die funktioniert, ohne dass der Entwickler sie bemerkt.

Kernerkenntnisse

• Multi-Turn-Degradation ist strukturell, kein Kontextlängenproblem. Die MSR/Salesforce-Studie zeigte 39 % Degradation selbst bei konstanter Kontextlänge. Turn-Grenzen, nicht Token-Limits, treiben den Kollaps.¹
• Drei unabhängige Mechanismen erfordern drei verschiedene Interventionen. Kompressionsverlust benötigt Zustandssicherung. Kohärenzverlust benötigt Frischkontext-Iteration. Koordinationsversagen benötigt gemeinsame Zustandsprotokolle.
• Die 90-Minuten-Klippe ist real und messbar. Verfolgen Sie Kontextauslastung, Querverweis-Diversität und architektonische Widersprüche, um Degradation vor Produktionsfehlern zu erkennen.
• Frischkontext-Iteration funktioniert, kostet aber 15–20 % Overhead. Das Ralph-Loop-Muster tauscht Orient-Overhead gegen volles Kontextbudget pro Iteration. Der Trade-off begünstigt frischen Kontext jenseits von 60–90 Minuten.
• Adaptives Schlussfolgerungsbudget übertrifft einheitliche Tiefe. Du et al. erreichten mit kognitivem Entscheidungsrouting eine 34 %-Kostenreduktion bei 23 % Konsistenzverbesserung, indem die Schlussfolgerungstiefe an die Aufgabenanforderungen angepasst wurde.²

FAQ

Referenzen