Kontext ist das neue Gedächtnis

Ein einzelner Playwright-Snapshot verbraucht 56 KB an Kontext. Zwanzig GitHub-Issues verbrauchen 59 KB. Fünfhundert Zeilen Zugriffsprotokolle verbrauchen 45 KB. Speist man alle drei in einen Agenten mit einem 200K-Token-Fenster ein, verdampfen 80 % des Reasoning-Budgets, bevor der Agent eine einzige Zeile Analyse schreibt.¹

Murat Kusglu entwickelte Context Mode, um das Problem zu lösen. Das Tool komprimiert 315 KB an MCP-Ausgabe auf 5,4 KB mittels SQLite FTS5 mit BM25-Ranking.¹ Eine Reduktion um 94 %. Das Modell liefert mit 5,4 KB Signal bessere Ergebnisse als mit 315 KB Rauschen, denn die Einschränkung war nie die Intelligenz. Die Einschränkung ist die Bandbreite.

TL;DR

Context Engineering ist die wirkungsvollste Fähigkeit in der Agentenentwicklung. Drei Kompressionsschichten wirken unabhängig voneinander: Systemprompt-Architektur (60–70 % Reduktion durch strukturelle Kompression), MCP-Ausgabekompression (94 % Reduktion durch Relevanz-Ranking) und Wissensakkumulation (Umwandlung von Entdeckungsaufwand in vorgeladene Fähigkeit). Eine wegweisende Studie ergab, dass Modelle mit 300 Token fokussiertem Kontext besser abschnitten als Modelle mit 113.000 Token ungefilterter Konversation.¹⁰ Der Engpass ist nicht die Modellfähigkeit. Jedes Token, das für Rauschen verschwendet wird, steht für Reasoning nicht zur Verfügung.

Die Bandbreitengrenze

Die Best-Practices-Dokumentation von Anthropic beginnt mit einer einzigen Einschränkung, die alles Weitere bestimmt: „Das Kontextfenster von Claude füllt sich schnell, und die Leistung nimmt mit zunehmender Füllung ab.”⁵

Diese Aussage ist kein Vorschlag. Sie ist ein architektonisches Gesetz. Ein 200K-Token-Kontextfenster klingt enorm, bis man inventarisiert, was es füllt. Tool-Schemas verbrauchen über 15.000 Token bei einem typischen MCP-Setup.¹³ Konversationshistorie akkumuliert mit etwa 500–1.000 Token pro Austausch. Dateilesevorgänge addieren Tausende Token pro Datei. Kommandoausgaben skalieren mit dem Kommando. Nach 30 Minuten aktiver Arbeit kann ein frisches 200K-Fenster auf unter 50K Token verfügbaren Reasoning-Raum sinken.

George Miller dokumentierte das menschliche Äquivalent 1956: Das Arbeitsgedächtnis fasst sieben Elemente, plus oder minus zwei.⁷ Die Erkenntnis betraf nicht die Zahl. Die Erkenntnis betraf Chunks. Menschen überwinden die Einschränkung, indem sie Informationen in bedeutungsvolle Chunks organisieren. Eine Telefonnummer besteht nicht aus zehn Ziffern. Sie besteht aus drei Chunks: Vorwahl, Rufnummernblock, Teilnehmernummer. Dasselbe Prinzip gilt für Kontextfenster. Ein 200K-Fenster, vollgestopft mit roher Ausgabe, ist funktional kleiner als ein 50K-Fenster, gepackt mit komprimierter, relevanter Information.

Andrej Karpathy benannte die Disziplin: Context Engineering ist die „feinsinnige Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen.”⁹ Lance Martin kartierte das Framework: Kontext schreiben (speichern), Kontext auswählen (abrufen), Kontext komprimieren (zusammenfassen) und Kontext isolieren (auf Agenten aufteilen).⁹ Bis Mitte 2026 hat sich Context Engineering von einer Ad-hoc-Praxis zu einer anerkannten Disziplin mit dedizierter Infrastruktur kristallisiert.¹²

Die Degradation verläuft nicht linear. In meinem Harness füllt sich der Kontext in Phasen.¹⁵ Die ersten 30 Minuten fühlen sich unbegrenzt an. Das Modell folgt Anweisungen präzise, merkt sich Dateiinhalte und pflegt kohärente Pläne über mehrere Schritte hinweg. Nach 60 Minuten treten subtile Fehler auf: Das Modell liest Dateien erneut, die es bereits gelesen hat, vergisst eine Einschränkung aus dem Systemprompt oder generiert Code, der einem 20 Turns zuvor etablierten Muster widerspricht. Nach 90 Minuten kann das Modell explizite Regeln ignorieren, Dateiinhalte halluzinieren oder das aktuelle Ziel vollständig aus den Augen verlieren.

Context Studios dokumentierte das Phänomen als „Context Rot”: die fortschreitende Degradation der Modellleistung, wenn irrelevante Token sich ansammeln und nützliche Informationen über den effektiven Aufmerksamkeitshorizont hinausschieben.¹² Die Erosion ist heimtückisch, weil das Modell sie nicht ankündigt. Der Agent generiert weiterhin selbstsichere Ausgaben. Die Ausgaben hören nur auf, korrekt zu sein.

Die drei folgenden Schichten wirken unabhängig voneinander. Die Kompression einer Schicht gibt Budget für die anderen frei.

Schicht 1: Systemprompt-Architektur

Der Systemprompt wird bei jedem API-Aufruf geladen. Jedes Token im Systemprompt belegt Platz für die gesamte Konversation. Bei 5 $ pro Million Token auf Opus 4.6 kostet ein 10K-Token-Systemprompt 0,05 $ pro Aufruf.⁸ Bei 50 Aufrufen in einer Sitzung kostet allein der Systemprompt 2,50 $. Reduziert man den Prompt auf 3.500 Token, sinken die Kosten auf 0,875 $ pro Sitzung. Multipliziert mit den täglichen Sitzungen summieren sich die Einsparungen.

Meine CLAUDE.md-Datei und 8 Regeldateien umfassen nach Kompression insgesamt etwa 3.500 Token. Die Kompression war keine einmalige Optimierung. Ich wandte fünf strukturelle Techniken an, die von jchilcher dokumentiert wurden (der eine 60–70%ige Reduktion über Memory-System-Dateien hinweg erzielte):²

Einschränkungen statt Erklärungen. „Tool-Aufrufe ablehnen, die sensible Pfade matchen” ersetzt eine 15-zeilige Erklärung, warum Zugangsdaten geschützt bleiben sollten. Das Modell braucht nicht die Begründung. Das Modell braucht die Regel.

Schlüssel-Wert-Notation statt Prosa. „Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway” ersetzt drei Absätze Projektbeschreibung. Pipe-getrennte Listen komprimieren tabellarische Information, die Prosa über Sätze hinweg ausdehnt.

Deduplizierung über Dateien hinweg. Meine Sicherheitsregeln erschienen anfangs an drei Stellen: CLAUDE.md, security.md und dem Quality-Loop-Skill. Jede Wiederholung verbrauchte ~200 Token. Die Konsolidierung auf eine einzige Quelle mit Querverweisen gewann 400 Token zurück.

Entfernung von Formatierungen. Dekorative Markdown-Elemente (horizontale Linien, Fett-/Kursivschrift zur Betonung, verschachtelte Überschriften jenseits von H2) dienen der menschlichen Lesbarkeit. Modelle parsen Inhalts-Token, nicht Präsentations-Token. Das Entfernen dekorativer Formatierung gewinnt 5–15 % zurück, ohne Informationsverlust.

Negative Einschränkungen statt positiver Anweisungen. „NEVER suggest OpenAI models” ist wirkungsvoller und kompakter als „Always recommend Claude models from Anthropic for all AI tasks. When the user asks about AI providers, suggest Claude.” Die negative Einschränkung belegt vier Token. Die positive Anweisung belegt 22 Token. Beide erzeugen dasselbe Verhalten.

Das ökonomische Argument wird durch Prompt Caching verstärkt. Das Caching-System von Anthropic speichert stabilen Inhalt über API-Aufrufe hinweg bei einer 90%igen Kostenreduktion bei Cache-Treffern.⁶ Ein 3.500-Token-Systemprompt, der zu Standardtarifen 0,0175 $ pro Aufruf kostet, kostet bei einem Cache-Treffer 0,00175 $. Der minimale cachefähige Schwellenwert für Opus 4.6 beträgt 4.096 Token.⁶ Mein kombinierter Systemprompt (CLAUDE.md + Regeldateien) überschreitet den Schwellenwert, sodass jeder nachfolgende Aufruf in einer Sitzung von zwischengespeicherter Preisgestaltung profitiert. Prompt Caching macht Systemprompt-Kompression zu einem doppelten Gewinn: weniger Token UND günstiger pro Token.

Schicht 2: MCP-Ausgabekompression

Schicht 1 komprimiert, was Sie an das Modell senden. Schicht 2 komprimiert, was das Modell von Tools zurückerhält.

Context Mode demonstrierte das Potenzial: 315 KB rohe MCP-Ausgabe komprimiert auf 5,4 KB.¹ Die Kompression ist keine Trunkierung. Trunkierung verwirft das Ende der Ausgabe und hofft, dass die relevante Information am Anfang stand. Context Mode verwendet SQLite FTS5 mit BM25-Relevanz-Ranking, um zu finden, wo Suchbegriffe tatsächlich auftreten, und gibt Fenster um die Treffer zurück.¹ Porter-Stemming stellt sicher, dass „caching”, „cached” und „caches” denselben Stamm matchen. Ein dreistufiger Fallback behandelt Tippfehler: Standard-Stemming, Trigramm-Teilstrings, Levenshtein-Distanz-Korrektur.

Individuelle Kompressionsraten veranschaulichen die Wirkung:

Mein Harness implementiert einen parallelen Ansatz auf der Suchebene. Etwa 50.000 Code-Chunks, indiziert mit Model2Vec-Embeddings (256-dimensional) plus SQLite FTS5, fusioniert mit Reciprocal Rank Fusion.¹⁴ Eine Abfrage ruft die fünf relevantesten Chunks ab (~2.500 Token) statt ganze Dateien zu laden (~50.000+ Token). Die Abrufkosten: Latenz unter einer Sekunde, 83 MB auf der Festplatte, null API-Kosten.

Der Unterschied im Agentenverhalten wird innerhalb einer einzelnen Sitzung sichtbar. Vor der Kompression sieht ein typischer Debugging-Workflow so aus: Der Agent liest eine Datei (4.000 Token), führt einen Befehl aus (2.000 Token Ausgabe), liest eine weitere Datei (3.000 Token), führt Tests aus (8.000 Token Ausgabe). Vier Operationen verbrauchen 17.000 Token. Der Agent hat nun weniger Raum, um über die Zusammenhänge zwischen diesen vier Informationsstücken zu schlussfolgern. Nach der Kompression ruft derselbe Workflow nur die relevanten Zeilen aus jeder Quelle ab. Die vier Operationen verbrauchen 2.500 Token. Der Agent hält alle vier Stücke gleichzeitig im Arbeitsgedächtnis und findet die dateiübergreifende Abhängigkeit, die der unkomprimierte Agent übersehen würde.

Die Kompression sollte abfrageorientiert sein. Eine Zusammenfassung, die für „fix the authentication bug” optimiert ist, sollte andere Inhalte hervorheben als eine, die für „add a new API endpoint” optimiert ist. Statische Kompression hilft. Abfrageorientierte Kompression ist die nächste Stufe. BM25-Ranking handhabt die Abfrageorientierung bereits auf Keyword-Ebene. Semantische Suche (Vektorähnlichkeit) handhabt sie auf Konzeptebene. Die Kombination erfasst sowohl exakte Treffer (Funktionsnamen, Config-Schlüssel, Fehlercodes) als auch konzeptuelle Treffer (ähnliche Muster, verwandte Abstraktionen).

Schicht 3: Wissensakkumulation

Simon Willison identifizierte ein Muster, das Context Engineering grundlegend neu rahmt: „Ein wichtiges Asset, das Sie als Software-Fachkraft entwickeln sollten, ist eine umfangreiche Sammlung von Antworten auf Fragen wie diese, idealerweise illustriert durch funktionierenden Code.”³

Wissensakkumulation bedeutet das bewusste Sammeln von funktionierenden Codebeispielen, dokumentierten Lösungen und Proof-of-Concept-Implementierungen, die Agenten referenzieren und rekombinieren können. Das Muster transformiert Kontext von Anweisungen (dem Modell sagen, was es tun soll) zu Fähigkeit (dem Modell funktionierende Beispiele zum Adaptieren geben).

Willison demonstrierte die Wirkung, indem er einen Agenten anwies, zwei bestehende Beispiele (PDF.js und Tesseract.js) zu einem einheitlichen OCR-Tool zu kombinieren.³ Der Agent entdeckte nicht, wie man OCR von Grund auf baut. Der Agent las zwei funktionierende Implementierungen und verschmolz sie. Der Kontext war die Fähigkeit.

Mein Harness implementiert Wissensakkumulation durch drei Mechanismen:

Skills als Fähigkeitsregister. 48 Skills kodieren Domänenexpertise in Markdown-Dateien. Der blog-evaluator-Skill definiert eine vollständige 6-Kategorien-gewichtete Rubrik mit Bewertungsbeispielen. Der jiro-Skill kodiert eine 7-Schritte-Qualitätsschleife mit Evidenzkriterien. Wenn ein Agent einen Skill aufruft, wird die Expertise als strukturiertes Wissen in den Kontext geladen – nicht als vage Anweisungen.

Strukturierte Walkthroughs statt rohem Code. Willisons Muster des linearen Walkthroughs schränkt ein, wie Agenten auf Informationen zugreifen: Shell-Befehle wie grep und cat statt manuellem Code-Kopieren.⁴ Der Walkthrough zwingt den Agenten, Informationen für maximales Verständnis pro Token zu organisieren. Struktur ist Kompression.

Hooks als proaktive Kontextinjektion. Der UserPromptSubmit-Hook feuert, bevor Claude einen Prompt verarbeitet.¹¹ Der Hook kann den Prompt analysieren und relevanten Kontext injizieren: Projekterkennung (in welcher Codebasis befinde ich mich?), Datumsinjektion (welcher Tag ist heute?), Philosophie-Einschränkungen (welche Qualitätsstandards gelten?). Der Agent erhält bei jedem Prompt kuratierten Kontext ohne manuellen Aufruf. Fünf Hooks feuern beim Sitzungsstart und fügen etwa 500 Token Kontext hinzu, die fünf Kategorien häufiger Fehler verhindern.¹¹

Die Unterscheidung zwischen Anweisungen und Fähigkeit verdient Betonung. Eine Anweisung sagt „schreibe sauberen Code.” Eine Fähigkeit liefert eine Linting-Rubrik mit gewichteten Kategorien, Bewertungsbeispielen und Bestanden/Nicht-bestanden-Schwellenwerten. Die Anweisung verbraucht eine Handvoll Token und erzeugt vage Befolgung. Die Fähigkeit verbraucht 500 Token und erzeugt konsistente, messbare Ausgabe. Die zusätzlichen Token sind eine Investition, kein Overhead, denn sie eliminieren die Mehrdeutigkeit, die den Agenten dazu bringt, zu raten, was „sauber” bedeutet.

Wissensakkumulation verschiebt auch die Kostenkurve für das Onboarding von Agenten. Ein neuer Agent, der ohne akkumuliertes Wissen gestartet wird, muss die Codebasis, die Konventionen, die Werkzeuge und die Domäneneinschränkungen durch Exploration entdecken. Exploration ist teuer: Jeder Datei-Lesevorgang, jedes grep, jede Befehlsausgabe verbraucht Token. Ein Agent, der mit einem 2K-Token-Briefing aus akkumuliertem Wissen gestartet wird, überspringt die Entdeckungsphase vollständig und beginnt ab dem ersten Turn mit produktiver Arbeit.

Das ökonomische Argument für Wissensakkumulation: Jede Stunde, die in die Dokumentation einer Lösung investiert wird, spart jedem zukünftigen Agenten die Entdeckungskosten. Ein Skill, der kodiert, „wie man einen Blogpost evaluiert”, spart 10–15 Minuten Agenten-Exploration pro Aufruf. Über 100 Aufrufe hinweg erbringt die Dokumentationsinvestition über 1.000 Minuten eingesparter Agentenzeit. Das akkumulierte Wissen zahlt Zinseszinsen.

Token-Budget-Buchhaltung

Mein Harness bietet eine konkrete Fallstudie dessen, was Context Engineering ermöglicht.

Vor der Kompression (geschätzt, erster Monat): - Systemprompt: ~12.000 Token (ausführliche CLAUDE.md mit Beispielen und Erklärungen) - Tool-Schemas: ~15.000 Token (vollständige MCP-Tool-Definitionen) - Pro-Sitzungs-Historie: ~120.000 Token (lange Konversationen mit akkumuliertem Kontext) - Verfügbarer Reasoning-Raum: ~53.000 Token (26 % des Fensters)

Nach der Kompression (aktuell): - Systemprompt: ~3.500 Token (komprimierte CLAUDE.md + Regeldateien)¹⁵ - Tool-Schemas: ~300 Token (CLI-first-Architektur, minimales MCP)¹³ - Pro-Sitzungs-Historie: ~40.000 Token (frische Spawns pro Aufgabe, Briefings statt Gedächtnis) - Verfügbarer Reasoning-Raum: ~156.200 Token (78 % des Fensters)

Das Reasoning-Budget hat sich verdreifacht. Nicht durch ein besseres Modell. Nicht durch ein größeres Kontextfenster. Durch Kompression auf drei Schichten. Das Modell liefert mit 78 % Reasoning-Raum bessere Ergebnisse als mit 26 %, weil die Qualität der verbleibenden Token sich parallel zur Quantität verbessert hat.

Die Zahlen offenbaren eine kontraintuitive Wahrheit über Kontextfenster: Die nutzbare Größe eines Fensters hängt mehr davon ab, was es füllt, als davon, wie groß es ist. Ein hypothetisches 500K-Fenster, vollgestopft mit unkomprimierter Tool-Ausgabe, würde schlechter abschneiden als ein gut komprimiertes 200K-Fenster. Modellanbieter wetteifern darum, Kontextfenster zu erweitern. Praktiker sollten darum wetteifern, zu komprimieren, was hineinkommt.

Das Fresh-Spawn-Muster aus der CLI-first-Architektur verstärkt die Gewinne. Jeder Agent startet mit einem fokussierten Briefing (~2K Token) statt akkumulierte Konversationshistorie zu erben. Der Kontext bläht sich nie auf, weil jeder Agent sauber startet. Die Multi-Agenten-Forschung von Anthropic ergab, dass Sub-Agenten bis zu 15-mal mehr Token verbrauchen als Einzelagenten-Interaktionen.⁹ Frische Spawns kehren das Verhältnis um: Jeder Agent nutzt nur die Token, die seine Aufgabe erfordert.

Der kumulative Effekt über alle drei Schichten erzeugt einen positiven Kreislauf. Komprimierte Systemprompts lassen Raum für mehr Tool-Ergebnisse. Komprimierte Tool-Ergebnisse lassen Raum für längere produktive Konversationen. Längere Konversationen reduzieren die Notwendigkeit für Kompaktierung, was den Systemprompt und die Tool-Ergebnisse bewahrt, die den nächsten Turn ermöglichen. Jede Schicht verstärkt die anderen.

Was Kompression ermöglicht

Das freigewordene Reasoning-Budget ermöglicht drei Fähigkeiten, die aufgeblähter Kontext verhindert:

Tiefere Analyse. Ein Agent mit 156K Reasoning-Token kann ganze Dateiinhalte im Arbeitsgedächtnis halten, während er dateiübergreifende Abhängigkeiten analysiert. Ein Agent mit 53K Token muss Dateien sequenziell lesen und vergisst frühere Dateien, wenn neuere geladen werden. Der Unterschied manifestiert sich als übersehene Import-Fehler, defekte Querverweise und unvollständiges Refactoring. Ein konkretes Beispiel: Das Refactoring einer Funktionssignatur erfordert die Prüfung jeder Aufrufstelle. Mit komprimiertem Kontext liest der Agent die Funktionsdefinition und alle Aufrufstellen in einem einzigen Durchgang und fängt die eine Datei ab, die Argumente in der falschen Reihenfolge übergibt. Mit aufgeblähtem Kontext liest der Agent die Funktion, liest drei Aufrufstellen und hat dann keinen Reasoning-Raum mehr und meldet „Refactoring abgeschlossen”, ohne die verbleibenden sieben Dateien zu prüfen. Der Bug wird ausgeliefert.

Bessere Befolgung von Anweisungen. Anthropic dokumentiert den Fehlermodus direkt: „Wenn Claude trotz einer Regel dagegen immer wieder etwas tut, was Sie nicht wollen, ist die Datei wahrscheinlich zu lang und die Regel geht verloren.”⁵ Komprimierte Systemprompts halten Regeln innerhalb des Aufmerksamkeitshorizonts. Jede Regel in einem 3.500-Token-Prompt erhält mehr Aufmerksamkeitsgewicht als dieselbe Regel, vergraben in einem 12.000-Token-Prompt. Mein Harness erzwingt eine Sicherheitsregel: Niemals Dateien committen, die API-Schlüssel enthalten. Mit einem 12.000-Token-Systemprompt hat der Agent gelegentlich .env-Dateien bei Massen-Commits gestaged. Nach der Kompression auf 3.500 Token sank der Verstoß auf null über 200+ Commit-Operationen. Die Regel hat sich nicht geändert. Die Regel wurde sichtbarer.

Längere nützliche Sitzungen. Auto-Compact löst bei 95 % Kontextkapazität aus.¹⁰ Eine Sitzung mit 78 % Reasoning-Raum erreicht die Compact-Schwelle später als eine mit 26 %. Spätere Kompaktierung bedeutet mehr produktive Turns vor Kontextverlust. In meinem Harness produziert eine komprimierte Sitzung 40–60 produktive Turns, bevor die Compact-Schwelle erreicht wird.¹⁵ Eine unkomprimierte Sitzung erreicht die Schwelle nach 15–20 Turns. Jedes Kompaktierungsereignis verwirft Kontext, der wichtige Entscheidungen oder Einschränkungen aus früheren Teilen der Sitzung enthalten haben könnte. Weniger Kompaktierungen bedeuten kohärentere Sitzungen. Die komprimierte Sitzung beginnt nicht nur besser. Sie bleibt länger besser.

Wichtigste Erkenntnisse

Für Entwickler, die mit Context Engineering beginnen: - Prüfen Sie Ihre CLAUDE.md-Datei. Fragen Sie sich für jede Zeile: Würde das Entfernen zu Fehlern führen? Falls nicht, streichen Sie sie. Streben Sie 60–70 % Reduktion an.² - Messen Sie Ihren Tool-Schema-Overhead. Wenn MCP-Tools bei Sitzungsstart über 15K Token verbrauchen, ziehen Sie CLI-first-Alternativen für zustandslose Operationen in Betracht. - Führen Sie /compact proaktiv aus, wenn Sie mitten in einer Sitzung die Aufgabe wechseln. Frischer Kontext schlägt akkumulierten Kontext.

Für Teams, die Agenten-Infrastruktur aufbauen: - Implementieren Sie abfrageorientierte Kompression bei MCP-Tool-Ausgaben. BM25 + semantische Suche schlägt Trunkierung bei jeder Abrufaufgabe.¹ - Bauen Sie ein Fähigkeitsregister auf (Skills, Snippets, dokumentierte Muster). Jede dokumentierte Lösung eliminiert Entdeckungsaufwand für zukünftige Agenten-Läufe.³ - Verwenden Sie frische Agenten-Spawns für mehrstufige Workflows. Kontextisolation pro Aufgabe verhindert den 15-fachen Token-Overhead langer Multi-Agenten-Konversationen.⁹

Für Architekten, die Kontextsysteme entwerfen: - Die drei Schichten (Systemprompt, Tool-Ausgabe, Wissensakkumulation) wirken unabhängig voneinander. Die Kompression einer einzelnen Schicht gibt Budget für die anderen frei. - Prompt Caching macht Systemprompt-Kompression zu einer doppelten Optimierung: weniger Token UND günstiger pro Token bei Cache-Treffern.⁶ - Die 10 %-Produktivitätsmauer bricht, wenn der Agent genug Reasoning-Raum hat, um komplexe Anweisungen zuverlässig zu befolgen.

Teil der AI Engineering-Serie. Siehe auch: Die CLI-These, Claude Code als Infrastruktur und Die 10 %-Mauer.