Definition: Context Engineering
Context Engineering ist die Disziplin, die Daten, Werkzeuge, Anweisungen und Memory-Inhalte gezielt zusammenzustellen, die ein KI-System in jedem Arbeitsschritt sieht - und das Kontextfenster des Large Language Model als knappes Arbeitsgedächtnis zu behandeln statt als offene Leinwand.
Kernmerkmale von Context Engineering
Context Engineering wirkt über die gesamte Laufzeit eines Agentenlaufs, nicht an einer einzelnen Prompt-Grenze, und ändert die Inhalte des Kontextfensters dynamisch, sobald neue Informationen eintreffen.
- Dynamische Kontext-Zusammenstellung pro Schritt statt statischer Prompt
- Explizites Token-Budget für Anweisungen, Tools, abgerufene Daten und Memory
- Memory über Turns hinweg via Zusammenfassung, Scratchpad und externem State
- Tool-Beschreibungen und -Outputs zählen als Kontext und konkurrieren um den Platz
Context Engineering vs. Prompt Engineering
Prompt Engineering formt den einzelnen Anweisungstext, den das Modell sieht. Context Engineering entscheidet alles drumherum: welche abgerufenen Dokumente angehängt werden, welche Tool-Definitionen sichtbar sind, welche vergangenen Turns bleiben, welche zusammengefasst und welche verworfen werden. Andrej Karpathy formulierte den Unterschied Mitte 2025 mit dem Bild: Das LLM ist die CPU, das Kontextfenster ist das RAM, das bewusst befüllt werden muss. Diese Verschiebung zählt, weil jeder produktionsreife Agent gleich scheitert, wenn das Kontextfenster mit Low-Signal-Inhalten zuläuft: Halluzinationen steigen, Tool-Nutzung leidet, Latenz wächst.
Bedeutung von Context Engineering im Enterprise-KI-Umfeld
Context Engineering ist heute der praktische Engpass für die Qualität produktiver KI-Agenten. Anthropics Engineering-Beitrag von September 2025 beschreibt Context Engineering als natürliche Weiterentwicklung von Prompt Engineering und berichtet bis zu 54 Prozent Verbesserung auf Agent-Benchmarks, wenn ad-hoc Prompt-Stuffing durch bewusste Kontext-Kuration ersetzt wird.
Methoden und Verfahren für Context Engineering
Enterprise-Context-Engineering kombiniert vier kanonische Strategien, die sich direkt auf typische Agenten-Fehlermuster abbilden.
Write Context
Write Context umfasst alles, was der Agent außerhalb des Live-Fensters persistiert: Scratchpads, in die er beim Reasoning schreibt, strukturierte Memory-Updates am Sitzungsende und Audit-Logs für die spätere Prüfung.
- Scratchpad-Notizen für Zwischen-Reasoning zwischen Tool-Aufrufen
- Strukturierte Memory-Updates, die am Sitzungsende in einen persistenten Store committet werden
- Audit-Log jeder Kontext-Änderung für Evaluation und Rollback
Select Context
Select Context entscheidet, was für den nächsten Schritt ins Fenster gezogen wird: die richtigen Dokumente aus einem Retrieval-Augmented-Generation-Store, die richtigen vergangenen Turns aus dem Sitzungs-Memory, die richtige Tool-Untermenge für den aktuellen Intent. Selection-Qualität zählt meist mehr als Retrieval-Recall, weil jeder irrelevante Token das Signal verdünnt, das wirklich zählt.
Compress and Isolate Context
Compress verwandelt lange Verläufe in kurze Zusammenfassungen, die nur die wenigen Fakten erhalten, die der Agent braucht - das schafft Platz für frische Evidenz. Isolate teilt Arbeit auf Sub-Agenten oder Sandbox-Kontexte auf, sodass verrauschter Zwischen-State die finale Entscheidung nicht verschmutzt. Beides ist ab dem Moment Pflicht, ab dem ein Agent mehr als eine Handvoll Turns läuft oder lange Aufgaben bearbeitet.
Wichtige Kennzahlen für Context Engineering
Context-Engineering-Programme reporten gegen operative, strategische und Qualitätsmetriken, die Token-Ökonomie mit Agent-Performance verknüpfen.
Operative Performance-Metriken
- Kontext-Auslastung: Ziel 60-80 Prozent des Fensters pro Schritt, nicht 95-100 Prozent
- Tokens pro Aufgabe: Ziel 30-60 Prozent Reduktion gegenüber naivem Prompt-Stuffing
- Tool-Relevanz: Anteil der bereitgestellten Tools, die der Agent pro Aufgabe wirklich nutzt
- Retrieval-Precision at k: Anteil der abgerufenen Chunks, auf die der Agent verweist
Strategische Geschäftsmetriken
Der Business Case für Context Engineering beruht darauf, mit dem gleichen Modell-Spend mehr zu erreichen. Anthropics berichtete 54-Prozent-Benchmark-Verbesserung übersetzt sich direkt in entweder niedrigere Inferenzkosten bei gleicher Genauigkeit oder höhere Genauigkeit bei gleichen Kosten - beides skaliert in volumenstarken Produktions-Deployments.
Qualitäts- und Zuverlässigkeitsmetriken
Qualitätsmessung läuft per KI-Evaluation auf einer festen Regressions-Suite: Halluzinationsrate je Intent, Tool-Use-Genauigkeit, Anteil belegbar gegrundeter Antworten vor und nach Kontext-Änderungen. Die entscheidende Metrik: Verbessert eine bewusste Kontext-Änderung den Eval-Score, ohne eine andere Metrik zu verschlechtern?
Risikofaktoren und Kontrollen bei Context Engineering
Context Engineering bringt eigene Fehlermuster mit, die explizite Guardrails verlangen.
Context Overflow und Lost-in-the-Middle
Wenn das Fenster über das effektive Verständnisband eines Modells hinaus gefüllt wird, sinkt die Genauigkeit, obwohl der Prompt technisch noch in das Limit passt.
- Harte Token-Budgets pro Kontextkategorie (Anweisungen, Tools, Daten, Memory)
- In der Regressions-Suite auf Long-Context-Eingaben testen, nicht nur auf kurze
- Genauigkeit als Funktion der Kontextlänge tracken, nicht nur den Durchschnitt
Veraltetes und widersprüchliches Memory
Memory, das über Sitzungen überdauert, kann veraltete Fakten oder widersprüchliche Zusammenfassungen tragen, denen der Agent dann vertraut. Gegenmaßnahmen: versionierte Memory-Einträge, Aktualitäts-Scoring und explizite Konfliktauflösungs-Prompts, wenn zwei Memory-Quellen widersprechen.
Datenleckage sensibler Inhalte über Kontext
Kontextfenster aggregieren Daten aus vielen Quellen - das mischt schnell Kunden-, Mitarbeiter- und regulierte Informationen in einen einzigen LLM-Aufruf. Behandeln Sie das Kontextfenster wie eine Datenbankabfrage: Datenmenge minimieren, vor dem Retrieval maskieren, jeden Abruf gegen die Wissensmanagement-Quelle protokollieren - so bleiben DSGVO und Audit-Pflichten nachweisbar.
Praxisbeispiel
Eine mittelständische DACH-Maschinenbau-Service-Operation hat die Prompt-Stuffing-Pipeline hinter ihrem Dispositions-Agenten in ein context-engineered System umgebaut. Vorher konkatenierte jede Dispositionsentscheidung die komplette Kundenhistorie, alle offenen Aufträge und den gesamten Ersatzteilkatalog ins Fenster - der Agent verfehlte regelmäßig die relevante SLA-Klausel. Die neue Pipeline zieht nur die letzten drei relevanten Tickets des Kunden, die SLA-Klausel zur aktuellen Produktlinie und den Teilebestand der Technikerregion - 60 Prozent des Fensters bleiben frei für Reasoning und Tool-Aufrufe.
- Per-Step-Retrieval-Policy für Tickets, SLA-Klauseln und Bestand pro Produktfamilie
- Token-Budget durchgesetzt über Anweisungen, Tools und abgerufene Daten
- Persistentes Memory der Dispositionsentscheidungen für die Schichtende-Prüfung
- Evaluations-Suite, die Kontext-Änderungen gegen 200 Regressionsfälle bewertet
Aktuelle Entwicklungen und Auswirkungen
Context Engineering hat sich zwischen Q3 2025 und Q2 2026 vom Blog-Post zum operativen Standard entwickelt.
Von Prompt-Bibliotheken zu Context-Pipelines
Unternehmen bauen keine wiederverwendbaren Prompt-Bibliotheken mehr, sondern wiederverwendbare Context-Pipelines, die pro Schritt entscheiden, was abgerufen, komprimiert und verworfen wird.
- Pipeline-Templates für typische Agent-Formen (Recherche, Disposition, Support)
- Context-Router, die Retrieval-Strategien je Intent auswählen
- Token-Budget-Gates, die Läufe blockieren, deren Kontext das Budget übersteigt
Lange Kontextfenster lösen das Problem nicht
Million-Token-Fenster von Gemini und Claude machen naives Prompt-Stuffing technisch möglich, aber operativ teuer und qualitätsschädlich. Context Engineering bleibt der bestimmende Faktor für Agent-Zuverlässigkeit auch im Million-Token-Maßstab, weil Aufmerksamkeit nicht linear mit der Fenstergröße skaliert.
Kontext als Beschaffungs-Spezifikation
Enterprise-Procurement beginnt, Context-Engineering-Praktiken in Agent-Anbieter-Bewertungen zu spezifizieren - dokumentierte Kontext-Budgets, Retrieval-Policies und Memory-Governance gelten als Nachweis von Produktionsreife, nicht als Forschungs-Kuriosität.
Fazit
Context Engineering ist die Lebenszyklus-Disziplin, die 2026 darüber entscheidet, ob ein produktiver KI-Agent zuverlässig, bezahlbar und auditierbar ist. Die vier kanonischen Strategien (write, select, compress, isolate) ersetzen die Prompt-Stuffing-Muster, die die frühe Prompt-Engineering-Ära prägten. Unternehmen, die das Kontextfenster als knappes Arbeitsgedächtnis behandeln, liefern Agenten, die Skalierung und Audit überstehen; wer es als offene Leinwand sieht, liefert Agenten, die das Demo bestehen und im Quartalsreview scheitern. Mit wachsenden Kontextfenstern wird die Disziplin wichtiger, nicht unwichtiger: Die Frage verschiebt sich von “was passt rein” zu “was sollte drin sein”.
Häufig gestellte Fragen
Was ist Context Engineering und wie unterscheidet es sich von Prompt Engineering?
Context Engineering ist die Praxis, alles zu kuratieren, was das Modell pro Schritt sieht - nicht nur den Anweisungstext. Es behandelt das Kontextfenster als knappes Arbeitsgedächtnis und füllt es dynamisch mit Dokumenten, Tools und Memory, die zur aktuellen Entscheidung passen. Prompt Engineering schreibt die Anweisung; Context Engineering entscheidet, was sie umgibt.
Warum ist Context Engineering die dominierende Skill für KI-Agenten geworden?
Produktive KI-Agenten scheitern, wenn das Kontextfenster mit Low-Signal-Inhalten zuläuft: Halluzinationen steigen, Tool-Nutzung leidet, Latenz wächst. Anthropics Engineering-Beitrag von September 2025 berichtet bis zu 54 Prozent Benchmark-Verbesserung, wenn Context Engineering ad-hoc Prompt-Stuffing ersetzt - ein Muster, das sich in Produktions-Traffic von Unternehmen wiederfindet.
Was sind die vier kanonischen Strategien des Context Engineering?
Write, Select, Compress, Isolate. Write umfasst persistierte Scratchpads und Memory; Select betrifft, was ins Fenster gezogen wird; Compress verwandelt lange Verläufe in kurze Zusammenfassungen; Isolate teilt Arbeit auf Sub-Agenten, damit verrauschter State die finale Entscheidung nicht verschmutzt. Die meisten produktiven Agenten nutzen alle vier.
Machen Million-Token-Kontextfenster Context Engineering überflüssig?
Nein. Million-Token-Fenster von Gemini und Claude machen naives Prompt-Stuffing technisch möglich, aber operativ teuer und qualitätsschädlich. Aufmerksamkeit skaliert nicht linear mit der Fenstergröße, und Lost-in-the-Middle-Effekte treten deutlich vor dem technischen Limit auf. Context Engineering bleibt der bestimmende Faktor für Agent-Zuverlässigkeit bei jeder Fenstergröße.
Wie wird Context Engineering gemessen?
Standardmuster ist eine Regressions-Suite, die Halluzinationsrate, Tool-Use-Genauigkeit und Anteil gegrundeter Antworten vor und nach jeder Kontext-Änderung bewertet. Operative Metriken sind Kontext-Auslastung pro Schritt (Ziel 60-80 Prozent), Tokens pro Aufgabe und Retrieval-Precision at k. Die entscheidende Frage: Verbessert eine Kontext-Änderung den Eval-Score, ohne eine andere Metrik zu verschlechtern?
Ersetzt Context Engineering Retrieval-Augmented Generation?
Nein. Retrieval-Augmented Generation ist eine Methode innerhalb von Context Engineering. Context Engineering entscheidet, welche abgerufenen Chunks ins Fenster kommen, welche vergangenen Turns bleiben, welche Tools sichtbar sind und wie viel Platz für das Reasoning des Modells übrig bleibt. RAG liefert Kandidaten; Context Engineering wählt aus und budgetiert.
