Context Engineering: So bleiben KI-Agenten beim Auftrag

Wenn ein Agent in der Demo überzeugt, bei echten Aufgaben aber vom Auftrag abkommt, lohnt sich zuerst ein Blick auf die Informationen, die das Modell tatsächlich erreichen. Zusätzliche Anweisungen sind nicht immer die Lösung. Context Engineering steuert bei jedem Schritt 5 Eingaben: Anweisungen, Tools, abgerufene Fakten, gespeichertes Wissen und den bisherigen Verlauf. Ziel ist, genügend Belege für die nächste richtige Handlung bereitzustellen und dabei weniger irrelevantes Material mitzuschleppen.

Was ist Context Engineering?

Context Engineering legt fest, was ein Modell sieht, wenn es seine nächste Entscheidung trifft. Dazu gehören die formulierte Anweisung, die verfügbaren Tools, die von ihnen gelieferten Belege, das geladene Wissen und der beibehaltene Gesprächsverlauf.

Das Kontextfenster ist der Arbeitsbereich des Modells für eine Anfrage. Ein Token ist eine Einheit aus Text oder anderen Inhalten, die das Modell verarbeitet. Ein irgendwo im System gespeichertes Dokument ist zunächst nur eine verfügbare Informationsquelle. Zum aktiven Kontext wird sein Inhalt erst, wenn die Anwendung oder der Agent ihn lädt.

Dieser Unterschied erklärt ein bekanntes Problem im Produktivbetrieb: Ein Agent kann Zugriff auf die richtige Richtlinie haben und trotzdem auf Grundlage eines alten Gesprächs antworten, weil die aktuelle Richtlinie im Moment der Entscheidung gar nicht beim Modell angekommen ist. Umgekehrt kann das Laden sämtlicher Richtlinien sachfremde Ausnahmen und veraltete Fassungen in den Kontext bringen.

In seinem Engineering-Beitrag vom 29. September 2025 beschreibt Anthropic diese Arbeit als „das Zusammenstellen und Pflegen der optimalen Menge an Tokens (Informationen) während der LLM-Inferenz“. Anthropic unterscheidet damit zwischen dem Formulieren von Anweisungen und dem Verwalten der umfassenderen Informationen, die während der Ausführung bereitgestellt werden. Anthropics Beitrag zu Context Engineering.

LangChain spricht in seinem Beitrag vom 2. Juli 2025 davon, „das Kontextfenster bei jedem Schritt eines Agenten mit genau den richtigen Informationen zu füllen“. Der Beitrag ordnet die Arbeit vier Tätigkeiten zu: schreiben, auswählen, verdichten und isolieren. Gemeint ist, nützlichen Zustand zu speichern, relevantes Material abzurufen, verbleibende Inhalte zu kürzen und unabhängige Untersuchungen voneinander zu trennen. LangChains Beitrag zu Context Engineering.

In der Praxis verändert sich damit, was überhaupt gestaltet werden muss. Ein einzelner Prompt kann unverändert bleiben. Die nächste Anfrage eines Agenten verändert sich dagegen jedes Mal, wenn er eine Datei liest, ein Tool-Ergebnis erhält, eine Teilaufgabe abschließt oder erkennt, dass eine frühere Annahme falsch war. Es braucht also Regeln dafür, wie diese Anfrage während der gesamten Aufgabe zusammengestellt wird.

Dokumentation geprüft am 13. Oktober 2026: Das nachfolgend beschriebene Tool-Verhalten wurde anhand der aktuellen Dokumentation von Anthropic und OpenAI geprüft. Das durchgehende Beispiel veranschaulicht einen Entwurf; es ist kein Benchmark aus dem Produktivbetrieb.

Context Engineering und Prompt Engineering: Was ist der Unterschied?

Prompt Engineering verbessert die Anweisung; Context Engineering verbessert die gesamte Anfrage, in die sie eingebettet ist. Beides bleibt nötig.

Bei einem Coding-Agenten könnte Prompt Engineering aus „Repariere die Registrierung“ die Anweisung machen: „Finde heraus, warum erneute Registrierungsversuche doppelte Willkommens-E-Mails auslösen. Schlage eine möglichst kleine Korrektur und einen Regressionstest vor.“ Context Engineering bestimmt anschließend, welche Registrierungsdateien, Wiederholungsprotokolle, Projektregeln und bisherigen Erkenntnisse der Agent erhält, bevor er die Korrektur vorschlägt.

Auch eine hervorragend formulierte Anweisung hilft nicht, wenn die Protokolle der falschen Umgebung geladen werden. Und ein sorgfältig ausgewählter Protokollausschnitt kann nicht ausgleichen, dass die Anweisung offenlässt, ob der Agent nur analysieren, Dateien ändern oder die Änderung bereitstellen soll.

Die entscheidende Fähigkeit: Kontext sinnvoll abgrenzen

Für jede Information muss feststehen, wann sie in den Kontext gehört und wann sie ihn wieder verlassen kann. Dauerhafte Projektregeln, der vorübergehende Aufgabenstand und Rohbelege brauchen unterschiedliche Aufbewahrungszeiten.

Eine Programmierkonvention gehört in die dauerhaft geltenden Anweisungen. „Der Zweig für erneute Versuche ist noch nicht getestet“ gehört in die Übergabe der aktuellen Aufgabe. Die vollständige Antwort eines Anbieters gehört in eine zugängliche Belegdatei; die relevanten Felder werden geladen, sobald sie die Entscheidung beeinflussen.

Deshalb ist Retrieval-Augmented Generation, kurz RAG, nur ein Teil dieser Arbeit. RAG ruft unterstützendes Material für ein Modell ab. Welche Anweisungen, Tools und Teile des Verlaufs erhalten bleiben und was aus dem Abruf in den Kontext gelangt, muss weiterhin entschieden werden.

Context Engineering für KI-Agenten: Die wichtigsten Maßnahmen

Der erste Ansatzpunkt ist die größte Quelle irrelevanten Kontexts im fehlerhaften Schritt. Es müssen nicht alle Mechanismen gleichzeitig eingeführt werden. Bei einem Debugging-Agenten, der in Protokollen versinkt, ist eine andere erste Korrektur nötig als bei einem Assistenten, der ständig Projektvorgaben vergisst.

Den Verlauf anhand von Entscheidungen verdichten

Claude Code, Anthropics Coding-Agent, bietet /context zur Prüfung der Kontextbelegung und /compact zum Kürzen eines Gesprächs. Die automatische Verwaltung entfernt ältere Tool-Ausgaben und fasst bei Bedarf anschließend das Gespräch zusammen. Die Dokumentation warnt ausdrücklich davor, dass detaillierte Anweisungen aus früheren Gesprächsabschnitten dabei verloren gehen können. Kontextverwaltung in Claude Code.

Die Verdichtung braucht einen klaren Zweck. Bei der Untersuchung der Willkommens-E-Mails wäre dieser Befehl sinnvoll: /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Er gibt aufgabenspezifische Vorgaben, garantiert aber nicht, dass jedes Detail erhalten bleibt.

Vor der Fortsetzung sollte geprüft werden, ob die Zusammenfassung noch zwischen beobachtet, abgeleitet und nicht geprüft unterscheidet. „Erneute E-Mail-Versandversuche untersucht“ benennt nur ein Thema. „Die Annahme durch den Anbieter ist bestätigt; der Pfad für die lokale Bestätigung muss noch untersucht werden“ hält dagegen einen Arbeitsstand fest, mit dem sich weiterarbeiten lässt.

Verdichtung bedeutet Informationsverlust. Originalbelege sollten zugänglich bleiben und dauerhafte Regeln in den Projektanweisungen stehen, damit ein späterer Schritt die benötigten Details wieder abrufen kann.

Belege erst dann abrufen, wenn sie gebraucht werden

Zuerst wird die Quelle geladen, die die nächste Frage beantwortet. Die Suche wird erst ausgeweitet, wenn das Ergebnis nicht genügt. Anthropics Engineering-Beitrag beschreibt dieses Vorgehen so: Schlanke Verweise bleiben erhalten, und Tools laden die Informationen bei Bedarf. Kontext zum richtigen Zeitpunkt laden.

In Claude Code unterstützen Tools zum Lesen von Dateien und zum Ausführen von Shell-Befehlen diesen Ablauf. Ein passender Auftrag lautet, den Handler für erneute Versuche zu finden, ihn und die aufrufende Stelle zu lesen und die zugehörige Fehlersequenz zu untersuchen. Ist das spezielle Grep-Tool aktiviert, kann es Dateipfade, passende Inhalte oder Trefferzahlen statt vollständiger Dateien zurückgeben. Tool-Referenz von Claude Code.

Für einen eigenen Agenten sollte ein Abruf einen Quellenverweis, einen relevanten Ausschnitt und genügend Metadaten liefern, um den Geltungsbereich zu bestimmen: Umgebung, Datensatzkennung, Version oder Gültigkeitsdatum. Ein späterer Tool-Aufruf kann den umliegenden Inhalt öffnen.

Ein Abruf kann relevante Belege übersehen. Deshalb braucht es eine Regel für die Ausweitung der Suche. Bleibt eine eng gefasste Suche erfolglos, muss der Suchbereich oder die Anfrage angepasst werden, bevor die Information als nicht vorhanden gilt. Lässt sich aus einem Ausschnitt nicht erkennen, ob eine Ausnahme greift, wird der umgebende Abschnitt geladen.

Tool-Ergebnisse kürzen, bevor sie ins Gespräch gelangen

Ein Tool sollte das Ergebnis für die nächste Entscheidung liefern und zugleich einen Weg anbieten, ausgelassene Details nachzuladen. Anthropic empfiehlt für umfangreiche Tool-Ausgaben Filter, Seiteneinteilung, Bereichsauswahl und Kürzung sowie hilfreiche Hinweise, wenn Ergebnisse verkürzt werden. Anthropics Hinweise zum Tool-Design.

Claude Code setzt dieses Muster bei umfangreichen Ausgaben erfolgreicher Shell-Befehle konkret um: Oberhalb der Grenze für die direkte Ausgabe liefert es den Pfad einer gespeicherten Datei und eine Vorschau. Der Agent kann die Datei bei Bedarf durchsuchen oder lesen. Fehlgeschlagene Befehle werden laut Dokumentation anders behandelt. Es darf deshalb nicht vorausgesetzt werden, dass jede gekürzte Fehlermeldung einen Dateipfad zum vollständigen Ergebnis enthält. Umgang mit Shell-Ausgaben.

Für den Registrierungsagenten enthält ein brauchbares Protokollergebnis das passende Ereignis, den vorausgehenden Vorgang, den Fehler und die Fundstelle. Wiederholte erfolgreiche Anfragen können in der Protokolldatei bleiben. Fehlercode und Ereigniskennung müssen exakt erhalten bleiben: Eine Umschreibung wie „Irgendetwas hat zu lange gedauert“ kann genau den Hinweis beseitigen, von dem die richtige Korrektur abhängt.

Pauschales Abschneiden kann die entscheidende Ausnahme entfernen. Auslassungen sollten sichtbar sein; eine Folgeabfrage oder ein Dateiverweis muss die Details zugänglich machen. Zuerst wiederholtes Rauschen kürzen, bevor widersprüchliche Belege gekürzt werden.

Unabhängige Untersuchungen an Subagenten ohne Gesprächsübernahme geben

Subagenten in Claude Code können eine klar begrenzte Untersuchung in einem eigenen Kontextfenster durchführen und ein Ergebnis zurückgeben. Ein Subagent ohne Fork beginnt mit seiner Definition und dem übergebenen Auftrag; ein Gesprächs-Fork übernimmt den Verlauf des übergeordneten Agenten. Beide trennen die anschließende Arbeit ab, doch nur die erste Variante startet mit einem unbelasteten Kontext. Subagenten und Forks.

Ein geeigneter Teilauftrag lautet etwa: „Untersuche den Pfad für erneute E-Mail-Versandversuche. Ändere keine Dateien. Liefere die relevanten Pfade, die Belege für eine doppelte Zustellung, konkurrierende Erklärungen und den nächsten Prüfschritt.“ Die nötigen Vorgaben gehören in den Auftrag; es darf nicht vorausgesetzt werden, dass der Subagent das Hauptgespräch kennt.

Die Rückgabe sollte auf das beschränkt bleiben, was sich weiterverwenden lässt: Erkenntnisse, Belegverweise und Unsicherheiten. Liefert ein Subagent seinen gesamten Leseverlauf zurück, verlagert er die Überladung lediglich wieder ins Hauptgespräch.

Subagenten stellen eigene Anfragen und verbrauchen Nutzungskontingent. Sie können Arbeit wiederholen, wenn ihr Auftrag eine Entscheidung auslässt, die der übergeordnete Agent bereits getroffen hat. Sinnvoll sind sie, wenn sich die Untersuchung abtrennen lässt und ihre Zwischenausgaben anschließend entbehrlich sind. Eng zusammenhängende Überlegungen sollten zusammenbleiben. Die Einrichtung beschreibt der Beitrag zu Claude-Code-Subagenten.

Gedächtnisdateien eine kleine, dauerhafte Aufgabe geben

CLAUDE.md enthält Projektanweisungen und ist kein Ablageort für jedes abgeschlossene Gespräch. Claude Code bietet außerdem eine automatische Gedächtnisfunktion für Notizen zu gewonnenen Erkenntnissen. Die Dokumentation grenzt beides von technisch erzwungener Konfiguration ab: Ein Verbot in einer Gedächtnisdatei macht die betreffende Handlung nicht technisch unmöglich. Gedächtnisfunktionen in Claude Code.

In einem kleinen Produktteam gehören repositoryspezifische Regeln, tatsächlich verwendete Build- und Testbefehle, Grenzen für Änderungen und Verweise auf ausführlichere Quellen in die dauerhaft geladene Datei. Der vorübergehende Stand einer Untersuchung bleibt in einer separaten Aufgabennotiz. Die Dateistruktur erläutert CLAUDE.md als Teamgedächtnis.

Eine leicht übersehene Einschränkung: Wird ein langes Dokument in CLAUDE.md importiert, wird auch dessen Inhalt geladen. Das Auslagern in importierte Dateien kann die Ordnung verbessern, ohne den aktiven Kontext zu verkleinern. Für Anweisungen, die nur in einem Teil des Repositorys benötigt werden, kommen die dokumentierten pfadbezogenen Regeln infrage. Bei wiederverwendbaren Abläufen stellt Claude Code normalerweise zunächst nur die Beschreibungen der Skills bereit; die vollständigen Anweisungen werden erst beim Aufruf geladen. Importe und Regeln mit begrenztem Geltungsbereich, Laden von Skills.

Dauerhaft gespeicherte Dateien bewahren veraltete Annahmen ebenso zuverlässig wie nützliches Wissen. Abgeschlossene Störungen und abgelöste Befehle sollten entfernt werden. Bei veränderlichen Fakten gehört eine Quelle oder ein Versionsstand dazu. Den grundsätzlichen Unterschied zwischen Sitzung, Arbeitskontext und dauerhaftem Speicher erklärt der Beitrag zum Gedächtnis von KI-Agenten.

Wie Claude Agent SDK und Codex diese Maßnahmen umsetzen

Die beschriebenen Tools bringen die Mechanismen mit; welche Belege und Aufgabengrenzen gelten, entscheidet weiterhin die Anwendung. Automatische Kontextverwaltung kann nicht bestimmen, welche fachliche Information der eigene Ablauf abzurufen vergessen hat.

Claude Agent SDK: Die Agentenschleife in die eigene Anwendung holen

Das Claude Agent SDK stellt die Tools, die Agentenschleife und die Kontextverwaltung hinter Claude Code für Anwendungen in Python und TypeScript bereit. Es eignet sich, wenn ein Agent in ein selbst betriebenes Produkt oder eine Automatisierung eingebettet werden soll. Überblick zum Agent SDK.

Das SDK verdichtet ältere Verlaufsteile automatisch, sobald sich das Kontextfenster seiner Grenze nähert, und gibt dabei ein Systemereignis namens compact_boundary aus. Wird dieses Ereignis zusammen mit den Aufgabenergebnissen protokolliert, lassen sich Fehler erkennen, die nach einer Zusammenfassung auftreten. SDK-Subagenten ohne Fork behalten ihre Zwischenarbeit in eigenen Gesprächen und geben ihre Abschlussnachricht zurück. Agentenschleife des SDK, SDK-Subagenten.

Das Laden von Projektanweisungen sollte bewusst konfiguriert werden. Die aktuellen Standardoptionen von query() aktivieren Nutzer- und Projektquellen. Werden in TypeScript settingSources oder in Python setting_sources angegeben, muss project enthalten sein, wenn die CLAUDE.md des Projekts geladen werden soll. Ein leeres Array verhindert das Laden. Entscheidend sind die Konfigurationsquellen, nicht die Auswahl der System-Prompt-Vorlage claude_code. Laden von Anweisungen im SDK.

Auch eine leistungsfähige Agentenschleife braucht fachlich passende Abrufregeln. Bei einem Support-Agenten muss weiterhin definiert werden, welcher Kunde gerade gemeint ist, welche Richtlinie gilt und welche Belege vor einer Handlung vorliegen müssen.

Codex: Repository-Anweisungen und laufendes Gespräch trennen

OpenAIs Codex liest vor Arbeitsbeginn Anweisungen aus AGENTS.md. Dabei kombiniert es globale Vorgaben mit Projektdateien entlang des Pfads vom Repository-Stammverzeichnis bis zum Arbeitsverzeichnis. Später geladene Vorgaben haben Vorrang; AGENTS.override.md hat im jeweiligen Verzeichnis Priorität. Projektanweisungen für Codex.

Diese Hierarchie erlaubt es, allgemeine Build-Regeln im Stammverzeichnis und spezielle Regeln nahe am jeweiligen Arbeitsbereich zu halten. Codex CLI bietet außerdem /compact zum Zusammenfassen des sichtbaren Gesprächs und /init zum Anlegen eines Grundgerüsts für eine Anweisungsdatei. Dieses Gerüst sollte anhand des Repositorys geprüft werden, bevor es als verbindlich gilt. Codex-Befehle.

Eine Anweisungsdatei im Repository hält den laufenden Aufgabenstand nicht automatisch fest. Aktuelles Ziel, bestätigte Erkenntnisse, offene Arbeiten und Belegstellen sollten separat gespeichert werden. Nach einem Neustart oder einer Verdichtung muss die nächste Anfrage diesen Arbeitsstand bereitstellen können, ohne die gesamte Untersuchung erneut wiederzugeben.

Context Engineering am Beispiel: Vom überladenen zum fokussierten Agenten

Das Material rund um eine Entscheidung lässt sich kürzen, solange ihre Voraussetzungen erhalten bleiben. Als Beispiel dient ein hypothetischer Coding-Agent, der doppelte Willkommens-E-Mails nach erneuten Registrierungsversuchen untersuchen soll. Die folgenden Dateinamen und Belege veranschaulichen den Entwurf; sie stammen nicht aus einem eingesetzten System.

Sein überladenes Ausgangspaket enthält das gesamte Entwicklungshandbuch, umfangreiche Repository-Auszüge, Protokolle unbeteiligter Dienste, alle früheren Debugging-Gespräche und Tools für sachfremde Verwaltungsaufgaben. Der eigentliche Auftrag ist enger: den Pfad zum doppelten Versand finden, die kleinstmögliche Änderung vorschlagen und einen Regressionstest bestimmen. Schemaänderungen gehören nicht zum Auftrag.

1. 1

   Aktuelle Aufgabe und dauerhafte Vorgaben erhalten

   An die Stelle konkurrierender Aufträge im Gesprächsprotokoll treten das aktuelle Ziel und die Abnahmekriterien. Die Einschränkung zu Schemaänderungen bleibt sichtbar. Für diesen Lauf werden die benötigten Repository-Tools bereitgestellt; Definitionen unbeteiligter Verwaltungstools bleiben draußen. Dauerhafte Repository-Konventionen kommen in die passende Projektanweisungsdatei, vorübergehende Beobachtungen bleiben in der Aufgabennotiz. Das gesamte Handbuch gehört nicht in einen automatisch geladenen Import.

2. 2

   Dateimassen durch eine Übersicht der Belegstellen ersetzen

   Verweise auf signup-handler.ts, welcome-job.ts, den Test für erneute Versuche und die zugehörige Protokolldatei bleiben erhalten. Diese Namen dienen der Veranschaulichung. Handler und Worker werden gelesen, wenn sie die nächste Frage beantworten; ihre Abhängigkeiten werden bei Bedarf untersucht. Die Übersicht macht Belege erreichbar, ersetzt aber nicht deren Lektüre.

3. 3

   Das Tool-Ergebnis auf den Fehler eingrenzen

   Angefordert werden das betroffene Registrierungsereignis und die Abfolge seiner erneuten Versuche. Angenommen, der hypothetische Datensatz zeigt zunächst die Annahme durch den Anbieter, dann eine fehlende lokale Bestätigung und schließlich einen weiteren eingereihten Versuch. Diese Abfolge, die Ereigniskennung und die Fundstelle bleiben erhalten. Unbeteiligte erfolgreiche Anfragen bleiben im Originalprotokoll. Ob der zweite Versuch tatsächlich zugestellt wurde, bleibt ausdrücklich offen.

4. 4

   Eine klar begrenzte Suche auslagern

   Ein Subagent ohne Fork erhält den Auftrag, die Stelle zu finden, an der doppelter Versand verhindert wird. Dazu bekommt er den Aufgabenumfang und die relevanten Pfade. Gefordert sind Fundstellen und Belege sowie ein ausdrücklicher Hinweis, falls die Suche unvollständig war. Das Ergebnis geht an den Hauptagenten zurück; die Such- und Lesevorgänge des Subagenten bleiben außerhalb seines Kontexts.

5. 5

   Die Untersuchung zu einer brauchbaren Übergabe verdichten

   Erhalten bleiben das aktuelle Ziel, bekannte Belege, verworfene Erklärungen, die offene Frage und die nächste Handlung. Ein eingereihter erneuter Versuch muss weiterhin von einer bestätigten doppelten Zustellung unterschieden werden. Das ursprüngliche Gesprächsprotokoll wird archiviert, damit der Agent Details nachschlagen kann, statt sie zu erraten.

6. 6

   Aus den verbleibenden Informationen die nächste Anfrage aufbauen

   Geladen werden die Aufgabe, dauerhafte Regeln, der relevante Handler-Ausschnitt, die gefilterte Ereignisfolge und das Ergebnis des Subagenten. Als Nächstes werden der Bestätigungspfad und die Verhinderung von Doppelversand untersucht und der Regressionstest vorgeschlagen. Falls dafür weitere Belege nötig sind, werden sie nachgeladen. Das gesamte Archiv wird nicht aus Gewohnheit wieder angehängt.

Die daraus entstehende Aufgabennotiz könnte so aussehen:

Ziel: Doppelte Willkommens-E-Mails nach erneuten Registrierungsversuchen erklären und eine minimale Korrektur mit Regressionstest vorschlagen.
Vorgabe: Keine Schemaänderungen vornehmen.
Belege: Die ausgewählte Protokollsequenz zeigt die Annahme durch den Anbieter, eine fehlende lokale Bestätigung und einen weiteren eingereihten Versuch. Ereignisverweis und Fundstelle im Originalprotokoll erhalten.
Ungeklärt: Ob der eingereihte erneute Versuch zugestellt wurde und wo die Verhinderung von Doppelversand greift.
Nächste Prüfung: Die Pfade für Bestätigung und Verhinderung von Doppelversand im referenzierten Handler und Worker untersuchen.

Diese hypothetische Notiz hält die Unsicherheit sichtbar. Für die Diagnose erhält das Modell zusätzlich den zugehörigen Belegausschnitt.

Das Ergebnis ist ein kleinerer Bestand an Inhalten, keine behauptete Token-Einsparung. Die genaue Token-Zahl hängt von der tatsächlichen Anfrage und dem Tokenizer ab. Ob Kosten sinken und mehr Aufgaben erfolgreich abgeschlossen werden, muss gemessen werden. Das Beispiel zeigt, was entfernt werden kann und was erhalten bleiben muss.

Eine Vorlage für die Übergabe beim Context Engineering

Eine Aufgabennotiz sollte diese Felder enthalten, ausgefüllt mit tatsächlichen Belegen aus dem Lauf:

• Ziel und Abschlusskriterium: der aktuelle Auftrag und die Bedingungen für einen erfolgreichen Abschluss.
• Vorgaben: Grenzen, die auch im nächsten Schritt gelten müssen.
• Gesicherte Fakten: jede Erkenntnis zusammen mit ihrer Fundstelle und dem relevanten Versionsstand oder Geltungsbereich.
• Unsicherheit: was weiterhin nur abgeleitet, widersprüchlich oder ungeprüft ist.
• Nächste Handlung: die nächste Prüfung und die Stelle, an der sich ihre Belege abrufen lassen.

Ändert sich eine Erkenntnis, muss die Notiz aktualisiert werden. Wer jeden neuen Gedanken nur anhängt, ohne ältere Aussagen zu überarbeiten, erzeugt das ursprüngliche Problem erneut – lediglich in einer kleineren Datei.

Kontextgröße und Kosten: Welche Zahlen wirklich zählen

Optimiert werden die Kosten eines abgenommenen Ergebnisses, nicht die Länge einer einzelnen Anfrage. Ein kleineres Hauptgespräch kann mit mehr Subagenten-Aufrufen, Abrufen oder fehlgeschlagenen Versuchen einhergehen.

Zwei dokumentierte Budgets für Anweisungen zeigen, warum die Einheit wichtig ist. Die Standardobergrenze für zusammengefasste Projektdokumente in Codex beträgt 32 KiB, also 32 × 1,024 = 32,768 Bytes. Das ist eine Byte-Grenze, kein Token-Budget. Claude Code empfiehlt, jede CLAUDE.md unter 200 Zeilen zu halten. Das ist eine Empfehlung für das Schreiben, keine feste Grenze des Kontextfensters. Keine dieser Zahlen erlaubt eine Vorhersage der Einsparungen. Anweisungsgrenze in Codex, Schreibempfehlungen für Claude Code.

Für einen produktiven Ablauf werden die Kosten des Hauptagenten, der Subagenten, der Verdichtung, der Abrufe und der Wiederholungsversuche erfasst. Anschließend gilt:

Kosten pro abgenommener Aufgabe = Gesamtkosten des Ablaufs über alle Versuche ÷ Anzahl der Aufgaben, die die Abnahmekriterien erfüllen.

Für ein Monatsbudget werden zu den Gebühren der Modellnutzung die Kosten für Tools, Abrufe, Speicher und Hosting addiert. Für Context Engineering gibt es keinen einheitlichen Monatspreis. Ohne die konkrete Arbeitslast und die geltenden Anbietertarife lässt sich auch keine belastbare Einsparung in Dollar nennen.

Caching erschwert den Vergleich. OpenAIs Prompt-Cache verwendet übereinstimmende Präfixe der fertig zusammengesetzten Eingabe erneut. Eine Verdichtung kann dieses Präfix verändern und damit die Cache-Wiederverwendung verringern, obwohl die Anfrage kürzer wird. Wiederverwendbare Anweisungen sollten möglichst stabil bleiben; verglichen werden die Gesamtkosten vor und nach der Änderung. Eine geringere Cache-Trefferquote allein beweist nicht, dass eine Optimierung gescheitert ist. Prompt-Caching bei OpenAI.

Die Diagnose von Prompt-Caching bei GPT-6 hilft, Probleme durch wechselnde Präfixe von Problemen durch unnötige Inhalte zu trennen. Ein Cache macht die Verarbeitung wiederholter Eingaben günstiger. Ob diese Eingaben zur Aufgabe gehören, entscheidet er nicht.

Context Engineering in der Praxis: Was zuerst ändern?

Gehandelt wird, wenn der Ablaufmitschnitt einen Kontextfehler zeigt – mit dem kleinsten Eingriff, der ihn behebt. Ein solcher Mitschnitt, auch Trace genannt, dokumentiert die Abfolge von Anfragen, Tool-Aufrufen und Ergebnissen. Dazu gehört, was das Modell vor jeder Entscheidung gesehen hat.

Für Entwicklungsteams ist der Schritt unmittelbar vor der falschen Handlung entscheidend. Fehlen Belege, muss der Abruf korrigiert werden. Gehen sie in wiederholten Ausgaben unter, sollte das Tool-Ergebnis gefiltert werden. Verdrängt eine frühere Diskussion den aktuellen Auftrag, müssen Aufgabenstand und Übergabe berichtigt werden. Flutet eine abtrennbare Untersuchung das Hauptgespräch, gehört sie in einen eigenen Kontext.

Für Betriebsverantwortliche gilt: Ein akzeptables Ergebnis definieren und repräsentative Fehlerfälle für die Evaluation aufbewahren. An denselben Aufgaben werden Ergebnisqualität, unbelegte Behauptungen, Wiederholungsversuche, Latenz und Gesamtkosten verglichen. Es sollte jeweils nur eine Regel für die Kontextzusammenstellung geändert werden, damit das Ergebnis interpretierbar bleibt. Vorhandene Ablaufmitschnitte liefern die Grundlage für Offline-Evaluationsfälle.

Für Einkaufsverantwortliche sind andere Fragen zentral: Macht das Produkt den Kontext und die Tool-Ergebnisse hinter einer Antwort sichtbar? Bleiben Quellenverweise nach einer Zusammenfassung erhalten? Lassen sich dauerhafte Anweisungen steuern? Ein Gedächtnis-Feature, bei dem nicht erkennbar ist, welche Inhalte geladen werden, erschwert die Fehlersuche.

Zusätzliche Mechanismen können warten, wenn ein kurzer, klar begrenzter Ablauf bereits zuverlässig funktioniert. Möglicherweise genügt eine verständlichere Anweisung oder eine bessere Tool-Fehlermeldung, ohne Gedächtnisdienst oder Subagenten-Netzwerk. Liegt der Fehler an falschen Berechtigungen, defekter Anwendungslogik oder nicht verfügbaren Quelldaten, muss diese Ursache direkt behoben werden. Das Zusammenstellen des Kontexts allein reicht dafür nicht aus.

Was wird bei Context Engineering überbewertet?

Ein größeres Kontextfenster, mehr Gedächtnis und mehr Agenten schaffen Kapazität, belegen aber keine besseren Entscheidungen. Entscheidend ist, ob sie diesem konkreten Ablauf helfen, die richtigen Informationen in den nächsten Schritt mitzunehmen.

„Alles in den Prompt“ erspart die Auswahl, bringt aber konkurrierendes Material hinein. „Alles zusammenfassen“ wählt zu radikal aus, wenn dabei die entscheidende Ausnahme verschwindet. „Das übernimmt ein Subagent“ hilft nur, wenn sich die Aufgabe übergeben lässt, ohne wesentliche Entscheidungen zu verlieren.

Der teuerste Irrtum besteht darin, eine kürzere Anfrage mit einem überprüften System gleichzusetzen. Ein Agent, der kostengünstig auf Grundlage der falschen Richtlinie antwortet, liegt weiterhin falsch. Gute Regeln für den Kontext sollten die Antwort leichter überprüfbar machen: Die maßgebliche Regel ist sichtbar, die Belege haben eine Quelle und offene Unsicherheit bleibt ausdrücklich benannt.

Häufige Fragen, wenn ein Agent vom Auftrag abkommt

Hilft Context Engineering, wenn ein Agent in der Demo funktioniert, im Produktivbetrieb aber scheitert?

Es kann fehlende Belege, veraltete Anweisungen, übermäßige Tool-Ausgaben und verlorenen Aufgabenstand beheben. Zuerst muss die fehlerhafte Anfrage untersucht werden. Ein defektes Tool, fehlerhafte Anwendungslogik oder eine Aufgabe jenseits der Modellfähigkeiten braucht eine eigene Lösung. Maßstab für die Änderung sind abgenommene Ergebnisse bei repräsentativen Aufgaben.

Braucht es zum Einstieg eine Vektordatenbank oder ein Multi-Agenten-Framework?

Nein. Der Einstieg gelingt mit ausdrücklichen Projektanweisungen, dem gezielten Abruf von Dateien oder Dokumenten, begrenzten Tool-Ergebnissen und einer Aufgabenübergabe. Semantische Suche kommt hinzu, wenn sie zum Finden relevanter Inhalte nötig ist. Ein Subagent wird sinnvoll, wenn eine in sich geschlossene Untersuchung von einem eigenen Kontext profitiert.

Woran lässt sich erkennen, dass zu viel Kontext entfernt wurde?

Für die nächste Entscheidung müssen die maßgebliche Regel, unterstützende Belege, der zutreffende Geltungsbereich und wichtige Ausnahmen noch vorhanden sein. Muss der Agent eine entfernte Tatsache erraten, wurde zu stark gekürzt. Die Quelle sollte abrufbar bleiben; beantwortet der Ausschnitt die Frage nicht, wird mehr vom Original gelesen.

Der erste Schritt am Montag: Einen bereits vorhandenen fehlgeschlagenen Lauf nehmen und die Anfrage vor seiner ersten falschen Handlung untersuchen. Die Inhalte werden als dauerhafte Anweisungen, aktueller Aufgabenstand, jetzt benötigte Belege oder Material eingeordnet, das im Speicher bleiben kann. Dann wird die kleinste passende Änderung vorgenommen. Anschließend werden Ergebnis und Gesamtkosten des Ablaufs anhand derselben Evaluationsfälle verglichen.

Der Newsletter liefert praktische Anleitungen zum Entwickeln und Betreiben nützlicher Agenten.