Best Practices: Context Engineering – Gunther Popp – AI‑Driven Development & Agentic AI

In diesem Beitrag beschäftige ich mich mit dem sogenannten “Context Engineering”, also dem Management dessen, was wir den AI-Agenten als Grundlage für ihre Arbeit mitgeben und in einer Session kontinuierlich weiterentwickeln.

Einleitung

Das Thema Context Engineering ist eine der weniger offensichtlichen Stellschrauben bei der Arbeit mit AI-Agenten. Ein Grund hierfür ist, dass die Agenten ihren Kontext mehr oder weniger automatisch verwalten. Unter dem “Kontext” versteht man hierbei die Folge von Tokens, die einem Modell zur Verarbeitung bzw. Inferenz übergeben wird.

Sobald wir eine neue Session starten, ist der Kontext durch den Starter- oder System-Prompt und die für den Agenten verfügbaren Werkzeuge schon initialisiert, wird ggf. durch einen Bootstrap-Prompt weitergeführt und schließlich durch unsere weiteren Session-Prompts und die Werkzeugaufrufe der Agenten kontinuierlich ausgebaut. Vieles hiervon läuft automatisch ab und bis auf einen kleinen Indikator dafür, wie “voll” das Kontextfenster schon ist, bekommen wir in der Regel wenig davon mit.

Trotzdem lohnt es sich, einen genaueren Blick auf die zu Grunde liegenden Mechanismen zu werfen. Denn der Kontext ist entscheidend für die Qualität der durch den Agenten erstellten Artefakte und hat erheblichen Einfluss auf die Kosten, die dadurch entstehen. Einfach den Kontext so klein wie möglich zu halten, ist allerdings auch zu einfach gedacht. So viel schon mal als Teaser vorneweg: Das Ziel ist ein Kontext, der alles Relevante enthält, nicht ein möglichst kleiner Kontext.

Entstehung des Kontexts

Wenn wir eine neue Session starten, ist der Kontext bereits teilweise befüllt. Das Coding-Tool gibt dem Modell grundlegende Anweisungen mit, üblicherweise über einen System- oder Starter-Prompt. Darin legt der Anbieter fest, wie der Agent arbeiten, Werkzeuge einsetzen und mit uns kommunizieren soll. Hinzu kommen Beschreibungen der verfügbaren Werkzeuge sowie je nach Tool weitere Informationen, etwa persönliche Vorgaben oder Beschreibungen verfügbarer Skills. Ein nicht mehr ganz aktuelles, aber trotzdem lesenswertes Beispiel für einen Codex-Starter-Prompt findet sich in der OpenAI-Entwicklerdokumentation.

Unsere eigenen Projektanweisungen ergänzen diese Grundlage. Dateien wie AGENTS.md oder CLAUDE.md werden vom Tool automatisch berücksichtigt. Danach wächst der Kontext durch unsere Prompts, die Antworten des Modells und die Ergebnisse seiner Werkzeugaufrufe: gelesene Dateien, Suchtreffer, Testausgaben und vieles mehr.

Kontextfenster

Der Kontext umfasst, wie eingangs beschrieben, alle Informationen, die dem Modell bei einer Anfrage zur Verfügung stehen. Ihr Umfang wird in Tokens gemessen. Tokens sind die Einheiten, in die Text für die Verarbeitung durch das Modell zerlegt wird, etwa ganze Wörter, Wortteile oder Satzzeichen. Das Kontextfenster begrenzt, wie viele Tokens das Modell insgesamt verarbeiten kann. Wir unterscheiden damit zwischen dem tatsächlichen Inhalt und der verfügbaren Kapazität.

Context Engineering bedeutet, die Informationen im Kontext gezielt auszuwählen, zu strukturieren und laufend zu pflegen. Und zwar innerhalb des verfügbaren Kontextfensters und im Hinblick auf die erreichbare Qualität der Ergebnisse und die dafür benötigten (und bezahlten) Tokens.

Screenshot: Belegung des Kontextfensters in Claude Code — Beispiel aus Claude Code: Belegung und Zusammensetzung des Kontextfensters in einer laufenden Session

Die Größe des Kontextfensters ist je nach Anbieter, Tool und Zugangsweg unterschiedlich. Claude Code von Anthropic mit Sonnet 5.5 oder Opus 5.5 bietet Stand Oktober 2026 beispielsweise schon in der kleinsten Abo-Stufe (“Pro”) ein Kontextfenster mit 1.000.000 Tokens. In meiner aktuellen OpenAI-Codex-Konfiguration sind es mit GPT-6 Astra hingegen “nur” 272.000 Tokens.

Ginge es nun nur um die Qualität, würden wir versuchen, das verfügbare Kontextfenster optimal auszunutzen. Wohlgemerkt, “optimal”, nicht “maximal”. Denn auch bei neueren Modellen bleibt der sinnvoll nutzbare Füllgrad des Kontextfensters ein Thema. Ein großes Kontextfenster beschreibt zunächst die technisch verarbeitbare Menge an Informationen. Wie zuverlässig das Modell diese nutzt, hängt von der Aufgabe und dem Inhalt ab. Eine allgemeine, oft zitierte Grenze von maximal 80 % Füllgrad ist nicht abgesichert. Es ist unklar, ob Erkenntnisse aus älteren Untersuchungen noch relevant sind. Ein Beispiel ist dieses Paper zum Thema “Context Rot” vom Mai 2026: Opus 4.6, GPT 5.4 und Gemini 3.1 übersahen als Sicherheitsmonitore für Coding-Agenten gefährliche Aktionen 2- bis 30-mal häufiger, wenn ihnen rund 800.000 Tokens unauffälliger Aktivität vorausgingen. Ob die im Paper diskutierten Ergebnisse auf andere Aufgaben und aktuelle Modelle übertragbar sind, bleibt offen. Eine verlässliche, allgemein anwendbare Grenze nennen die Anbieter nicht.

Komplexer wird der Sachverhalt zudem durch den zweiten Faktor neben der erzielten Qualität der Agenten: die Kosten. Im professionellen Umfeld wird häufig tokenbasiert abgerechnet. Und bei jedem Modellaufruf zählt nicht nur der aktuelle Prompt, sondern der gesamte aktive Kontext. Ein größerer Kontext erhöht daher die Kosten für den nächsten Request ans Modell. Wie stark die Kosten steigen, hängt unter anderem vom Modell, dem Tarif und der Wiederverwendung bereits verarbeiteter Kontextteile durch Prompt Caching ab. Wer entsprechende Tools zum Kostenmonitoring einsetzt, beispielsweise LiteLLM, kann dies sehr schön nachvollziehen.

Automatische Kontextverwaltung

Die Toolhersteller wissen natürlich um den Spagat, möglichst alle für die Session relevanten Informationen im Kontext zu halten und gleichzeitig die Kontextgröße im Auge zu behalten. Daher bieten gängige Coding-Tools Mechanismen zur automatischen Kontextverwaltung:

Dynamisches Nachladen von Informationen: Der Agent liest zunächst nur die für die Aufgabe relevanten Stellen aus dem Projekt. Dieses Prinzip wird auch als Just-in-Time Context bezeichnet. Progressive Disclosure überträgt es auf Anweisungen und Werkzeuge: Bei Skills stehen zunächst Name und Beschreibung bereit, die vollständigen Anweisungen erst, wenn der Skill wirklich eingesetzt wird. Auch die Beschreibungen der verfügbaren Werkzeuge eines MCP-Servers können bedarfsabhängig geladen werden. Das verhindert, dass schon der Startkontext sämtliche Detailanweisungen und Tool-Definitionen enthält.
Auslagern von Ergebnissen und Notizen: Aktuelle Coding-Tools können umfangreiche Werkzeugausgaben beispielsweise in temporäre Dateien auslagern, aus denen der Agent nur die jeweils benötigten Ausschnitte in den Kontext übernimmt. Dieses Verhalten kann man sehr schön beobachten. Es lohnt sich, mal einen Blick ins eigene /tmp-Verzeichnis zu werfen. Auf meinem Rechner finde ich dort typischerweise die Hinterlassenschaften der letzten AI-Sessions. Aufräumen gehört offensichtlich noch nicht zu den Kernkompetenzen der Agenten, aber das kann ja noch kommen. Zudem bieten manche Coding-Tools eine Memory-Funktion, mit der Agenten ausgewählte Erkenntnisse und Entscheidungen in dauerhaften Notizen speichern und später wieder einlesen können. Dies kann automatisch oder auf ausdrückliche Anweisung geschehen.
Entfernen gelesener Inhalte aus dem Kontext: Bereits eingelesene Inhalte werden ggf. wieder aus dem aktiven Kontext entfernt. Typische Kandidaten sind ältere Tool-Ausgaben, etwa Dateiinhalte oder Suchtreffer.
Kontextverdichtung: Die Context Compaction (bei automatischer Ausführung Auto Compaction) geht noch einen Schritt weiter und ersetzt Teile des Kontexts durch automatisch erstellte, gekürzte Varianten. Dabei sollen die Zielsetzung der aktuellen Session, wichtige Entscheidungen, der Arbeitsstand und offene Punkte erhalten bleiben. Dieser Prozess kann mehrere Minuten dauern und wird in den Tools auch entsprechend gekennzeichnet. Context Compaction ist aus meiner Sicht ein notwendiges Übel, das eine kontinuierliche Weiterarbeit in langen, komplexen Sessions überhaupt erst möglich macht. Klar ist aber auch, dass wir nicht sicher wissen, welche Teile des Kontexts beispielsweise als “wichtige Entscheidungen” gewertet werden und erhalten bleiben. Und was eben nicht. Meiner Erfahrung nach leidet die Qualität der Ergebnisse auch heute noch unter der Context Compaction, deshalb versuche ich, Compactions möglichst zu vermeiden. Auf diesen Punkt gehe ich unten im Abschnitt “Manuelle Kontextpflege” nochmal genauer ein.
Auslagern von Teilaufgaben: Unterstützt das Coding-Tool Subagenten, kann der Hauptagent etwa eine Recherche an einen weiteren Agenten mit eigenem Kontextfenster delegieren. Dessen gelesene Dateien, Suchtreffer und Zwischenschritte füllen dann nicht zusätzlich den Hauptkontext. Zurück kommt lediglich ein kompakter Ergebnisbericht. Claude Code nutzt beispielsweise eingebaute Subagenten zur Code-Erkundung.

Manuelle Kontextpflege

Auch wenn die Automatik uns beim Thema Context Engineering schon viel abnimmt, sollte man sich nicht vollständig darauf verlassen. Und sei es nur, weil die Motivation, die Kosten zu reduzieren, auf Herstellerseite vermutlich weniger stark ausgeprägt ist als auf Anwenderseite. Daher empfehle ich die folgenden Techniken zur manuellen Kontextpflege kennenzulernen und in die eigenen Arbeitsabläufe mit den Agenten zu integrieren:

Sessions begrenzen: Die wichtigste und einfachste Technik lautet meiner Meinung nach: Eine Aufgabe pro Session. Auf diesen Punkt bin ich indirekt schon in meinen Beiträgen über Feature-Spezifikationen und Implementierungspläne eingegangen. Statt zu versuchen, von der Spezifikation über die Planung und die Implementierung alles in eine Session zu packen, erstellen wir hierfür separate Artefakte in separaten Sessions. Jede neue Session erhält die für ihre Aufgabe relevanten Ergebnisse der vorherigen Schritte als Grundlage. Neben vielen anderen Vorteilen hält das den Kontext der jeweiligen Sessions klein und fokussiert.
Gezielte Auswahl von Tools und Skills: Es ist natürlich verlockend, in der Konfiguration des Coding-Tools möglichst viele Tools und Skills auszuwählen. Schließlich werden die eigenen Agenten dadurch “mächtiger” und bieten uns neue Möglichkeiten zur Automatisierung. Aber das alles benötigt eben auch Platz im Kontextfenster, selbst wenn zunächst nur Namen und Beschreibungen geladen werden. Im Screenshot oben belegen die MCP-Tools rund 17.000 Tokens im Kontext, weitere rund 124.000 Tokens sind als “deferred” markiert und werden erst bei Bedarf geladen. Ich versuche daher, immer nur die absolut notwendigen Tools standardmäßig zu aktivieren. Selten benutzte Tools schalte ich dann nach Bedarf dazu.
Sorgfältige Prompt-Erstellung: Jeder Prompt muss sorgfältig und fokussiert erstellt werden. Das klingt banal, ist es aber meiner Erfahrung nach überhaupt nicht. Unscharfe Prompts führen zu explorativen Lesezugriffen und Korrekturschleifen, die den Kontext unnötig füllen. Ich schreibe Prompts so, wie ich früher Quellcode erstellt habe. Auch wenn die Agenten zum Plaudern einladen, ist ein Prompt kein “Gespräch”. Es ist eine gezielte Arbeitsanweisung, eben tatsächlich eine Art neuer Quellcode.
Auto Compaction vermeiden: Die automatische Kontextverdichtung ist für mich das Signal, den Zuschnitt meiner Session zu überprüfen, siehe den ersten Punkt der Liste. Es ist nicht so, dass ich dann sofort abbreche und eine neue Session “erzwinge”. In der Regel arbeite ich dann erstmal weiter und bringe die Session zu einem sinnvollen Ende. Aber als Signal, jetzt langsam mal zu Potte zu kommen, taugt die Compaction auf jeden Fall.
Semantic Anchors erproben: Die Idee der Semantic Anchors ist es, in den Prompts etablierte Fachbegriffe wie “arc42” oder “ADR nach Nygard” zu verwenden. Die Annahme ist, dass das Modell dabei auf bereits gelerntes Wissen zurückgreift und man sich daher viele Tokens an Beschreibungen sparen kann. Es gibt hierfür sogar einen Katalog auf GitHub, in dem geeignete Begriffe gesammelt werden. Ich persönlich finde die Idee dahinter spannend und erwähne sie deshalb auch hier im Beitrag, habe aber selber noch wenig Erfahrung damit gesammelt. Der Erfolg steht und fällt damit, ob die Modelle die Fachbegriffe kennen und im beabsichtigten Sinn interpretieren.

Fazit

Mit der zunehmenden Relevanz der Kostenfrage, zumindest im professionellen Umfeld, lohnt es sich, das Thema Context Engineering explizit im eigenen Entwicklungsprozess zu verankern. Getrennte Sessions für Spezifikation, Planung, Implementierung und Reviews sind für den Anfang aus meiner Sicht die wirkungsvollste Maßnahme. Zusätzlich lohnt es sich, alle Standard-Prompts, etwa den Bootstrap-Prompt und die Projektanweisungen, regelmäßig zu kontrollieren und ggf. den Fokus zu schärfen, statt sie einfach nur “kürzer zu machen”. Zudem sollten etablierte Best Practices, wie das erwähnte Achten auf die automatische Kontextverdichtung, regelmäßig an die Teams kommuniziert werden. Wer schon einen AI-Driven-Development-Prozess mit entsprechender Dokumentation etabliert hat, hat relativ einfaches Spiel. Für alle anderen bietet sich eine erneute Gelegenheit, über die Vorteile eines solchen Prozesses im eigenen Unternehmen nachzudenken.