Das Problem ist nicht nur ein volles Context Window

Ein Coding-Agent beginnt mit einer kleinen Aufgabe: einen fehlgeschlagenen Test untersuchen, eine Abhängigkeit verfolgen, ein Modul ändern, Prüfungen ausführen und den Patch erklären. Dann wächst die Aufgabe. Der Agent liest Issue-Verläufe, öffnet Dutzende Dateien, ruft wiederholt Tools auf, verarbeitet Testausgaben, stößt auf eine Deployment-Warnung und muss zugleich Vorgaben beachten, was er keinesfalls ändern darf.

Irgendwann ist der vollständige Verlauf zu groß oder zu teuer, um ihn bei jeder Modellanfrage mitzuschicken. Die naheliegende Antwort lautet: zusammenfassen. Das ist nötig, aber genau dort können lang laufende Agents unbemerkt unzuverlässig werden.

Long-horizon context management bezeichnet die bewusste Steuerung der für das Modell sichtbaren Informationen, wenn eine Agent-Aufgabe ein praktisches Context-Budget übersteigt. Dazu gehört, festzulegen, was erhalten, zusammengefasst, entfernt, später abgerufen oder außerhalb der Unterhaltung gespeichert wird. Es geht nicht nur darum, unter einem Token-Limit zu bleiben. Es geht darum, genug Kontinuität zu bewahren, damit der Agent die richtige Aufgabe unter den richtigen Einschränkungen beendet.

Das ist ein Arbeitsbegriff, keine gefestigte Branchenterminologie. Du wirst auch Begriffe wie Agent Context Management, Context Compaction, Context Compression oder Long-running Agent State Management sehen. „Compaction“ meint meist, einen Teil des Verlaufs durch eine kürzere Darstellung zu ersetzen. Context Management ist weiter gefasst: Es umfasst auch Löschen, Retrieval, Caching, State Schemas, Validierung und Wiederherstellung.

Einfach gesagt: Wenn der Verlauf eines Agents zu groß wird, kürze ihn nicht einfach. Entscheide bewusst, welche Fakten sofort verfügbar bleiben müssen, welche erneut abgerufen werden können und welche Regeln nie von einer Zusammenfassung abhängen dürfen.

Das ist jetzt relevant, weil Agent-Läufe länger werden und mehr Tools einsetzen. Die Python- und TypeScript-SDK-Releases von Anthropic vom 15. September 2026 ergänzten Beta-Context Compaction-Parameter und signierte Compaction Blocks. Damit wird Compaction zu einer expliziten Runtime-Frage statt zu einem improvisierten Prompt-Trick. Anthropic Python SDK release Anthropic TypeScript SDK release

Aktiver Kontext ist ein Arbeitsvorrat, kein Archiv

Ein Modell arbeitet nur mit dem aktiven Kontext: den Instructions, Nachrichten, Tool-Ergebnissen und weiteren Informationen in der aktuellen Anfrage. Ein Verlauf kann historisch vollständig sein und trotzdem ein schlechter aktiver Kontext. Rohe Kommandoausgaben verdrängen die eigentliche Aufgabe. Eine alte, aber bindende Einschränkung wird von neuer Unterhaltung überlagert. Ein Log mit 20.000 Zeilen ist nicht schon deshalb nützlich, weil es verfügbar ist.

Ein belastbares Design behandelt den aktiven Kontext als Arbeitsvorrat. Er sollte enthalten, was das Modell für die nächste Entscheidung benötigt, nicht jedes Detail der Vergangenheit. Der Rest gehört an einen von drei Orten:

  • in eine kompakte State-Darstellung für Fakten, die sofort verfügbar bleiben müssen;
  • in External Memory für dauerhafte, abfragbare Informationen, die bei Bedarf abgerufen werden; und
  • in maßgebliche Systeme für Informationen, die exakt sein müssen, etwa Quelldateien, Issue-IDs, Deployment-Datensätze, Transaktionskennungen und Berechtigungen.

Gerade die letzte Unterscheidung ist entscheidend. Eine vom Modell erzeugte Zusammenfassung kann sagen, eine Migration sei gelungen. Sie ist kein Beleg dafür. Bei irreversiblen oder folgenreichen Vorgängen muss der maßgebliche Nachweis außerhalb des Modelltexts bleiben.

Einfach gesagt: Ein kompaktierter Verlauf kann einem Agent beim Weiterdenken helfen. Er darf nicht zum einzigen Nachweis dafür werden, was das System getan hat.

Wie Compaction praktisch funktioniert

Die Details der Implementierung unterscheiden sich, der Ablauf ist aber ähnlich.

Zuerst überwacht die Runtime das Wachstum des Kontexts. Auslöser können ein Token-Schwellenwert, eine maximale Zahl von Tool-Aufrufen, ein Kostenbudget oder eine Policy-Grenze vor einer riskanten Aktion sein. Erst auf einen Fehler der Anfrage zu warten, ist ein schwacher Auslöser: Dann bleibt keine Zeit, State sorgfältig zu sichern.

Danach wählt die Runtime eine Operation. Sie kann ältere Nachrichten in strukturierten State zusammenfassen. Sie kann ausgewählte alte Tool-Ergebnisse entfernen, die bereits in eine Entscheidung eingeflossen sind. Oder sie verschiebt Material in externen Speicher und hinterlässt eine kompakte Referenz, über die der Agent es wiederfinden kann.

Als Nächstes entsteht eine Projektion der Aufgabe. Gute Projektionen trennen dauerhafte Fakten von Unterhaltungserzählung. Sie können Ziel, explizite Akzeptanzkriterien, erledigte Schritte, offene Fragen, relevante Ressourcenkennungen, geänderte Artefakte, ausstehende Prüfungen und nicht verhandelbare Einschränkungen festhalten. Sie sollten nicht vorgeben, jede Nuance des ursprünglichen Verlaufs zu bewahren.

Dann baut die Runtime die nächste Anfrage aus dieser Projektion, dem jüngsten Verlauf und den neuen Belegen. Gibt ein Provider einen typisierten Compaction Block zurück, behandle ihn als Protokolldaten, nicht als gewöhnlichen Assistant-Text. Speichere ihn und führe ihn genau nach den Vorgaben des Provider-Protokolls wieder mit; zugehörige undurchsichtige Metadaten können ebenfalls nötig sein, um Kontinuität zu erhalten. Die neuen signierten Blocks von Anthropic zeigen konkret, dass diese Grenze Teil der Agent-Infrastruktur wird. Python release TypeScript release

Zum Schluss validierst du den Übergang. Der Agent sollte sein aktuelles Ziel, die nächste sichere Aktion und die weiter geltenden Einschränkungen benennen können. Bei riskanteren Workflows solltest du an dieser Grenze für eine Policy-Prüfung, eine Evaluation oder eine menschliche Freigabe anhalten.

Das ist Context Engineering zur Laufzeit. Context Engineering ist die umfassendere Disziplin, für das Modell sichtbare Informationen auszuwählen, zu strukturieren und anzuordnen. Long-horizon context management ist das Lebenszyklusproblem: Was geschieht, wenn diese Informationen wachsen, sich ändern, verdichtet werden und über Anfragen oder Sessions hinweg erhalten bleiben müssen?

Was es nicht ist

Compaction wird oft mit Prompt Caching verwechselt. Prompt Caching nutzt stabile Prompt-Präfixe erneut, sodass ein Provider sie nicht auf dieselbe Weise neu berechnen oder übertragen muss. Compaction reduziert oder verändert die Informationen, die das Modell aktiv sieht. Beide Techniken ergänzen sich, aber Caching löst keinen Informationsverlust, und Compaction garantiert keine niedrigeren Inference-Kosten.

Es ist auch nicht bloß eine Gesprächszusammenfassung. Eine Zusammenfassung ist ein Ergebnis. Context Management umfasst außerdem Auslöser, Schema, Auswahlregeln, den Erhalt von Protokollobjekten, Wiederherstellungsverhalten und Tests an der Grenze.

Ebenso wenig ist es ein verlässlicher Checkpoint. Ein Checkpoint soll die Wiederherstellung aus einem bekannten Zustand ermöglichen, meist mit reproduzierbaren externen Daten. Eine Sprachmodell-Zusammenfassung ist probabilistisch und verlustbehaftet. Sie kann beim Wiederaufnehmen des Denkens helfen, reicht aber nicht als einzige Grundlage für einen Datenbank-Write, ein Production-Rollout oder eine sicherheitsrelevante Entscheidung.

Einfach gesagt: Eine Zusammenfassung ist ein nützliches Briefing für den nächsten Modellaufruf, kein Transaktionsprotokoll, kein Berechtigungssystem und keine Quelle der Wahrheit.

Beispiel: ein Agent für Repository-Wartung

Stell dir als Beispiel einen Agent vor, der einen Service nach der Abkündigung einer Abhängigkeit aktualisieren soll. Er muss Verwendungen finden, eine abwärtskompatible Änderung vornehmen, die Prüfungen des Projekts ausführen und einen Pull Request vorbereiten. Er darf ein Repository ändern, aber weder deployen noch Cloud-Infrastruktur verändern.

Zu Beginn sieht der Agent Aufgabenanweisungen, Repository-Policy und seine Tool-Berechtigungen. Im Verlauf sammelt er Datei-Lesevorgänge, Suchergebnisse, fehlgeschlagene Test-Logs, Paketmetadaten, Diffs und Erklärungen. Nach genug Aufrufen führt die Runtime eine Compaction durch.

Ein schwaches Design fordert das Modell auf, „alles bisherige zusammenzufassen“, verwirft den Verlauf und arbeitet weiter. In der Zusammenfassung können das genaue fehlgeschlagene Kommando, die Versionsbeschränkung oder die Vorgabe fehlen, keine Deployment-Konfiguration zu ändern. Sie kann einen Patch beschreiben, ohne die konkret geänderten Dateien zu behalten.

Ein stärkeres Design erzeugt strukturierten Task State. Es erhält Ziel, genehmigten Repository-Geltungsbereich, geänderte Dateien und ihre aktuellen Revisionen, ausgeführte Tests und Ergebnisse, die offene Kompatibilitätsfrage sowie das Verbot von Deployment-Änderungen. Große Logs werden extern mit stabilen Referenzen gespeichert; der Agent kann den relevanten Abschnitt bei Bedarf abrufen. Das eigentliche Repository bleibt maßgeblich für Dateiinhalte.

Die nächste Anfrage enthält den kompakten State, aktuelle Nachrichten und nur die neuen Belege, die für die nächste Aktion nötig sind. Vor dem Öffnen eines Pull Request vergleicht eine Evaluation das Verhalten vor und nach der Compaction bei demselben Repository-State. Meidet der Agent weiterhin Deployment-Dateien? Führt er einen Test erneut aus, von dem bereits bekannt ist, dass er aus einem anderen Grund fehlschlägt? Fragt er nach fehlenden Informationen, statt sie zu erfinden?

Die Einschränkung sollte nicht nur in Text stehen. Der Guardrail gegen Deployment-Änderungen braucht auch Durchsetzung in Tool- und Authorization-Schicht. Eine Zusammenfassung kann eine Regel bekräftigen; sie darf nicht der einzige Mechanismus sein, der eine verbotene Aktion verhindert.

Wo es scheitert

Der grundlegende Fehler ist Verlust. Zusammenfassungen lassen exakte Werte, Unsicherheit, Herkunft und Einschränkungen aus. Wiederholte Compaction verstärkt diesen Verlust: Eine Zusammenfassung einer Zusammenfassung hat noch weniger Chancen, ein wichtiges Detail zu behalten.

Besonders anfällig sind Sicherheitsvorgaben. Eine Studie aus 2026 berichtet, dass Compaction Governance-Einschränkungen im Kontext unbemerkt entfernen kann, worauf Agents verbotene Tool-Aktionen ausführen können. Studie zu Governance Decay Eine weitere empirische Studie aus 2026 berichtet, dass wiederkehrende Compression den Einfluss jüngster Interaktionen schwächen und zu blockierten Aktionen, wiederholter Exploration und instabilem Verhalten führen kann. Studie zu Execution Instability Das sind Forschungsergebnisse, kein Beweis dafür, dass jede Implementierung so scheitert. Sie sind ein guter Grund, die Grenze zu testen, statt flüssig klingenden Zusammenfassungen zu vertrauen.

Daneben gibt es alltäglichere Fehler. Eine Zusammenfassung kann die Erzählung erhalten, aber die Dateiversion verlieren, auf der ein Patch beruhte. Ein Provider-spezifischer Compaction Block kann bei einem Retry falsch serialisiert werden oder fehlen. Ein Wiederherstellungspfad kann eine teure Operation erneut ausführen oder nach einer fehlerhaften Zusammenfassung weiterlaufen, obwohl er stoppen sollte.

Die Antwort lautet nicht: „Nie kompaktieren.“ Ohne Compaction stoßen viele nützliche lang laufende Workflows irgendwann an ihre Grenze. Die Antwort ist, den Verlust sichtbar zu machen und kritischen State außerhalb der verlustbehafteten Schicht zu halten.

Was du diese Woche tun kannst

Beginne mit einem begrenzten Agent-Workflow, nicht mit einem offenen autonomen System. Instrumentiere Kontextgröße, Compaction-Auslöser, Fehler, Retries und die Zahl der Fälle, in denen ein Agent eine bereits abgeschlossene Untersuchung wiederholt. So wird aus einem vagen Qualitätsproblem beobachtbares Verhalten.

Definiere ein State Schema, bevor du ein Modell um eine Zusammenfassung bittest. Trenne mindestens Ziel, erledigte Arbeit, ausstehende Arbeit, Einschränkungen, Kennungen, Artefakte und Unsicherheit. Entscheide für jedes Feld, ob der kompakte State maßgeblich, nur beratend oder lediglich ein Verweis auf einen externen Datensatz ist.

Baue dann Evaluations, die eine Compaction-Grenze überschreiten. Gib dem Agent eine Aufgabe mit einer wichtigen Einschränkung zu Beginn, genug irrelevante Tool-Ausgabe, um Compaction auszulösen, und später eine verlockende Aktion, die diese Einschränkung verletzt. Prüfe, ob externe Kontrollen diese Aktion weiterhin verweigern, selbst wenn der kompaktierte State unvollständig ist.

Entwirf schließlich die Wiederherstellung bewusst. Entscheide, ob ein Compaction-Fehler anhalten, wiederholen, State aus externen Datensätzen neu aufbauen oder mit dem ursprünglichen Verlauf fortsetzen soll, sofern dieser verfügbar ist. Die richtige Wahl hängt von Kosten und Umkehrbarkeit der nächsten Aktion ab. Entscheidend ist, dass sie eine entworfene Policy ist und kein Zufallsverhalten nach einem Token-Limit-Fehler.

Lang laufende Agents werden immer nur begrenzten aktiven Kontext haben. Die technische Chance besteht darin, diese Grenze zu einer expliziten State-Grenze zu machen: beobachtbar, testbar, wiederherstellbar und niemals allein verantwortlich dafür, die wichtigen Kontrollen zu bewahren.