Context Engineering: Compaction, Memory-Tools und Context Rot bei langen Agentenläufen

Das typische Bild aus dem Produktivbetrieb: Ein Agent löst die ersten zehn Schritte einer Aufgabe sauber, arbeitet Schritt fünfzehn noch korrekt ab – und ignoriert bei Schritt vierzig eine Vorgabe, die im ersten Nutzerturn glasklar formuliert war. Die naheliegende Reaktion ist, ein größeres Modell oder ein größeres Fenster zu kaufen. Beides hilft weniger als erwartet.

Context Engineering ist die Disziplin, die entscheidet, welche Information zu welchem Zeitpunkt im Arbeitsspeicher des Modells liegt – und welche nicht. Dieser Artikel bündelt, was aus vier Arbeiten der Monate Mai bis Juli 2026 und aus den öffentlich dokumentierten Vendor-Implementierungen belastbar ableitbar ist, und übersetzt es in Entscheidungen für einen selbst betriebenen Orchestrator.

Context Rot: das messbare Problem

Die Referenzarbeit zum Thema ist älter als die aktuelle Compaction-Welle: „Context Rot: How Increasing Input Tokens Impacts LLM Performance" von Kelly Hong, Anton Troynikov und Jeff Huber (Chroma), veröffentlicht am 14. Juli 2025. Getestet wurden 18 Modelle – unter anderem Claude Opus 4, Claude Sonnet 4 und Sonnet 3.7/3.5, GPT-4.1 samt mini und nano, GPT-4o, o3, Gemini 2.5 Pro und Flash sowie Qwen3-235B-A22B, Qwen3-32B und Qwen3-8B. Der Befund ist über alle Familien hinweg konsistent: Mit wachsender Eingabelänge sinkt die Zuverlässigkeit, selbst wenn die gesuchte Information vollständig im Kontextfenster steht.

Drei Details aus der Arbeit sind für den Entwurf eines Agentensystems wichtiger als die Überschrift:

• Der Abfall ist nicht linear, sondern klippenartig. Viele Modelle halten ihre Genauigkeit bis rund 32k Token weitgehend, brechen dann aber bei 64k spürbar ein. Wer ein Budget plant, plant also nicht gegen eine sanfte Kurve, sondern gegen eine Kante.
• Ein einziger Distraktor genügt. Schon ein irrelevanter, aber thematisch ähnlicher Textblock senkt die Trefferquote – und der Effekt verstärkt sich, je länger der Gesamtinput ist.
• Fokus schlägt Vollständigkeit deutlich. In der LongMemEval-Auswertung liegt zwischen einem fokussierten Prompt von rund 300 Token und dem vollen Prompt von rund 113.000 Token eine große Leistungslücke – bei jeder getesteten Modellfamilie.

Kontraintuitiv ist ein vierter Befund: Modelle schneiden auf gemischten, unstrukturierten Haystacks tendenziell besser ab als auf logisch kohärenten. Ein langer, thematisch dichter Kontext ist also nicht der sichere Fall, sondern der schwierige. Das entwertet die verbreitete Annahme, Long-Context-Fähigkeit ließe sich durch „einfach alles reinlegen" nutzen.

Compaction: Wann komprimieren, was behalten

Compaction bedeutet: Der laufende Verlauf eines Agenten wird an definierten Punkten verdichtet, sodass der aktive Kontext klein bleibt, während der Auftrag weiterläuft. In der Praxis werden dabei zwei Verfahren verwechselt, die Anthropic selbst sauber trennt – und man sollte sie auch im eigenen Orchestrator trennen:

• Context Editing löscht. Alte Tool-Ergebnisse oder Thinking-Blöcke werden entfernt. Beta-Header context-management-2025-06-27, Strategien clear_tool_uses_20250919 und clear_thinking_20251015.
• Compaction fasst zusammen. Ein separates Feature mit eigenem Beta-Header compact-2026-01-12 und der Strategie compact_20260112, Standard-Trigger bei 150.000 Token.

Die dokumentierten Defaults von clear_tool_uses_20250919 sind ein brauchbarer Startpunkt für eigene Schwellen: Auslösung bei 100.000 Input-Token, Erhalt der letzten drei Tool-Uses, optional clear_at_least als Mindestmenge zu löschender Token, exclude_tools für Werkzeuge, deren Ergebnisse nie verschwinden dürfen, und clear_tool_inputs = false. Stand August 2026 ist das Ganze weiterhin Beta, nicht GA – ein Punkt, auf den wir im Abschnitt zum Eigenbau zurückkommen.

Die drei sinnvollen Auslöser

1. Tokenschwelle. Am einfachsten zu implementieren und am leichtesten zu monitoren. Wählen Sie die Schwelle unterhalb der Modellklippe, nicht knapp unterhalb des Fensterlimits.
2. Schrittzahl. Robuster bei Werkzeugen mit stark schwankender Antwortgröße; verhindert, dass ein einzelner 40k-Token-Dump die gesamte Planung überschreibt.
3. Phasenwechsel. Der qualitativ beste Auslöser: nach Abschluss der Recherche, vor Beginn der Umsetzung. Hier ist ohnehin klar, welche Details ihren Zweck erfüllt haben.

Was eine Kompaktierung immer überleben muss, ist eine sehr kurze Liste: das Ziel im Wortlaut des Auftraggebers, die harten Constraints und die noch offenen Teilaufgaben. Alles andere ist verhandelbar.

Zur Wirkung: Anthropic nennt aus dem Beta-Launch des Context-Managements im Herbst 2025 – gemessen mit Claude Sonnet 4.5 auf einem internen Agentic-Search-Benchmark – ein Plus von 29 % für Context Editing allein und 39 % in Kombination mit einem Memory-Tool. Diese Zahlen werden häufig als frische 2026er-Messung zitiert; sie sind es nicht. Aussagekräftiger aus derselben Quelle ist ohnehin eine andere Kennzahl: In einer Evaluierung mit 100 Websuche-Turns senkte Context Editing den Tokenverbrauch um 84 % und ermöglichte Workflows, die sonst schlicht an Kontexterschöpfung gescheitert wären.

Structured Context Eviction statt Summarization

Die interessanteste Gegenposition zur Zusammenfassung stammt von Andrew Semenov und Svyatoslav Dorofeev: „Beyond Compaction: Structured Context Eviction for Long-Horizon Agents", arXiv 2606.11213 (v1 vom 1. Mai 2026). Die Arbeit benennt vier konkrete Schwächen summarisierender Compaction: unvorhersehbare Verlustigkeit, Zerstörung der Kausalstruktur, blockierende Modellkosten für die Zusammenfassung selbst – und kompressionsinduzierte Halluzination, also Fakten, die erst beim Verdichten entstehen.

Der Gegenentwurf heißt Context Window Lifecycle (CWL). Der Agent annotiert seine eigene Trajektorie als typisierte, abhängigkeitsverknüpfte Episoden. Überschreitet er das Budget, greift eine deterministische, LLM-freie Policy und verdrängt in fester Prioritätsreihenfolge: Nutzer-Turns und aktiv bearbeiteter Explorationskontext bleiben erhalten, Action-Episoden, deren Effekte bereits in der Umgebung persistiert sind, werden aggressiv abgeworfen. Wer eine Datei geschrieben hat, braucht das Tool-Protokoll des Schreibvorgangs nicht mehr – die Datei ist der Zustand.

Die harte Zahl der Arbeit: Eine einzige Agent-Session absolvierte 89 sequenzielle Aufgaben über 80 Millionen Token, ohne messbare Genauigkeitsverschlechterung gegenüber pro Aufgabe isolierten Sessions. Für agentische Systeme mit Tages- oder Wochenhorizont ist das die relevantere Eigenschaft als ein Punktgewinn auf einem Kurzbenchmark: Der aktive Kontext bleibt an einer stabilen Obergrenze, statt zu wachsen.

Governance Decay: das Audit-Risiko

Am besten belegt und für regulierte Branchen am unangenehmsten ist „Governance Decay: How Context Compaction Silently Erases Safety Constraints in Long-Horizon LLM Agents" von Shiyang Chen, arXiv 2606.22528 (v1 vom 21. Juni 2026, v2 vom 27. Juni 2026). Der Benchmark ConstraintRot bewertet Tool-Calls deterministisch über 1.323 Episoden und sieben Modellfamilien.

Zustand des Constraints im Kontext	Verstoßrate	Bedeutung für den Betrieb
Policy vollständig im Kontext	0 %	Sollzustand – kein Modellproblem
Nach Compaction, Mittel über alle Modelle	30 %	Jeder dritte Lauf verletzt eine Vorgabe
Nach Compaction, schlechtestes Einzelmodell	59 %	Modellwahl ist Teil des Risikos
Constraint überlebt die Zusammenfassung	0 %	Es liegt an der Erhaltung, nicht am Modell
Constraint fällt heraus	38 %	Direkte Kausalität nachgewiesen

Die Differenzierung in den letzten beiden Zeilen ist der eigentliche Kern: Es handelt sich nicht um ein diffuses Nachlassen der Regeltreue, sondern um einen sauber lokalisierbaren Defekt. Überlebt die Vorgabe die Verdichtung, bleibt die Verstoßrate bei null. Fällt sie heraus, springt sie auf 38 %.

Die Arbeit demonstriert zusätzlich eine „Compaction-Eviction Attack": Adversarialer Inhalt im Kontext – etwa in einem abgerufenen Dokument oder einer Tool-Antwort – bringt den zusammenfassenden Schritt dazu, eine legitime Policy wegzulassen. Optimierte Injektionen besiegten dabei jedes evaluierte Modell. Für Betreiber heißt das: Der Summarizer ist eine Angriffsfläche, nicht bloß eine Optimierung.

Die vorgeschlagene Gegenmaßnahme ist erfreulich unspektakulär und trainingsfrei: Constraint Pinning. Governance-Constraints werden in einen quarantänierten Block gelegt, der von verlustbehafteter Compaction gar nicht erst berührt wird. Damit stellte die Arbeit die Verstoßrate von 0 % wieder her. Wer einen Agenten in einem auditpflichtigen Prozess betreibt – Personalvorauswahl, Kreditvorprüfung, Instandhaltungsfreigaben – sollte diesen unverdrängbaren Block als Pflichtbestandteil der Architektur behandeln und seine Existenz in der technischen Dokumentation nachweisen können.

Tool-Result-Clearing und externes Memory

Der größte Einzelposten im Kontext eines Agenten sind selten die Anweisungen, sondern die Rückgaben der Werkzeuge: Suchergebnisse, Logfiles, Datenbankauszüge, HTML. Das Muster dagegen ist immer dasselbe – große Tool-Antworten verlassen den aktiven Kontext und werden durch eine Kurzfassung plus eine Referenz ersetzt, über die der Agent den Volltext bei Bedarf zurückholt.

Zwei Mechanikdetails entscheiden über den Erfolg. Erstens läuft Anthropics Context Editing serverseitig; der Client behält die vollständige, unveränderte History. Gelöscht wird chronologisch, ältestes zuerst, und der entfernte Inhalt wird durch Platzhaltertext ersetzt, damit das Modell überhaupt weiß, dass etwas fehlt. Zweitens – und das ist der Kostenpunkt – invalidiert Tool-Result-Clearing den gecachten Prompt-Präfix ab der Löschstelle. Genau dafür existiert clear_at_least: Es lohnt sich nur zu löschen, wenn die eingesparte Menge die verlorene Cache-Trefferquote rechtfertigt. Thinking-Block-Clearing erhält den Cache dagegen, solange Blöcke behalten werden. Wer Prompt-Caching ernsthaft nutzt, muss beide Mechanismen gemeinsam auslegen, nicht getrennt.

Addressable Recall Compaction

Die derzeit sauberste Umsetzung dieses Musters beschreibt „Addressable Recall Compaction for Long Context-Window Control in AI Agents" von Thang Dang, Yuma Ichikawa, Sakina Fatima und Koichi Shirahata, arXiv 2607.25066, eingereicht am 27. Juli 2026. ARC trennt den Archivspeicher von der Darstellung im Aktivkontext: Tool-Observations landen in einem append-only, ID-adressierbaren Log; bei der Kompaktierung werden ältere Observations im Aktivkontext durch kompakte Zitationen ersetzt. Der Agent kann jeden Inhalt per ID zurückholen – ohne das Werkzeug erneut auszuführen und ohne auf eine Ähnlichkeitssuche angewiesen zu sein, die das Falsche finden könnte.

Evaluiert wurde mit Qwen3-8B bei 16k Kontextfenster und Qwen3-32B bei 32k. Needle-in-a-Haystack: 99,40 % Exact-Answer-Accuracy gegenüber 88,12 % für die beste Baseline. LongBench-v2 Hard: 29,97 % gegenüber 28,25 %. Wichtig für die Einordnung: „Verlustfrei" bezieht sich auf die Archivierung samt adressierbarem Recall, nicht auf den Aktivkontext – dort stehen Pointer, keine Volltexte. Und die berichtete Reduktion von Serving-Zeit und HBM-Traffic ist unter dem Hardware-Kostenmodell der Autoren gerechnet, nicht auf realer Hardware gemessen.

Selbst bauen statt Vendor-API

Für Betreiber eigener Infrastruktur ist der entscheidende Punkt banal: Serverseitige Compaction- und Context-Editing-APIs der Anbieter stehen Ihnen nicht zur Verfügung, wenn das Modell auf Ihrem eigenen Rack läuft. Und selbst bei Nutzung der Vendor-API sind beide Features im August 2026 noch Beta – eine Abhängigkeit, die man in einem Produktivsystem mit Fünfjahreshorizont ungern eingeht.

Die gute Nachricht: Die drei wirksamsten Bausteine sind anbieterunabhängig und trainingsfrei implementierbar.

Verfahren	Beleg	Selbst umsetzbar?
Constraint Pinning	arXiv 2606.22528 – 0 % Verstoßrate wiederhergestellt	Ja, trainingsfrei
Context Window Lifecycle	arXiv 2606.11213 – 89 Aufgaben / 80 Mio. Token	Ja, LLM-freie Policy
Addressable Recall Compaction	arXiv 2607.25066 – 99,40 % vs. 88,12 % NIAH	Ja, Log + IDs
Vendor Context Editing / Compaction	84 % weniger Token, 100-Turn-Websuche	Nein – API-gebunden, Beta
CompactionRL	arXiv 2607.05378 – 66,8 % SWE-bench Verified	Nein – erfordert RL-Training

Die letzte Zeile verdient eine Einordnung. „CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents" (arXiv 2607.05378, 6. Juli 2026) stammt von Yujiang Li, Zhenyu Hou, Yi Jing, Jie Tang und Yuxiao Dong aus dem Zhipu-/GLM-Team und optimiert Aufgabenausführung und Summary-Generierung gemeinsam, mit Token-Level-Loss-Normalisierung und Cross-Trajectory Generalized Advantage Estimation. GLM-4.5-Air (106B-A30B) erreicht damit 66,8 % Pass@1 auf SWE-bench Verified (+7,0 Punkte) und 24,5 % auf Terminal-Bench 2.0 (+3,1); GLM-4.7-Flash (30B-A3B) kommt auf 56,0 % (+5,5) und 20,2 % (+6,8). Das Verfahren ist in der RL-Pipeline des offenen GLM-5.2 (750B-A40B) im Einsatz. Nachbauen wird das im Mittelstand niemand – der Punkt ist ein anderer: Kompaktierung ist inzwischen ein Trainingsziel und nicht mehr nur eine Laufzeitheuristik. Wer heute ein offenes Modell auswählt, sollte fragen, ob es auf lange Läufe hin trainiert wurde.

Zwei pragmatische Hebel im eigenen Stack

Kompakte Tool-Schemata. Aufgeblähte Werkzeugbeschreibungen sind stiller Dauerballast in jedem Turn. Die MCP-Spezifikation in Revision 2026-07-28 lockert mit SEP-2106 inputSchema und outputSchema auf beliebige JSON-Schema-2020-12-Keywords und ergänzt $ref-Auflösung samt Ressourcengrenzen für Kompositions-Keywords – das erlaubt, wiederkehrende Strukturen einmal zu definieren statt in jedem Tool zu wiederholen. Dieselbe Revision enthält zwei direkt kontextrelevante Punkte: Server sollen Tools aus tools/list in deterministischer Reihenfolge liefern, damit clientseitiges Caching greift und die Prompt-Cache-Trefferquote steigt, und ein neues CacheableResult-Interface mit den Pflichtfeldern ttlMs und cacheScope macht Cachefähigkeit explizit. Die Headline-Änderungen der Revision sind übrigens andere: Wegfall der Protokoll-Sessions und des Mcp-Session-Id-Headers, ein zustandsloses Protokoll ohne initialize-Handshake.

Sub-Agenten als Kontextisolation. Eine Teilaufgabe, die zwanzig Tool-Calls und 60k Token Zwischenmaterial erzeugt, gehört nicht in den Hauptkontext. Der Sub-Agent bekommt Auftrag und Constraints, arbeitet in eigenem Fenster und gibt ein Ergebnis von wenigen hundert Token zurück. Das ist Compaction durch Architektur statt durch Zusammenfassung – und es ist die Variante, die am wenigsten schiefgehen kann. Wie sich das in ganze Prozessketten übersetzt, zeigen wir unter Agentic Workflows.

Was das an GPU-Kapazität spart

Auf eigener Hardware ist Context Engineering kein Qualitätsthema allein, sondern ein Kapazitätsthema. Der KV-Cache wächst linear mit der Sequenzlänge und linear mit der Zahl gleichzeitiger Sessions – er ist bei Agentenlast typischerweise die Ressource, die zuerst ausgeht, nicht die Modellgewichte. Halbiert man den durchschnittlichen aktiven Kontext, verdoppelt man näherungsweise die Zahl paralleler Sessions auf derselben GPU. Beim Prefill kommt hinzu, dass der Attention-Anteil überproportional mit der Sequenzlänge wächst; ein halbierter Kontext spart dort tendenziell mehr als die Hälfte der Rechenzeit.

Ehrlicherweise: Keine der genannten Arbeiten nennt eine gemessene VRAM- oder GPU-Stunden-Einsparung. Belastbar sind drei Größen – 84 % weniger Token in Anthropics 100-Turn-Websuche-Evaluierung, eine stabile Obergrenze des Aktivkontexts über 80 Millionen Token bei CWL, und ARCs modellierte Reduktion von Serving-Zeit und HBM-Traffic. Wer eine Hardwareentscheidung trifft, rechnet deshalb besser mit den eigenen Tokenkurven aus dem Pilotbetrieb als mit Prozentzahlen aus Papers. Für die Auslegung selbst haben wir die Rechenwege in einem eigenen Beitrag zusammengestellt.

Zwei Nebeneffekte gehören in dieselbe Kalkulation. Erstens die Kostenseite eines hybriden Betriebs: Bei Anthropics First-Party-API kostet Claude Sonnet 5 im August 2026 3 $ pro Million Input-Token und 15 $ pro Million Output-Token (Einführungspreis 2 $/10 $ bis 31.08.2026), Cache-Reads liegen bei rund 0,1× des Input-Preises, Cache-Writes bei 1,25× (5-Minuten-TTL) beziehungsweise 2× (1-Stunden-TTL). Ein kompakter, stabiler Präfix zahlt sich also doppelt aus – weniger Token und höhere Cache-Trefferquote.

Zweitens der Datenschutz: Jede Information, die nach Erledigung ihres Zwecks aus dem Kontext verschwindet, ist eine Information, die nicht in Folge-Prompts, nicht in Zusammenfassungen und nicht in Logs weiterwandert. Datenminimierung nach Art. 5 DSGVO und Context Engineering zeigen hier in dieselbe Richtung – ein seltener Fall, in dem Compliance und Performance sich nicht widersprechen. Wenn Sie das für Ihre eigene Umgebung durchrechnen wollen: Wir bauen solche Systeme unter KI-Agenten und betreiben sie auf On-Premise-Hardware, die genau auf diese Kontextprofile ausgelegt wird.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. arXiv 2606.11213
2. arXiv 2606.22528
3. arXiv 2607.25066
4. arXiv 2607.05378
5. trychroma.com context rot
6. claude.com context management
7. modelcontextprotocol.io changelog
8. platform.claude.com context editing.md

Häufig gestellte Fragen zu Context Engineering

Löst ein größeres Kontextfenster das Problem nicht einfach?

Nein. Der Genauigkeitsabfall mit wachsender Eingabelänge ist über mehrere Modellfamilien reproduziert – auch wenn alle relevanten Informationen im Kontext stehen. Ein größeres Fenster verschiebt die Grenze, es beseitigt sie nicht.

Wann sollte ein Agent kompaktieren?

Bei einer Tokenschwelle, nach einer definierten Zahl von Schritten oder beim Phasenwechsel im Auftrag. Wichtig ist, dass Ziel, harte Constraints und offene Teilaufgaben die Kompaktierung immer überleben.

Warum ist Compaction ein Compliance-Thema?

Weil naive Zusammenfassung Sicherheits- und Compliance-Vorgaben stillschweigend aus dem Kontext entfernt. Der Agent verhält sich danach anders, ohne dass ein Fehler sichtbar wird – für auditpflichtige Prozesse ein reales Risiko.

Was bringt Context Engineering auf eigener Hardware?

Direkt weniger KV-Cache pro Session und damit mehr parallele Agenten auf derselben GPU. Wer den durchschnittlichen Kontext halbiert, verdoppelt näherungsweise die Zahl gleichzeitiger Sessions.