Was ist Context Engineering? Die Fähigkeit, die KI-Demos von funktionierender KI trennt: Ein praxisnaher Leitfaden

Was Context Engineering ist und warum es KI-Demos von funktionierender KI trennt, wird klarer, wenn das Konzept mit einer konkreten Entscheidung verbunden wird, statt es als weiteres KI-Schlagwort zu behandeln. Dieser Leitfaden von AI Tools Radar konzentriert sich auf die Funktionsweise, die wichtigen Abwägungen und die Fragen, die Sie vor der Einführung eines Tools oder Workflows stellen sollten.

Im Juni 2025 veröffentlichte Andrej Karpathy eine Definition, die seither als Standardrahmen für eine aufkommende Disziplin gilt: Context Engineering ist „die feine Kunst und Wissenschaft, das Kontextfenster für den nächsten Schritt mit genau den richtigen Informationen zu füllen“.

Diese Einordnung war wichtig, weil sie etwas benannte, das Praktiker schon ohne Bezeichnung taten. Jede ernsthafte KI-Anwendung, jeder produktive Agent und jeder Workflow mit verlässlichen Ergebnissen enthält bewusste Entscheidungen darüber, welche Informationen das Modell bei seiner Ausführung sieht. Zusammengenommen sind diese Entscheidungen Context Engineering.

Prompt Engineering hingegen ist das, woran die meisten Menschen denken, wenn sie sich „Arbeit mit KI“ vorstellen. Sie schreiben bessere Anweisungen, formulieren klar und fügen Beispiele hinzu. Prompt Engineering ist real und nützlich. Es betrifft jedoch nur eine Ebene des Problems und in Produktionssystemen oft nicht die wichtigste.

Context Engineering ist die umfassendere Disziplin. Sie umfasst nicht nur, was Sie das Modell fragen, sondern alles, was es beim Antworten weiß: die Anweisungen, unter denen es arbeitet, die aufrufbaren Tools, den Gesprächsverlauf, die für die Aufgabe abgerufenen Dokumente und die Erinnerung daran, wer Sie sind und woran Sie gearbeitet haben. Ob diese Elemente richtig, in der richtigen Kombination und zum richtigen Zeitpunkt zusammenkommen, bestimmt, ob eine KI-Anwendung funktioniert oder scheitert.

Context Engineering gegenüber Prompt Engineering: Was tatsächlich anders ist.

Der Unterschied ist nicht akademisch. Er hat praktische Folgen für alle, die mit KI bauen oder sie zuverlässig einsetzen wollen.

Prompt Engineering konzentriert sich auf die Anfrage. Wie formulieren Sie die Frage? Welche Beispiele fügen Sie ein? Wie strukturieren Sie die Anweisung, um das gewünschte Ausgabeformat zu erhalten? Prompt Engineering setzt eine relativ statische Konstellation voraus: Modell, Nutzer, Anfrage.

Context Engineering konzentriert sich auf die Umgebung. Was weiß das Modell, bevor der Nutzer etwas eingibt? Welche Informationen werden abgerufen und eingefügt? Wie wird der Gesprächsverlauf verwaltet? Welche Tools stehen bereit? Welche Einschränkungen sind im System verankert? Context Engineering behandelt das Kontextfenster des Modells als aktive Gestaltungsfläche, nicht als leere Seite.

Die Erklärung von LangChain fasst den Unterschied so: Prompt Engineering bedeutet, die richtige Frage zu stellen; Context Engineering bedeutet, die optimale Umgebung zu schaffen, in der das Modell die richtige Lösung erkennt und ausführt — oft ohne dass der Nutzer sie überhaupt erfragen muss.

Bei gelegentlicher KI-Nutzung reicht Prompt Engineering meist aus. Sie öffnen ChatGPT, fragen etwas und verfeinern bei einer unpassenden Antwort die Formulierung. Das ist in Ordnung.

In KI-Produktionssystemen ist Prompt Engineering nur die Eintrittskarte. Die durchschnittliche bereitgestellte Anwendung des Jahres 2026 umfasst Abruf, Tool-Aufrufe, Verwaltung des Gesprächsverlaufs, strukturierten Zustand, bedingtes Routing und manchmal die Koordination mehrerer Modelle. All das sind Kontextentscheidungen. Ihre Qualität bestimmt die Qualität jeder vom System erzeugten Ausgabe.

Ein Kontextfenster ist nicht nur der Text, den Sie eingeben. In jeder gut entwickelten KI-Anwendung enthält der Kontext für einen Modellaufruf typischerweise mehrere unterschiedliche Schichten:

System-Prompt Die dauerhaften Anweisungen, die Rolle, Grenzen und Verhalten des Modells definieren. Wer ist das Modell? Was darf es tun? Was darf es niemals tun? Ein gut gestalteter System-Prompt ist kein Absatz vager Hinweise, sondern ein sorgfältig gepflegter Satz von Regeln und Rollen, der jede Antwort prägt.

Gesprächsverlauf Die Aufzeichnung dessen, was bisher gesagt wurde. Wie viel Verlauf erhalten bleibt, wie er bei zunehmender Länge komprimiert wird und was zusammenzufassen oder wortwörtlich zu bewahren ist, sind aktive Entwicklungsentscheidungen. Zu viel Verlauf vergeudet Kontextplatz. Zu wenig lässt bei komplexen mehrstufigen Aufgaben den roten Faden verlieren.

Abgerufene Dokumente Informationen, die aus einer externen Wissensquelle geholt und zur Inferenzzeit in den Kontext eingefügt werden. Das ist Retrieval-Augmented Generation (RAG), eine der wichtigsten Grundlagen des Context Engineering. Abrufqualität, Abschnittsgröße, Relevanzranking und Reihenfolge der Inhalte beeinflussen die Ausgabequalität.

Tool-Definitionen Die Schnittstellen, mit denen das Modell Aktionen ausführt: eine API aufrufen, Code ausführen, das Web durchsuchen oder in eine Datenbank schreiben. Wie Tools beschrieben sind, welche Parameter sie offenlegen und welche Tools in einem bestimmten Kontext verfügbar sind, sind Context-Engineering-Entscheidungen.

Gedächtnis Dauerhafte Informationen über Nutzer, Projekt oder frühere Interaktionen. Kurzzeitgedächtnis können die letzten Austausche sein. Langzeitgedächtnis kann Nutzerpräferenzen, frühere Entscheidungen und angesammeltes Wissen über laufende Arbeit umfassen. Die Analyse von Weaviate beschreibt Gedächtnis als die Schicht, mit der KI-Systeme im Laufe der Zeit wirklich personalisiert werden, statt in jeder Sitzung neu zu beginnen.

Zustand und strukturierte Daten Bei Agenten-Workflows mit mehreren Schritten gehören der aktuelle Aufgabenstatus, die Ergebnisse früherer Schritte und alle strukturierten Daten, die das Modell zum Schlussfolgern benötigt, zum Kontext und müssen sorgfältig verwaltet werden.

Die Kunst des Context Engineering besteht darin, diese Schichten für jeden einzelnen Aufruf richtig zusammenzustellen: zu wählen, was einbezogen, komprimiert, abgerufen und weggelassen wird, sodass das Modell genau das Nötige und nichts Signalverwässerndes erhält.

Warum Context Engineering zur entscheidenden Fähigkeit geworden ist.

Drei Veränderungen haben Context Engineering für die meisten ernsthaften KI-Arbeiten wichtiger gemacht als Prompt Engineering.

Der Aufstieg agentischer KI. Wenn ein Modell einmal als Antwort auf eine einzelne Frage läuft, ist Prompt Engineering am wichtigsten. Wenn ein Modell in einer Schleife läuft, Aktionen ausführt, Ergebnisse erhält und über den nächsten Schritt entscheidet, entwickelt sich der Kontext bei jedem Schritt weiter. Die Qualität des Agenten hängt fast vollständig davon ab, ob der Kontext in jedem Schritt die richtigen Informationen für die richtige Entscheidung enthält. Die Analyse von Deepset bezeichnet dies als zentralen Treiber: Je autonomer KI-Systeme werden, desto mehr wird Kontextdesign zur dominierenden Entwicklungsherausforderung.

Längere Kontextfenster, dasselbe Knappheitsproblem. Modelle unterstützen inzwischen Kontextfenster mit einer Million Tokens. Das scheint das Problem zu lösen, tut es aber nicht. Ein Fenster mit einer Million Tokens voller irrelevanter Informationen liefert schlechtere Ergebnisse als ein 100.000-Token-Fenster mit genau den richtigen Informationen. Mehr Kapazität beseitigt die Notwendigkeit der Auswahl nicht. Sie erhöht den Einsatz. Sorgloses Context Engineering im großen Maßstab bedeutet mehr Rauschen, nicht weniger.

Die Lücke zwischen Demos und Produktion. Es ist leicht, eine beeindruckende KI-Demo zu erstellen: Sie gestalten den Kontext von Hand, wählen Eingaben aus und führen sie einmal aus. Schwer ist es, ein KI-System zu bauen, das für Tausende Nutzer über Tausende unterschiedliche Eingaben und Zustände hinweg konsistent funktioniert. Der Unterschied lässt sich fast immer auf Context Engineering zurückführen. Die Demo funktionierte, weil jemand manuell gute Kontextentscheidungen traf. Das Produktionssystem scheitert, weil diese Entscheidungen nie systematisiert wurden.

Es gibt eine Ebene des Context Engineering, die die meisten Tools und Frameworks fast vollständig ignorieren: Ihren persönlichen Kontext.

System-Prompts, Tool-Definitionen und abgerufene Dokumente sind Entwicklungsprobleme, die Teams auf Anwendungsebene lösen können. Doch es gibt Kontext, der spezifisch für Sie ist: die Forschung der vergangenen sechs Monate, Meetings mit Ihren Kunden, Entscheidungen Ihres Teams im letzten Quartal und das angesammelte Wissen Ihrer besonderen Arbeitssituation. Keine KI-Anwendung wird mit diesem Kontext ausgeliefert. Sie kann es nicht. Er gehört Ihnen.

Das macht die meisten KI-Tools für ernsthafte Wissensarbeit so frustrierend. Das Modell ist leistungsfähig, die Infrastruktur solide. Doch jede Sitzung startet bei null, und die Distanz zwischen „was das Modell über die Welt weiß“ und „was das Modell über Ihre Arbeit weiß“ begrenzt jede Ausgabe.

Für die meisten Menschen erfolgt der Wechsel von Prompt Engineering zu Context Engineering in drei Stufen.

Stufe 1: Bewusstes Systemdesign. Behandeln Sie den System-Prompt nicht mehr als Nachgedanken. Definieren Sie klar, was das Modell ist und nicht ist, was es immer und was es nie tun soll. Behandeln Sie den System-Prompt wie Code: versionieren, Änderungen testen, pflegen.

Stufe 3: Zustandsverwaltung für mehrstufige Aufgaben. Wenn eine Aufgabe mehrere Schritte oder Modellaufrufe umfasst, verfolgen Sie den Zustand explizit. Was wurde entschieden? Was wurde erstellt? Was muss noch geschehen? Geben Sie diesen Zustand bewusst weiter, statt zu hoffen, dass das Modell ihn allein aus dem Gesprächsverlauf rekonstruiert.

Das Grundprinzip aller drei Stufen ist gleich: Die Ausgabequalität des Modells ist eine Funktion der Qualität seines Eingabekontexts. Diesen Kontext zu entwickeln, ist die Arbeit.

Ist Context Engineering nur für Entwickler? Nein. Der Begriff stammt aus der Softwareentwicklung, doch die Praxis gilt für jeden, der regelmäßig KI-Tools nutzt. Zu entscheiden, welche Informationen vor einer Frage an einen KI-Assistenten einbezogen werden, einen Ordner relevanter Dokumente für eine Sitzung aufzubauen oder eine Wissensbasis für Arbeitsnotizen zu verwenden, sind Formen von Context Engineering — auch ohne eine Zeile Code.

Was ist der Unterschied zwischen RAG und Context Engineering? RAG (Retrieval-Augmented Generation) ist ein Bestandteil des Context Engineering: der Teil, der relevante Dokumente abruft und in den Kontext einfügt. Context Engineering ist die umfassendere Disziplin, die außerdem System-Prompt-Design, Gedächtnisverwaltung, Tool-Definition, Umgang mit Gesprächsverlauf und Zustandsverfolgung in mehrstufigen Workflows umfasst.

Macht ein größeres Kontextfenster Context Engineering weniger wichtig? Nein. Größere Kontextfenster geben mehr Kapazität, vermindern aber nicht die Bedeutung dessen, was darin steht. Ein unfokussierter Kontext mit einer Million Tokens liefert schlechtere Ergebnisse als ein fokussierter Kontext mit 100.000 Tokens. Die Disziplin, Informationen auszuwählen, zu ordnen und zu komprimieren, wird mit wachsender Kapazität wichtiger, nicht weniger.

Wie hängen Context Engineering und KI-Agenten zusammen? Context Engineering ist grundlegend für Agentendesign. Ein Agent ist nur so zuverlässig wie der Kontext, den er in jedem Schritt erhält. Qualität von System-Prompt, Tool-Definitionen, abgerufenem Zustand und Gedächtnisverwaltung bestimmen, ob ein Agent gute Entscheidungen trifft oder abdriftet, halluziniert oder in Schleifen gerät. Bei agentischen Anwendungen sind die Folgen schlechten Context Engineering am deutlichsten sichtbar.

Context Engineering ist kein Trend. Es ist die Disziplin, die KI-Anwendungen auf dem Qualitätsniveau funktionieren lässt, das Nutzer tatsächlich benötigen. Der Wandel von „bessere Fragen stellen“ zu „bessere Informationsumgebungen gestalten“ ist der Wandel vom Nutzen von KI zum Bauen mit ihr — und vom Hinnehmen inkonsistenter Ergebnisse zum Erwarten verlässlicher Ergebnisse.

Der praktische Test lautet, ob dieser Ansatz einen wiederholbaren Teil der Arbeit verbessert, ohne seine Quellen, Kosten oder Fehlermodi zu verbergen. Beginnen Sie mit einer repräsentativen Aufgabe, behalten Sie bei folgenreichen Fehlern eine menschliche Kontrollinstanz bei und bewerten Sie das Ergebnis neu, wenn sich Modelle und Produkte ändern.

Tool-Verzeichnis ansehen →