Lost in Compaction: Wie Agenten sitzungsweite Regeln verlieren
Ein neues Paper untersucht, welche Nutzerregeln Context Compaction überleben. Im Mittel bleiben nur 17 Prozent erhalten, ein separater Extractor kommt auf über 90 Prozent.
Ein Agent bekommt zu Beginn einer langen Session die Anweisung, E-Mails nie direkt zu versenden. Vorher soll immer ein Entwurf gezeigt und auf Freigabe gewartet werden.
Danach folgen hunderte Turns, Tool Calls, Recherche und weitere Aufgaben. Irgendwann wird das Context Window knapp und der bisherige Verlauf wird komprimiert. Die aktuelle Aufgabe landet in der Zusammenfassung, die E-Mail-Regel nicht.
Später soll der Agent Sarah schreiben und verschickt die Nachricht direkt.
Das Paper „Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction“ von Zhiqi Wang, Yichi Zhang, Dongwon Lee und Yuchen Yang von der Pennsylvania State University untersucht solche Fälle. Für den Benchmark COMPINT platzieren die Autoren sitzungsweite Regeln in langen Agent-Verläufen und prüfen, was davon nach der Compaction übrig bleibt. Über alle getesteten Compactor-Konfigurationen hinweg waren es im Mittel 17 Prozent.1
Damit geraten Regeln in den Blick, die weder normale Task-Daten noch dauerhafte Nutzerpräferenzen sind. Sie gelten für eine Session, oft über viele Turns hinweg. Stehen sie nur in einer alten User-Nachricht, hängt ihre weitere Gültigkeit davon ab, ob die Compaction sie erhält.
Context Compaction gehört zum normalen Agent-Betrieb
Lange Agent-Läufe wachsen schnell über das nutzbare Context Window hinaus. Neben den eigentlichen Nachrichten sammeln sich Tool Calls, Tool-Ergebnisse, Code, Fehlermeldungen und Zwischenschritte an. Irgendwann muss ein Teil davon entfernt oder zusammengefasst werden.
Codex macht das automatisch. OpenAI beschreibt den Agent Loop so, dass bei Erreichen eines Schwellenwerts ein Compaction-Schritt ausgeführt wird. Die Responses API bietet dafür einen eigenen /responses/compact-Endpunkt; Codex verwendet den Mechanismus automatisch, sobald sein auto_compact_limit erreicht ist.2
Anthropic bietet für Claude ebenfalls serverseitige Compaction an. Ältere Conversation History wird dabei durch einen kompakteren compaction-Block ersetzt, damit die Session weiterlaufen kann.3
Ohne solche Mechanismen endet eine längere Agent-Session am Context Limit. Für die Architektur ist deshalb relevant, welcher Zustand die Komprimierung unabhängig überleben muss.
COMPINT trennt Aufgabe und Session Constraint
COMPINT betrachtet zusätzliche Regeln mit längerer Lebensdauer getrennt von der unmittelbaren Aufgabe eines Turns.
„Schreibe Sarah eine E-Mail“ ist eine Aufgabe.
„Zeige mir in dieser Session jede E-Mail vor dem Versenden“ ist eine Session Constraint.
Im Paper werden solche Regeln als Session beziehungsweise Side Constraints bezeichnet. Sie gelten über mehrere Turns hinweg, können aber trotzdem temporär sein. COMPINT verwendet 15 Constraints aus fünf Kategorien, jeweils drei pro Kategorie.1
| Kategorie | Beispiel |
|---|---|
| Action | Vor einer Aktion erst Freigabe einholen |
| Information | Ein vertrauliches Verzeichnis nicht öffnen |
| Process | Vor jeder Antwort zuerst eine Websuche durchführen |
| Preference | Primärquellen bevorzugen |
| Output | Nur in Bullet Points antworten |
Eine Output Preference hat andere Folgen als die Anweisung, bestimmte Dateien nicht zu lesen oder keine externen Aktionen ohne Bestätigung auszuführen. Im normalen Conversation Context sind es zunächst trotzdem nur Textstücke aus früheren User-Turns.
Drei Datensätze mit rund 100.000 Tokens Kontext
COMPINT verwendet drei verschiedene Ausgangsdatensätze und erzeugt daraus lange Sessions mit ungefähr 100.000 Tokens.1
WildChat steht für lange normale Unterhaltungen. Eine Instanz enthält im Mittel 519 Turns und 257 User-Turns.
Hermes Agent enthält Tool Calls und längere Agent-Trajektorien. Dort sind es durchschnittlich rund 120 Turns, aber nur neun User-Turns.
OpenResearcher bildet einen anderen Fall ab: eine grosse Nutzeranfrage, danach eine lange autonome Research-Trajektorie mit mehr als 300 Turns.
Für jeden Datensatz erzeugen die Autoren 50 Long-Context-Instanzen und platzieren darin die 15 Constraints. Allein die Hauptauswertung kommt damit auf 750 Fälle pro Compactor-Konfiguration. Weitere Versuche verändern Position, Formulierung und Wiederholungszahl der Regeln.1
Getestet werden sehr unterschiedliche Ansätze: nur die letzten fünf Turns behalten, LLMLingua-2 sowie LLM-basierte Zusammenfassungen mit Gemma, Qwen, gpt-oss-120b und GPT-5.4-mini.
Für die LLM-Compactors verwenden die Autoren unter anderem den von Anthropic veröffentlichten Compaction-Prompt und den strukturierten Prompt aus pi-mono. Letzterer besitzt bereits einen eigenen Abschnitt für Constraints und Preferences.1
Die Bezeichnung „Anthropic“ in den Ergebnistabellen meint diesen Prompt. COMPINT vermisst damit nicht die aktuelle Claude-Server-Compaction als Black Box. Dasselbe gilt für Codex: GPT-5.4-mini taucht als Compactor-Modell auf, der Test entspricht aber nicht OpenAIs produktivem /responses/compact-Pfad.
Im Mittel bleiben 17 Prozent der Regeln erhalten
Die Ergebnisse unterscheiden sich stark nach Datensatz, Modell und Prompt. Der Mittelwert über alle Konfigurationen liegt bei 17 Prozent Retention.1
Bei Hermes Agent erreicht gpt-oss-120b mit dem Anthropic-Prompt 18,5 Prozent. Mit dem stärker strukturierten pi-mono-Prompt sind es 36,3 Prozent.
Bei OpenResearcher steigt derselbe Vergleich von 8,4 auf 19,6 Prozent.
Auf WildChat funktioniert diese Kombination deutlich schlechter: 1,3 Prozent mit dem Anthropic-Prompt und 0 Prozent mit pi-mono.1
GPT-5.4-mini erzielt in einzelnen Setups wesentlich höhere Werte. Auf OpenResearcher erreicht die Kombination mit pi-mono 98 Prozent. Auf WildChat fällt sie auf 6,7 Prozent. Die GPT-5.4-mini-Läufe unterscheiden sich allerdings von der Hauptauswertung: ungefähr 220.000 Tokens Kontext, weniger Samples und deutlich höhere API-Kosten. Die Autoren nennen rund 800 Dollar allein für diesen Zusatzversuch.1
Ein einzelnes Modell oder ein einzelner schlechter Prompt erklärt die Ergebnisse damit nicht. Kontextstruktur, Position und Datensatz verändern die Retention stark.
Wenn die Regel wieder angehängt wird, folgt der Agent ihr fast immer
COMPINT misst auch das Verhalten nach der Compaction.
Zu jeder Regel gibt es zunächst eine Probe mit einer konformen und einer verletzenden Aktion. Bei der E-Mail-Regel muss das Modell beispielsweise zwischen „Entwurf zeigen und warten“ und „E-Mail direkt senden“ unterscheiden.1
Zusätzlich gibt es einen freien Tool-Use-Test. Der Agent darf dort normal antworten oder Tools aufrufen.
Mit dem kompaktierten Kontext lag die Compliance in diesem Experiment bei 31,8 Prozent. Wurde dieselbe Session Constraint nach der Compaction explizit wieder angehängt, stieg sie auf 99,7 Prozent. Mit dem vollständigen, nicht kompaktierten Verlauf inklusive Constraint waren es 73,4 Prozent.1
Die Autoren wiederholen den Versuch ausserdem mit gpt-oss-120b, Qwen3-30B-A3B und Gemma-4-E4B als ausführenden Modellen. Sobald die Constraint nach der Compaction wieder explizit im Context steht, liegen alle drei über 98 Prozent Compliance. Mit der normalen kompaktierten Repräsentation liegt die effektive Retention dagegen zwischen 12,8 und 27,6 Prozent.1
Der Sprung von 31,8 auf 99,7 Prozent ist ein starkes Indiz für Informationsverlust im Compaction-Schritt. Der Downstream-Agent kann die Regel in vielen Fällen anwenden; nach der Compaction bekommt er sie häufig nicht mehr zu sehen.
Regeln am Ende des Contexts überleben häufiger
Die Position einer Constraint verändert die Retention deutlich.
Bei Hermes Agent mit gpt-oss und pi-mono liegt sie bei 36 Prozent, wenn die Regel am Anfang steht. In der Mitte sind es 57 Prozent, kurz vor der Compaction 80 Prozent.1
Ein Versuch mit 50.000 statt 100.000 Tokens stützt denselben Effekt. Für eine Constraint am Anfang steigt die Retention von 36 auf 59 Prozent, in der Mitte von 57 auf 70 Prozent. Direkt am Ende ändert sie sich mit 80 auf 81 Prozent kaum.1
Das unterscheidet sich vom bekannten „Lost in the Middle“-Effekt, bei dem Informationen häufig am Anfang und Ende besser genutzt werden als in der Mitte.4 Bei COMPINT sieht die Kurve eher nach Distanz zum Compaction-Prompt aus: Je weiter eine Regel zurückliegt, desto eher verschwindet sie aus der erzeugten Repräsentation.
Für sitzungsweite Regeln ist dieser Recency-Effekt ungünstig. Solche Regeln werden oft früh festgelegt und sollen viel später noch gelten.
Strengere Formulierungen und Wiederholungen helfen nur begrenzt
Die Autoren testen auch, ob sich das Problem durch Formulierung lösen lässt. Constraints werden deutlicher geschrieben oder mit Hinweisen wie „This is an important constraint“ versehen.
Bei LLM-Compactors steigt die Retention dadurch messbar. Auf Hermes Agent erhöht sie sich bei gpt-oss mit Anthropic-Prompt beispielsweise von 9,1 Prozent bei der schwächsten Formulierung auf 24,1 Prozent bei einer strikten und expliziten Variante.1
Danach bauen die Autoren einen eigenen Compaction-Prompt, der ausdrücklich verlangt, alle weiterhin gültigen Nutzerregeln inklusive Bedingungen in die Zusammenfassung zu übernehmen. Auch damit steigen die Werte. Auf WildChat bleiben trotzdem weniger als 40 Prozent der Constraints erhalten.1
Wiederholung hilft ebenfalls, aber nicht linear. Die Retention wächst zunächst deutlich, wenn dieselbe Regel mehrfach im Verlauf auftaucht. Ab ungefähr 30 Wiederholungen flacht der Effekt ab.1
Als State-Management-Strategie taugt das kaum. Eine Regel sollte nicht dreissigmal im Chat stehen müssen, damit sie einen Compaction-Schritt überlebt.
Eine separate Constraint-Registry kommt auf über 90 Prozent
In einem weiteren Versuch nehmen die Autoren die Constraints aus dem normalen Compaction-Pfad heraus.
Ein Qwen3.5-9B läuft parallel zur Conversation und untersucht jeden neuen User-Turn. Erkennt das Modell eine länger gültige Regel, schreibt es sie in eine separate Session-Constraint-Registry. Beim nächsten Compaction Event wird die erzeugte Summary anschliessend mit dieser Registry ergänzt.1
Der Extractor muss dabei nicht jedes Mal den kompletten 100K-Context lesen. Er bekommt im Wesentlichen die aktuelle User-Nachricht, die vorherige Assistant-Nachricht und die bereits existierende Registry zur Deduplizierung.1
Die Retention liegt damit deutlich höher:
| Datensatz | Retention |
|---|---|
| Hermes Agent | 95,6 % |
| OpenResearcher | 95,1 % |
| WildChat | 90,3 % |
Im Mittel erreicht der Extractor 93,7 Prozent. Selbst auf WildChat liegt er mehr als 50 Prozentpunkte über dem besten speziell auf Constraints optimierten Compaction-Prompt.1
Code und Benchmark sind im Repository der Autoren veröffentlicht.5
Die Registry braucht Scope und Lifecycle
Für eine produktive Implementierung würde ich die Registry nicht als wachsende Liste von Textsätzen übernehmen.
Eine Constraint sollte mindestens einen Typ, ihre Quelle, einen Gültigkeitsbereich und einen Status haben. Eine Output Preference ist etwas anderes als eine Action-Regel oder eine Sperre für bestimmte Informationen. Diese Unterschiede werden spätestens dann relevant, wenn verschiedene Tools und Subagenten dieselbe Session benutzen.
Regeln können ausserdem ersetzt oder aufgehoben werden:
„Ab jetzt musst du nicht mehr vor jedem Kommando fragen.“
oder:
„Die Regel gilt nur noch für Produktionssysteme.“
Der im Paper beschriebene Extractor hängt neu erkannte, nicht duplizierte Constraints an die Registry an.1 Für ein produktives System bräuchte es zusätzlich Update-, Scope- und Revocation-Semantik. Sonst bleibt eine alte Regel zuverlässig erhalten, obwohl sie längst nicht mehr gilt.
Ich würde solche Constraints als expliziten Session-State führen und bei jeder Compaction erneut in den Model Context injizieren. Die Conversation bleibt die Quelle für normale Historie; Regeln mit Auswirkungen auf spätere Aktionen bekommen einen eigenen Lebenszyklus.
Sicherheitsregeln gehören nicht nur in die Conversation History
Für Coding Agents wird die Unterscheidung besonders deutlich bei Regeln wie „vor dem Löschen nachfragen“ oder „dieses Verzeichnis nicht lesen“.
Als User-Nachricht ist eine solche Regel Teil der Conversation History. Eine Sandbox, Approval Policy oder Tool Policy liegt ausserhalb der Conversation und übersteht Compaction unabhängig von einer Zusammenfassung.
Nicht jede Session Constraint muss zu einer harten Security Policy werden. Bei Regeln, die Dateien, Credentials, Netzwerkzugriffe oder externe Aktionen betreffen, würde ich aber möglichst wenig davon abhängig machen, ob ein Compactor den richtigen Satz erhält.
Eine Constraint-Registry wäre dafür eine zusätzliche Schicht zwischen Conversation und statischer Policy. Sie könnte temporäre Regeln über lange Sessions erhalten, ohne sie dauerhaft in ein Nutzerprofil oder eine globale Systemkonfiguration zu übernehmen.
Die 17 Prozent sind keine Messung von Codex oder Claude
Die 17 Prozent sollte man nicht als „Codex vergisst 83 Prozent seiner Regeln“ oder als entsprechende Aussage über Claude lesen.
COMPINT untersucht kontrollierte Compactor-Konfigurationen mit veröffentlichten Prompts und aktuellen Modellen. OpenAIs heutige Codex-Compaction verwendet einen nativen Responses-API-Mechanismus mit einem opaken Compaction Item.2 Anthropic bietet ebenfalls eine eigene serverseitige Compaction an.3 Diese produktiven Systeme werden im Paper nicht vollständig als Black Box vermessen.
Belastbar ist die engere Aussage: In den getesteten Compaction-Verfahren gehen sitzungsweite Constraints häufig verloren. Das passiert über mehrere Modelle, Datensätze, Positionen und Prompt-Varianten hinweg. Ein speziell auf Constraints optimierter Summary-Prompt verbessert die Retention, beseitigt das Problem aber nicht. Die getrennte Registry erreicht im selben Benchmark wesentlich höhere Werte.1
Dazu kommen die Grenzen des Preprints. Die Autoren arbeiten mit 15 konstruierten Constraints, synthetisieren lange Testinstanzen aus bestehenden Datensätzen und verwenden GPT-5.4 als Judge für die Hauptmessung. Den Judge vergleichen sie mit einem Menschen und Gemini; bei den 50 manuell bewerteten Samples berichten sie vollständige Übereinstimmung. Das ist eine kleine Validierungsstichprobe.1
Wenn eine Regel nach 100.000 Tokens noch gelten soll, würde ich sie nach diesen Ergebnissen nicht nur in der Conversation History lassen. Ich würde sie in Session-State übernehmen und nach jeder Compaction wieder in den Model Context geben.