Erinnern Sie sich noch, als wir dachten, beim Bau von KI-Anwendungen gehe es nur um clevere Prompts? Das wirkt heute fast rührend. Während KI-Projekte in Unternehmen wachsen und Agenten immer komplexere Aufgaben übernehmen, ist aus der Praxis eine neue Disziplin entstanden: Context Engineering. Es geht längst nicht mehr nur darum, was Sie einer KI sagen. Es geht darum, eine ganze Symphonie von Informationen zu dirigieren, die durch begrenzte Rechenfenster fließt.
Der RAM von KI-Systemen
Andrej Karpathy, früher KI-Chef bei Tesla und Forscher bei OpenAI, bringt es auf den Punkt: LLMs sind wie eine neue Art von Betriebssystem, in dem das Modell die CPU ist und sein Kontextfenster der RAM. So wie die Leistung Ihres Computers davon abhängt, was gerade im Speicher liegt, hängt die Wirksamkeit eines KI-Agenten davon ab, welche Informationen in jedem Moment sein Kontextfenster füllen.
Das ist keine akademische Spielerei. Shopify-CEO Tobi Lütke nennt Context Engineering eine „Kernkompetenz“, und Teams bei Anthropic berichten, dass Agenten routinemäßig Unterhaltungen über Hunderte von Gesprächsrunden führen. Diesen Informationsfluss zu steuern ist, wie Cognition es formuliert, „praktisch die Aufgabe Nummer 1 von Ingenieuren, die KI-Agenten bauen“.
Mehr als ein ChatGPT-Wrapper
Der Begriff „ChatGPT-Wrapper“ ist abgenutzt und, ganz offen gesagt, falsch. Moderne KI-Anwendungen steuern komplexe Abläufe, bei denen klassischen Softwarearchitekten schwindlig würde. Nehmen wir an, Sie bitten einen KI-Agenten, Ihr Backend zu deployen:
Zuerst braucht er Aufgabenbeschreibungen und Deployment-Anweisungen. Dann holt er sich über RAG (Retrieval Augmented Generation) Informationen zum Repository. Er sieht sich frühere Deployment-Logs an, prüft den aktuellen Systemzustand, geht die Fehlerhistorie durch und behält den Gesprächskontext im Blick. Und das alles, während er innerhalb der Token-Limits bleiben muss und nicht an Leistung verlieren darf.
Zu wenig Kontext, und dem Agenten fehlen entscheidende Informationen. Zu viel, und die Kosten explodieren, die Latenz steigt und die Leistung wird paradoxerweise schlechter. Drew Breunig hat mehrere Fehlerarten benannt: Context Poisoning (Halluzinationen verunreinigen den Arbeitsbereich), Context Distraction (irrelevante Informationen überfordern das Modell) und Context Clash (verschiedene Informationen widersprechen einander).
Die vier Säulen des Context Engineering
Wer Produktivsysteme von Unternehmen wie Anthropic und HuggingFace sowie verschiedene Code-Assistenten untersucht, stößt auf vier zentrale Muster:
1. Write Context: Externe Gedächtnissysteme
So wie Menschen Notizbücher benutzen, arbeiten moderne Agenten mit „Scratchpads“: externem Speicher, der Informationen außerhalb des Kontextfensters aufbewahrt. Das Multi-Agenten-Recherchesystem von Anthropic speichert seine Planung ausdrücklich im Gedächtnis, weil es weiß, dass bei mehr als 200.000 Token gekürzt wird.
Das sind nicht bloß flüchtige Notizen. Produkte wie ChatGPT, Cursor und Windsurf haben Langzeitgedächtnisse eingebaut, die Erkenntnisse über Sitzungen hinweg zusammenfassen und speichern. Die Schwierigkeit: Diese Erinnerungen sollen künftige Interaktionen verbessern und nicht kapern. Simon Willison hat dazu ein aufschlussreiches Beispiel geteilt: ChatGPT baute seinen gespeicherten Standort unerwartet in eine Anfrage zur Bildgenerierung ein. Das Abrufen von Erinnerungen kann also auch erfahrene Nutzer überraschen.
2. Select Context: Strategisches Abrufen von Informationen
Externes Gedächtnis bringt nichts ohne intelligenten Abruf. Coding-Agenten wie Claude Code nutzen eigene Dateien (CLAUDE.md) für dauerhafte Anweisungen, Cursor und Windsurf setzen auf Rules-Dateien. Sobald es über einfache Dateisysteme hinausgeht, wird es allerdings anspruchsvoll.
Moderne Systeme wählen relevante Erinnerungen über Embedding-Suche und Wissensgraphen aus. Einige besonders fortgeschrittene Implementierungen wenden RAG sogar auf die Tool-Beschreibungen selbst an und verbessern so die Treffsicherheit bei der Tool-Auswahl um den Faktor 3. Besonders aufschlussreich ist der Ansatz von Windsurf: Das Team kombiniert AST-Parsing, semantisches Chunking, grep/Dateisuche, Wissensgraphen und Re-Ranking-Algorithmen, weil einfache Embedding-Suche versagt, sobald Codebasen wachsen.
3. Compress Context: Informationen verdichten
Erreicht Claude Code 95 Prozent der Kontextkapazität, fasst es automatisch die gesamte bisherige Interaktion zwischen Nutzer und Agent zusammen. Diese „Auto-Compact“-Funktion ist nur eine von vielen Kompressionsstrategien. Rekursive Zusammenfassung, hierarchische Kompression und gezieltes Kürzen verfolgen alle dasselbe Ziel: das Wesentliche behalten und Token loswerden.
Cognition geht noch weiter und setzt per Fine-Tuning angepasste Modelle ein, die speziell an den Übergängen zwischen Agenten zusammenfassen. Die Schwierigkeit besteht darin, kritische Details zu bewahren und trotzdem spürbar zu komprimieren, eine Balance, die oft domänenspezifische Lösungen verlangt.
4. Isolate Context: Teile und herrsche
Das architektonisch vielleicht interessanteste Muster ist die Kontextisolation durch Multi-Agenten-Systeme. Die Bibliothek Swarm von OpenAI wirbt ausdrücklich für „Separation of Concerns“: Spezialisierte Agenten übernehmen Teilaufgaben, jeder mit eigenem Kontextfenster und eigenen Tools.
Die Forschung von Anthropic zeigt, dass das mehr ist als organisatorische Eleganz: Multi-Agenten-Systeme mit isolierten Kontexten schnitten bei komplexen Aufgaben besser ab als monolithische Agenten. Jeder Subagent kann sein ganzes Kontextfenster einem klar umrissenen Problem widmen und parallel arbeiten, ohne dass sich die Kontexte in die Quere kommen.
Der CodeAgent von HuggingFace isoliert anders: Statt bei Tool-Aufrufen JSON zurückzugeben, erzeugt er Code und führt ihn in Sandbox-Umgebungen aus. So bleiben Token-intensive Objekte (Bilder, Audiodateien, große Datensätze) aus dem Kontext des LLM heraus, während der programmatische Zugriff erhalten bleibt.
Die verborgene Infrastrukturschicht
Context Engineering ist vor allem deshalb schwierig, weil seine Komplexität unsichtbar bleibt. Nutzer sehen einen hilfreichen KI-Assistenten, Ingenieure ein empfindliches Zusammenspiel aus Informationsflüssen, Zustandsverwaltung und Rechenbeschränkungen. Wie Karpathy anmerkt, ist Context Engineering nur ein Teil einer entstehenden „dicken Schicht nichttrivialer Software“, zu der auch gehören:
- Zerlegung des Kontrollflusses
- Dynamisches Routing von Fähigkeiten
- Schleifen aus Generierung und Verifikation
- Parallelisierung und Prefetching
- Sicherheit und Guardrails
- Evaluierungs-Frameworks
Diese Infrastruktur arbeitet wie die Speicherverwaltung eines modernen Betriebssystems: Sie schiebt ständig um, priorisiert und optimiert, welche Informationen die Aufmerksamkeit der KI bekommen.
Wie geht es weiter?
Context Engineering verändert grundlegend, wie wir über KI-Anwendungen nachdenken. Wir bewegen uns vom Formulieren von Prompts zur Systemarchitektur, von Einzelanfragen zu dauerhaften Workflows, von zustandslosen Funktionen zu zustandsbehafteten Agenten mit reichhaltigen Gedächtnissystemen.
Die Schwierigkeiten sind real: Die Token-Ökonomie erzwingt harte Entscheidungen, Retrieval-Systeme können unerwünschte Informationen zutage fördern, und Kompression kann kritische Details kosten. Das Potenzial ist trotzdem gewaltig. Wenn Modelle größere Kontextfenster und besseres logisches Denken bekommen, entscheidet Context Engineering darüber, ob wir KI-Assistenten bauen oder echte KI-Kollegen.
Wenn das nächste Mal jemand eine KI-Anwendung als „nur einen ChatGPT-Wrapper“ abtut, denken Sie an die verborgene Komplexität darunter. Wie die Speicherverwaltung Ihres Betriebssystems macht Context Engineering seine Arbeit am besten, wenn Sie nie darüber nachdenken müssen. Der Weg dahin gehört aber zum Anspruchsvollsten, was moderne Softwareentwicklung zu bieten hat.
Wir schreiben nicht mehr nur Prompts. Wir bauen die kognitive Infrastruktur für eine neue Klasse digitaler Arbeitskräfte. Und das ändert alles.
Aus dem Englischen übersetzt: zum Originalbeitrag