Context Rot: Wenn lange KI-Chats an Zuverlässigkeit verlieren

Context Rot kann dazu führen, dass ein KI-Agent ungenauer arbeitet, obwohl seine Eingabe noch in das angegebene Kontextfenster passt. In einer Studie mit 18 Sprachmodellen stellte Chroma fest, dass sich die Zuverlässigkeit mit der Eingabelänge veränderte. Für die Praxis heißt das: Die für den nächsten Schritt nötigen Belege müssen erhalten bleiben, während irrelevante Teile des Verlaufs entfernt werden.

Was ist Context Rot bei KI-Modellen?

Context Rot bezeichnet eine abnehmende Zuverlässigkeit, wenn die einem Sprachmodell übergebene Informationsmenge wächst. Das Modell übersieht dann etwa Fakten, stellt falsche Zusammenhänge her oder liefert Antworten, die eine bereits getroffene Entscheidung nicht mehr berücksichtigen. Ein langer Gesprächsverlauf kann also weiterhin als Eingabe akzeptiert werden, während es dem Modell zunehmend schwerfällt, ihn korrekt zu nutzen.

Das Kontextfenster ist der Arbeitsbereich, der dem Modell für eine Anfrage zur Verfügung steht. Darin können Anweisungen, der Gesprächsverlauf, Dokumente und Tool-Ergebnisse liegen. Ein Token ist eine Inhaltseinheit, die das Modell verarbeitet, häufig ein Wortfragment. Unser Leitfaden zum Kontextfenster erklärt, was diesen Platz belegt.

Man kann sich das wie die Wand in einem Einsatzraum vorstellen: Neben dem aktuellen Plan hängen dort verworfene Hypothesen, überholte Zeitpläne und alte Protokolle. Eine größere Wand bietet Platz für mehr Material. Sie verrät der nächsten Person aber nicht, welche Entscheidung für die Arbeit noch maßgeblich ist.

Diese Unterscheidung ist bei der Fehlersuche an einem Agenten wichtig. Wurde die benötigte Information entfernt, bevor die Anfrage beim Modell ankam, müssen Kürzung oder Informationsabruf geprüft werden. War die Information enthalten, wurde aber übersehen oder falsch verwendet, ist zu untersuchen, wie das Modell den bereitgestellten Kontext verarbeitet hat. Keines dieser Symptome beweist für sich genommen, dass die Länge das Problem war.

Dokumentation geprüft am 24. Oktober 2026: Die folgenden Herstellerempfehlungen wurden mit der aktuellen Dokumentation von Anthropic abgeglichen. Die Workflow-Beispiele sind Entwurfsvorschläge, keine Berichte über Ergebnisse aus dem Produktivbetrieb.

Die Context-Rot-Studie: Was die Ergebnisse zeigen

Chromas am 14. Juli 2025 veröffentlichter Bericht zeigt: Wenn semantische Übereinstimmungen schwerer zu erkennen waren und scheinbar relevante Ablenkungen hinzukamen, wurde der Informationsabruf aus längeren Eingaben unzuverlässiger. Die kontrollierten Aufgaben liefern nützliche Belege, sind aber kein Benchmark für den eigenen Agenten. Originalstudie.

Im bereinigten Konversationsbenchmark LongMemEval verglich Chroma 306 Prompts mit durchschnittlich etwa 113.000 Token mit gezielt zusammengestellten Fassungen von durchschnittlich etwa 300 Token. Die fokussierten Eingaben schnitten bei allen untersuchten Modellen besser ab. Entscheidend ist jedoch: Diese kurzen Eingaben entstanden aus als relevant markierten Passagen und manuellen Anpassungen. Sie waren nicht das Ergebnis eines automatisch evaluierten Abrufsystems. Methoden und Ergebnisse der Studie.

Wie weit reichen Chromas Ergebnisse zu Context Rot?

Der Bericht weist weder den zugrunde liegenden Mechanismus nach noch eine allgemein sichere Tokenanzahl. Außerdem wächst im Experiment mit wiederholtem Text die Ausgabe zusammen mit der Eingabe. Das unterscheidet es von den Abrufaufgaben mit kurzen Antworten. Forschungsgrenzen und Aufgabenbeschreibungen.

Für die Entwicklung ist vor allem relevant, ob das eigene System die nötigen Belege finden und bewahren kann. Ein Diagramm, das sorgfältig ausgewählte Belege mit einem vollständigen Verlauf vergleicht, sagt nichts darüber aus, ob Suchindex, Filter oder Zusammenfassung diese Belege zuverlässig auswählen. Diese Auswahl muss gesondert evaluiert werden.

Warum sich längerer Kontext schwerer nutzen lässt

Relevantes Material muss sich von seiner Umgebung unterscheiden lassen. Ein alter Bereitstellungsplan kann dem aktuellen Plan stärker ähneln als ein themenfremdes Dokument. Das Risiko besteht deshalb nicht nur darin, einen Satz zu übersehen, sondern auch darin, den falschen Satz auf die aktuelle Situation anzuwenden.

Anthropics Leitfaden zum Context Engineering nennt Einschränkungen der Architektur und das Training mit überwiegend kürzeren Sequenzen als Faktoren, die den Umgang mit langem Kontext erschweren. Beschrieben wird ein allmählicher Präzisionsverlust statt einer einzelnen Grenze, an der die Leistungsfähigkeit verschwindet. Diese Erklärungen helfen bei der Einordnung, belegen aber keine vollständige Kausalkette.

Ein Beispiel: Im Verlauf eines Support-Agenten stehen eine erste Diagnose, ein gescheiterter Workaround und eine später bestätigte Lösung. Liefert ein anschließender Tool-Aufruf eine ältere Version der Fehlerbehebungsanleitung, muss der Agent für seine nächste Antwort sowohl die zeitliche Reihenfolge als auch die Verbindlichkeit der Quellen berücksichtigen. Der zusätzliche Text macht die Entscheidung komplizierter, obwohl die Frage des Nutzers gleich geblieben ist.

Diese Einordnung sollte ausdrücklich festgehalten werden: den aktuellen Stand benennen, die frühere Diagnose als verworfen kennzeichnen und die Quelle erhalten, die die akzeptierte Lösung stützt. Das Ziel sind ausreichende Belege mit eindeutigem Status, nicht ein möglichst kurzer Prompt.

Was Entwicklung und Betrieb zuerst prüfen sollten

Dieselbe Entscheidung mit unterschiedlichem Kontext vergleichen, bevor der Fehler dem Modell zugeschrieben wird. Für die Entwicklung bedeutet das, die tatsächlich von der Anwendung zusammengestellte Anfrage aufzuzeichnen. Im sichtbaren Chatverlauf fehlen womöglich Systemanweisungen, abgerufene Inhalte oder Tool-Antworten, die das Modell erhalten hat.

Im Betrieb sollte eine konkret übersehene Anforderung oder eine falsche Aktion benannt werden. „Der Chat wird irgendwie schlechter“ lässt sich schwer untersuchen. „Der Agent hat den Workaround empfohlen, der im Störungsprotokoll bereits verworfen wurde“ liefert dagegen einen Fall, der sich erneut durchspielen lässt.

Für ein gespeichertes Beispiel eignet sich diese Prüffolge:

1. 1

   Die Entscheidungssituation festhalten

   Frage, Modellkonfiguration und gefordertes Ergebnis bleiben unverändert. Die ursprüngliche Eingabe und die maßgeblichen Belege werden gespeichert. Beim erneuten Durchspielen dürfen keine externen Aktionen ausgeführt werden, damit der Vergleich den zugrunde liegenden Fall nicht verändert.

2. 2

   Prüfen, ob die Belege angekommen sind

   Die benötigte Passage in der tatsächlichen Anfrage suchen. Fehlt sie, müssen zuerst Informationsabruf, Kürzung oder das Laden des Arbeitsstands korrigiert werden. Wurde stattdessen eine überholte Quelle geladen, sind Quellenauswahl und Aktualität zu prüfen.

3. 3

   Eine fokussierte Vergleichsfassung erstellen

   Aufgabenanweisungen und sämtliche für die Antwort nötigen Belege beibehalten, aber themenfremden Verlauf und überholte Tool-Ergebnisse entfernen. Die erwartete Antwort darf nicht vorgegeben und die Aufgabe nicht vereinfacht werden. Anschließend anhand repräsentativer Wiederholungen vergleichen, ob die Antworten korrekt sind, Quellen richtig nutzen und Vorgaben einhalten.

4. 4

   Die Korrektur am Fehler ausrichten

   Hilft die fokussierte Eingabe, sollten Auswahl und Anordnung des Kontexts untersucht werden. Scheitern beide Fassungen, sind Aufgabe, Anweisungen, Qualität der Belege und Fähigkeiten des Modells zu prüfen. Beginnen die Fehler erst nach einer Zusammenfassung, muss untersucht werden, was darin verloren gegangen ist.

Dieser Vergleich dient der Diagnose. Er beweist nicht, dass allein die Länge den Fehler verursacht hat, denn mit dem Entfernen von Material verändert sich auch dessen Zusammensetzung. Für eine strengere Prüfung des Längeneffekts müssen die relevanten Belege und ihre Position kontrolliert werden, während themenfremdes Material hinzukommt. Ein einzelner erfolgreicher Wiederholungsversuch erlaubt keine allgemeine Schlussfolgerung.

Teams sollten handeln, wenn ein wachsender Verlauf wiederholt mit vermeidbaren Fehlern einhergeht. Ein kurzer, klar begrenzter Workflow, der seine Korrektheitsprüfungen besteht, kann bei seinem einfacheren Aufbau bleiben. Zusätzliche Orchestrierung ist dann sinnvoll, wenn ein beobachteter Fehler ihr eine konkrete Aufgabe gibt.

Wie lässt sich Context Rot bei einem Agenten verringern?

Die Maßnahme muss zu dem Material passen, das Probleme verursacht. Kontextverdichtung begrenzt den angesammelten Verlauf; gezielter Informationsabruf wählt Belege aus; Subagenten halten Erkundungsarbeit getrennt; eine klare Anordnung verdeutlicht die Aufgabe; knappe Tool-Antworten vermeiden unnötige Eingaben. Diese Maßnahmen ergänzen sich, können aber auf unterschiedliche Weise scheitern.

Den Verlauf verdichten und den Arbeitsstand erhalten

Bei der Kontextverdichtung, auch Compaction genannt, werden ältere Gesprächsinhalte durch eine kürzere Übergabe für die Fortsetzung ersetzt. Anthropics aktuelle Compaction-Dokumentation erklärt, warum ein kleiner aktiver Kontext wichtig ist: „Die Antwortqualität nimmt ab, wenn ein Gespräch länger wird.“ Die API unterstützt sowohl eine von der Anwendung angeforderte Verdichtung als auch eine Verdichtung, die beim Erreichen einer konfigurierten Tokenschwelle ausgelöst wird.

Die Übergabe sollte sich daran orientieren, was der nächste Schritt benötigt. Beim Störungsbeispiel gehören dazu das aktuelle Ziel, die bestätigte Ursache, der verworfene Workaround samt Begründung, verbleibende Unklarheiten, Fundstellen und die nächste Aktion. Wo die Korrektheit davon abhängt, müssen Kennungen oder Textstellen exakt erhalten bleiben.

Eine schwache Übergabe lautet: „Das Problem wurde untersucht, und es gab Fortschritte.“ Eine brauchbare Übergabe lautet: „Der Workaround wurde verworfen, weil er das geforderte Verhalten verletzt; die akzeptierte Lösung steht im Störungsprotokoll; die Überprüfung steht noch aus.“ Die zweite Fassung ermöglicht die Fortsetzung, ohne die gesamte Untersuchung nachzuerzählen.

Die Grenze: Eine Zusammenfassung kann ein Detail verwerfen, das später wichtig wird. Das ursprüngliche Protokoll muss zugänglich bleiben. Außerdem ist zu prüfen, ob der Agent nach der Fortsetzung noch Fragen beantworten kann, für die dieses Detail nötig ist. Einen Arbeitsstand dauerhaft zu speichern und zu entscheiden, was daraus erneut geladen wird, sind getrennte Aufgaben. Darum geht es im Leitfaden zum Agentengedächtnis.

Belege dann abrufen, wenn die Aufgabe sie braucht

Verweise auf umfangreiche Quellen behalten und relevante Abschnitte bei Bedarf laden. Anthropic bezeichnet das als Just-in-time-Kontext: Der Agent kann Dateipfade, Suchanfragen oder Links vorhalten und das zugehörige Material erst dann abrufen, wenn es gebraucht wird. Empfehlungen zum Kontextabruf.

Ein Agent zur Störungsbearbeitung beginnt mit dem aktuellen Störungsprotokoll und der einschlägigen Dienstdokumentation. Einen älteren Vorfall ruft er ab, wenn die Diagnose es erfordert. Jede Passage sollte zusammen mit ihrer Quelle, gegebenenfalls Version oder Datum und genügend umgebendem Text zurückgegeben werden, um eine Ausnahme richtig einordnen zu können.

Die Grenze: Beim Abruf kann die entscheidende Klausel fehlen oder ein plausibler, aber veralteter Treffer erscheinen. Bevor die Antwortqualität gemessen wird, sollte geprüft werden, ob die nötigen Belege überhaupt vorliegen. Der Agent braucht die Möglichkeit, die Suche auszuweiten oder die vollständige Quelle zu lesen, wenn ein Auszug keine eindeutige Aussage erlaubt.

Eine kleinere Ergebnismenge hilft nur, wenn sie alles enthält, was die Entscheidung braucht. „Gezielt abrufen statt alles in den Kontext packen“ ist eine Regel für die Auswahl, keine Aufforderung, unbequemen Kontext auszublenden.

Subagenten klar begrenzte Aufgaben und einen unbelasteten Kontext geben

Erkundungsarbeit bekommt einen eigenen Kontext, wenn der Hauptagent ihre Rohdaten nicht benötigt. Anthropics Dokumentation zu Subagenten in Claude Code beschreibt Agenten, die in eigenen Kontextfenstern arbeiten und ihre Ergebnisse an das Hauptgespräch zurückgeben.

Ein Subagent, der ein Protokoll untersucht, kann eine konkrete Frage, relevante Angaben zum Dienst und einen Verweis auf das Protokoll erhalten. Zurückgeben soll er das Ergebnis, die zugehörige Fundstelle, verbleibende Unsicherheit und noch ungeklärte Abhängigkeiten. Der Hauptagent kann dieses Ergebnis nutzen, ohne den gesamten Suchverlauf mitzuführen.

Die Grenze: Mit der Trennung geht auch gemeinsames Wissen verloren. Der Subagent muss deshalb die benötigten Vorgaben erhalten und seine Schlussfolgerung mit Belegen zurückgeben. Es ist zu prüfen, was das eingesetzte Orchestrierungsframework tatsächlich an einen Subagenten weiterreicht. Den gesamten Verlauf des Hauptagenten zu kopieren, würde die beabsichtigte Trennung zunichtemachen. Werden sämtliche Gesprächsverläufe der Subagenten anschließend in den Hauptkontext eingefügt, entsteht dort dieselbe Unübersichtlichkeit erneut.

Dieses Muster eignet sich für Untersuchungen, die sich getrennt bearbeiten lassen. Eine eng verzahnte Entscheidung, die einen gemeinsamen Arbeitsstand voraussetzt, lässt sich womöglich leichter im Hauptkontext mit gezieltem Informationsabruf treffen.

Dokumente und aktuelle Frage bewusst anordnen

Die aktuelle Aufgabe muss sich klar vom unterstützenden Material unterscheiden lassen. Anthropics Empfehlungen für Prompts mit langem Kontext raten dazu, lange Dokumente weit oben im Prompt zu platzieren, ihre Quellen kenntlich zu machen und die Frage danach zu stellen. Außerdem sollen vor der Beantwortung von Dokumentfragen zunächst die relevanten Zitate gefunden werden.

In der Anwendung bleiben verbindliche Anweisungen im dafür vorgesehenen Anweisungskanal. Innerhalb der Aufgabeneingabe sollte das aktuelle Störungsprotokoll getrennt von historischen Notizen gekennzeichnet werden; anschließend folgen eine klare Frage und die Anforderungen an die Ausgabe. Abgerufener Text wird nicht allein dadurch zu einer verbindlichen Anweisung, dass er an eine andere Stelle verschoben wurde.

Die Grenze: Eine andere Anordnung kann keine Belege wiederherstellen, die nie geladen wurden. Zudem garantiert keine Reihenfolge bei jedem Modell und jeder Aufgabe ein gutes Ergebnis. Verschiedene Anordnungen sollten anhand eigener Beispiele verglichen werden. Ein vollständiges Regelwerk muss nicht in jeder Gesprächsrunde wiederholt werden, wenn eine knappe, aktuelle Aufgabenbeschreibung ausreicht.

Tool-Ausgaben gezielt kürzen und vollständig zugänglich halten

Zurückgegeben wird das Ergebnis, das für die nächste Entscheidung nötig ist, zusammen mit einem Verweis auf die vollständige Ausgabe. Anthropics Empfehlungen zum Tool-Design sehen aussagekräftige Antworten und Mechanismen wie Filterung, Seiteneinteilung und Kürzung vor. Die Dokumentation zur Kontextbearbeitung beschreibt gesondert, wie ältere Tool-Ergebnisse aus dem Gesprächsverlauf entfernt werden können.

Bei einer fehlgeschlagenen Prüfung genügen der Fehler, der relevante Ausschnitt der Fehlermeldung und der Speicherort des Berichts. Bei einer Suche werden relevante Passagen und ihre Quellen zurückgegeben. Bei einer erfolgreichen Aktion sind es der Status und die Kennungen, die für die Fortsetzung gebraucht werden. Der vollständige Bericht muss nicht allein deshalb eingebettet werden, weil das Tool ihn erzeugt hat.

Die Grenze: Blindes Abschneiden kann die entscheidende Fehlermeldung oder Einschränkung entfernen. Auslassungen müssen erkennbar sein, und der Agent muss weitere Inhalte anfordern können. Die vollständige Ausgabe sollte außerhalb des aktiven Kontexts erhalten bleiben, wenn sie später geprüft werden muss.

Diese Entscheidungen gehören in die Schicht, die die Anfrage zusammenstellt. Der umfassendere Leitfaden zum Context Engineering erläutert, wie Anweisungen, Gedächtnis, Tools und abgerufenes Material zusammenspielen.

Welche Behauptungen über Context Rot sind überzogen?

Es gibt weder eine allgemeingültige Nachrichtenanzahl noch einen Prozentsatz des Kontextfensters, ab dem jeder Agent neu starten sollte. Ein Schwellenwert, der zu große Anfragen verhindert, ist eine Kapazitätseinstellung. Ab wann ein bestimmter Workflow unzuverlässig wird, muss dagegen anhand seiner tatsächlichen Aufgaben gemessen werden.

Ebenso wenig belegt jede schlechte Antwort in einem langen Chat Context Rot. Fehlende Belege, widersprüchliche Anweisungen, ein defektes Tool oder eine Aufgabe, die das System nicht bewältigen kann, können ähnliche Symptome hervorrufen. Ein brauchbarer Fehlerbericht benennt die misslungene Entscheidung und hält fest, welche Eingabe das Modell erhalten hat.

Kontextverdichtung ist nicht verlustfrei, und externes Gedächtnis sorgt nicht automatisch für Relevanz. Beide sind Komponenten, deren Ergebnisse geprüft werden müssen. Wer eine falsche Schlussfolgerung effizienter bewahrt, kann einen Workflow damit dauerhaft auf den falschen Kurs bringen.

Caching setzt wiederum an einer anderen Stelle an. Ein KV-Cache verwendet Attention-Berechnungen erneut. Er entscheidet weder, welches Dokument wichtig ist, noch entfernt er veralteten Verlauf. Auch eine Anfrage, die den Cache gut nutzt, kann für die nächste Entscheidung das falsche Material enthalten.

Eine kurze Checkliste für diese Woche

Für einen Agenten mit einem wiederkehrenden Fehler:

• Die tatsächliche Eingabe zum Zeitpunkt der Fehlentscheidung aufzeichnen und die dafür benötigten Belege bestimmen.
• Die Aufgabe mit fokussierten Belegen und unveränderten Anforderungen erneut durchspielen; die Korrektheit anhand repräsentativer Fälle vergleichen.
• Die Tool-Antwort mit dem meisten überflüssigen Material durch einen relevanten Auszug und einen Verweis auf die vollständige Ausgabe ersetzen.
• Eine Übergabe für die Kontextverdichtung festlegen, die Entscheidungen, verworfene Ansätze, Vorgaben, Quellen und offene Arbeiten erhält.
• Eine abtrennbare Untersuchung in einen unbelasteten Subagenten-Kontext auslagern, wenn die Erkundungsarbeit den Kontext überfrachtet.
• Die Änderung erst ausrollen, wenn der fortgesetzte Workflow die nötigen Fakten bewahrt und den untersuchten Fehler verringert; das bisherige Verhalten muss wiederherstellbar bleiben.

Am Anfang steht ein reproduzierbarer Fehler. Damit erhält die Änderung ein klares Abnahmekriterium, statt „weniger Kontext“ zum Erfolgsmaßstab zu machen.

Häufige Fragen zu Context Rot

Ist Context Rot noch ein Problem?

Anthropics aktuelle Compaction-Dokumentation beschreibt weiterhin ausdrücklich, dass die Antwortqualität mit wachsendem Gesprächsverlauf abnimmt. Das spricht dafür, Kontext weiterhin gezielt zu verwalten. Es belegt jedoch nicht, wie sich jedes aktuelle Modell verhält. Entscheidend ist die Evaluation des eingesetzten Modells und Workflows.

Wie lässt sich Context Rot vermeiden?

Aktuelle Anweisungen und notwendige Belege beibehalten, überholtes oder redundantes Material entfernen, den Verlauf sorgfältig verdichten und Details bei Bedarf abrufen. Nebenaufgaben mit vielen irrelevanten Zwischenergebnissen lassen sich gegebenenfalls auslagern. Bei jeder Änderung muss geprüft werden, ob die für den nächsten Schritt nötigen Fakten erhalten bleiben.

Was verursacht Context Rot?

Die Kontextlänge, die Relevanz des umgebenden Materials und die Darstellung der Informationen können die Zuverlässigkeit beeinflussen. Die ursprüngliche Studie weist keinen einzelnen zugrunde liegenden Mechanismus nach. Bei einem Agenten sollten zunächst die übergebenen Belege und der Arbeitsstand geprüft werden, bevor eine Korrektur ausgewählt wird.

Den Newsletter abonnieren für praxisnahe Leitfäden zur Entwicklung und zum Betrieb von KI-Workflows.