Context Engineering: Definition, Abgrenzung, Beispiel

Context Engineering bezeichnet die planvolle Gestaltung dessen, was ein Sprachmodell (das große KI-Sprachmodell hinter Anwendungen wie ChatGPT) bei jeder einzelnen Anfrage vor sich sieht. Die Disziplin steuert den Inhalt des Kontextfensters (des Arbeitsspeichers, in den ein Modell pro Anfrage alles hineinlesen muss, was es wissen soll) über die Zeit: welche Anweisungen, nachgeschlagenen Textausschnitte, Werkzeug-Beschreibungen, gespeicherten Nutzer-Notizen und aktuellen Eingaben pro Aufruf hineinkommen, was zusammengefasst wird und was hinausfällt.

Was ist Context Engineering?

Ein Sprachmodell beginnt jede Anfrage an die Programmierschnittstelle (API) bei null. Es erinnert sich nicht an die letzte Runde. Alles, was das Modell für die aktuelle Antwort wissen muss, gehört ins Kontextfenster: die Rollenanweisung, die Beschreibungen der verfügbaren Werkzeuge, der bisherige Gesprächsverlauf, aus einer Wissensdatenbank nachgeschlagene Textausschnitte, gespeicherte Nutzer-Notizen und die aktuelle Frage. Ein produktiver Agent (ein Programm, das ein Sprachmodell in Schleife mit Werkzeugen kombiniert) macht Dutzende bis Tausende solcher Anfragen pro Sitzung; Kosten, Wartezeit und Antwort-Qualität entscheiden sich an der Bestückung dieses Fensters. Context Engineering ist die Disziplin, die genau diese Bestückung als eigenständige Aufgabe behandelt.

Der Begriff hat eine klare Herkunft: [Andrej Karpathy](https://karpathy.ai/) hat ihn Mitte 2025 als eigene Disziplin gegen das engere Prompt Engineering positioniert. LangChain hat ihn im Blog-Beitrag [„The rise of Context Engineering"](https://www.langchain.com/blog/context-engineering-for-agents) zur Plattform-Disziplin ausgebaut, Anthropic hat das Engineering-Posting [„Effective context engineering for AI agents"](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) veröffentlicht. Auf Deutsch existiert die Übersetzung „Kontextgestaltung"; in der Fachdiskussion dominiert der englische Begriff.

Operativ tragen vier Mechaniken die Disziplin. Caching wiederverwendet identische Prompt-Prefixes über mehrere Aufrufe (Systemprompt, Tool-Definitionen, statische Dokumente) und senkt den Input-Preis für den gecachten Anteil um 60 bis 90 Prozent. Pruning hält das Fenster klein: Sliding Window, Trim-on-Budget, Tool-Filtering, Message-Decay. Selection entscheidet, was pro Aufruf überhaupt hereinkommt (RAG, Memory-Read, Tool-Selection on-demand, Few-Shot-Selection). Compression verdichtet ältere Turns durch Zusammenfassung, hierarchische Summaries oder Schema-Komprimierung. Die vier Mechaniken sind unabhängig steuerbar und greifen an unterschiedlichen Stellen im Lifecycle des Kontextfensters.

Der Begriff existiert, weil drei Entwicklungen die Prompt-Engineering-Klammer zu eng gemacht haben: Agent-Workloads laufen in Produktion mit vielen Aufrufen pro Session, Tool-Use ist Standard und bläst das Fenster mit Tool-Definitionen auf, und Long-Context-Modelle versprechen zwar eine Million Tokens und mehr, verarbeiten Inhalte in der Mitte langer Kontexte laut [Lost-in-the-Middle-Paper aus Stanford](https://arxiv.org/abs/2307.03172) aber systematisch schlechter. Mehr Fenster heißt nicht mehr Qualität.

Abgrenzung zu Prompt Engineering, RAG, Fine-Tuning und Agent Memory

Context Engineering wird häufig mit angrenzenden Disziplinen vermischt. Die relevanten Trennlinien:

Begriff	Ebene	Verhältnis zu Context Engineering
Prompt Engineering	ein einzelner Aufruf	Optimiert die Formulierung eines Prompts. Sub-Disziplin innerhalb von Context Engineering; die eigentliche Hebelwirkung liegt im Lifecycle des Kontextfensters über viele Aufrufe.
RAG	Selection-Pattern	Zieht externe Dokumente bedarfsgerecht in das Fenster. Baustein innerhalb von Context Engineering, dieselbe Ebene wie Memory-Read oder Tool-Selection.
Fine-Tuning	Modell-Gewichte	Verankert stabile Verhaltensmuster (Ton, Format, Nischenwissen) direkt im Modell. Verschiebt die Grenze dafür, was pro Aufruf mitgeschickt werden muss.
Agent Memory	Persistenz-Schicht	Speichert Konversationsverlauf, Präferenzen und Erfahrungen über Sitzungsgrenzen hinweg. Datenquelle für Context Engineering, das entscheidet, welche Memory-Einträge pro Aufruf in den Prompt geladen werden.
Kontext-Window	Modell-Eigenschaft	Technische Obergrenze der Prompt-Länge (128k bis mehrere Millionen Tokens). Context Engineering entscheidet über den Inhalt innerhalb dieser Grenze; ein größeres Fenster ersetzt die Disziplin nicht.

Die zentrale Trennlinie verläuft zwischen Prompt Engineering und Context Engineering. Prompt Engineering behandelt eine gute Formulierung als Zielgröße; Context Engineering behandelt die Zusammensetzung des Kontextfensters über den gesamten Lifecycle eines Agenten als Zielgröße. RAG, Agent Memory und Tool-Use liefern die Bausteine, die Context Engineering orchestriert.

Beispiel: Kundenservice-Agent mit Session-Historie

Ein Kundenservice-Agent lädt pro Aufruf einen 6.000-Token-Systemprompt (Tonalität, Compliance-Regeln), 3.000 Tokens Tool-Definitionen für 40 verfügbare Werkzeuge, die letzten 8 Konversationsturns (rund 4.000 Tokens), zwei RAG-Chunks aus der Wissensdatenbank (2.000 Tokens) und drei Memory-Einträge zum Kunden (500 Tokens). Ohne Context Engineering landen alle 40 Tool-Definitionen und die volle Session-Historie im Fenster. Die Token-Rechnung wächst linear mit der Sitzungsdauer, das Modell verliert Details in der Mitte, und wiederkehrende Prefixes werden bei jedem Call neu abgerechnet.

Mit Context Engineering greifen die vier Mechaniken zusammen. Caching legt Systemprompt und Tool-Definitionen als stabilen Prefix in den Anbieter-Cache; ab dem zweiten Aufruf kosten diese 9.000 Tokens rund 10 Prozent des normalen Input-Preises. Selection filtert die 40 Tools per Router auf die vier für den aktuellen Schritt relevanten und lädt nur diese in das Fenster. Compression fasst ältere Konversationsturns zu einem Zusammenfassungsblock zusammen, sobald ein Session-Budget überschritten ist. Pruning wirft die verdichteten Original-Turns aus dem Fenster. Umgesetzt wird die Mechanik häufig in einem LLM-Gateway plus Agent-Framework-Layer, damit die Regeln anwendungs-übergreifend durchsetzbar sind.