Was ist Context Engineering? Gib der KI die richtigen Infos statt mehr Worte

Jahrelang lautete der Standardrat: Schreib einen besseren Prompt. Dann begannen viele, Assistenten zu nutzen, die über Dutzende Schritte hinweg Dateien lesen, im Web suchen und Tools ausführen – und plötzlich zeigte sich ein anderes Problem. Das Modell scheiterte nicht, weil die Anweisung schlecht formuliert war. Es scheiterte, weil es die falschen Informationen vor sich hatte oder viel zu viele davon. Für die Lösung dieses Problems hat sich der Begriff Context Engineering durchgesetzt. Dieser Ratgeber erklärt, was Context Engineering ist, wie es sich vom Prompt Engineering unterscheidet, was tatsächlich im Kontext eines Modells landet, warum mehr nicht besser ist und wie du es anwendest – egal, ob du mit ChatGPT chattest oder einen Agenten baust.

Was Context Engineering eigentlich bedeutet

Ein Sprachmodell hat zwischen zwei Anfragen kein Gedächtnis und sieht weder deinen Bildschirm noch deine Dateien noch dein Unternehmen. Bei jeder Antwort arbeitet es ausschließlich mit dem Text (und den Bildern), die es in genau dieser Anfrage bekommt: seinem Kontextfenster. Context Engineering, also die bewusste Gestaltung des Kontexts, heißt zu entscheiden, was in dieses Fenster kommt – was hinein soll, was draußen bleibt, in welcher Form und in welcher Reihenfolge –, damit das Modell für den nächsten Schritt alles hat, was es braucht, und kaum etwas darüber hinaus.

Richtig bekannt wurde der Begriff im Juni 2025, als Shopify-CEO Tobi Lütke sagte, er ziehe ihn „Prompt Engineering“ vor, und Andrej Karpathy ihm zustimmte. Karpathy beschrieb es als „the delicate art and science of filling the context window with just the right information for the next step“ – auf Deutsch etwa: die feine Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen. Das Engineering-Team von Anthropic definierte es später als die Gesamtheit der Strategien, mit denen man die bestmögliche Auswahl an Token zusammenstellt und pflegt, während ein Modell arbeitet. Andere Worte, dieselbe Idee: Der Prompt, den du eintippst, ist nur ein Teil dessen, was das Modell liest – und oft der kleinste.

Ein hilfreiches Bild: Das Modell ist ein sehr fähiger Auftragnehmer, der jeden Morgen mit kompletter Amnesie ankommt. Was auf dem Schreibtisch liegt, wenn er sich hinsetzt, ist alles, was er über den Auftrag weiß. Context Engineering heißt, diesen Schreibtisch vorzubereiten.

Context Engineering vs. Prompt Engineering

Die beiden sind keine Konkurrenten. Beim Prompt Engineering geht es darum, wie du eine Anweisung formulierst: Rolle, Aufgabe, Einschränkungen und Format. Dieses Handwerk behandeln unsere Grundlagen des Prompt Engineering. Context Engineering setzt eine Ebene darüber an und kümmert sich um alles, was die Anweisung umgibt.

• Umfang – Prompt Engineering gestaltet eine Nachricht. Context Engineering gestaltet das gesamte Paket, das das Modell erhält: Systemprompt, Gesprächsverlauf, Dokumente, Beispiele und Tool-Ergebnisse.
• Zeitpunkt – ein Prompt wird meist einmal geschrieben. Der Kontext ist oft dynamisch: Er ändert sich mit jeder Runde eines Gesprächs und mit jedem Schritt eines Agenten.
• Der Fehler, den es behebt – Prompt Engineering behebt „Es hat falsch verstanden, was ich wollte“. Context Engineering behebt „Es hat es verstanden, aber ihm fehlten die Fakten“ und „Es hatte so viel Material, dass es sich verzettelt hat“.

Ein brillant formulierter Prompt mit dem falschen Kontext liefert trotzdem eine selbstsichere, falsche Antwort. Ein schlichter Prompt mit genau dem richtigen Kontext funktioniert oft auf Anhieb. Deshalb hat sich der Begriff bei Leuten durchgesetzt, die KI-Produkte bauen – er gilt aber genauso für alle, die einen Chat-Assistenten ernsthaft nutzen.

Was im Kontext eines Modells landet

Ob du in ein Chatfenster tippst oder eine App baust: Der Kontext setzt sich immer aus denselben wenigen Zutaten zusammen.

• Anweisungen – der Systemprompt oder die benutzerdefinierten Anweisungen, die Rolle, Regeln und Ton festlegen. Wie du sie schreibst, zeigt unser Leitfaden für System-Prompts.
• Die Aufgabe – deine aktuelle Anfrage, idealerweise mit Ziel und Zielgruppe, nicht nur mit der gewünschten Handlung.
• Beispiele – ein paar Muster für gute Ergebnisse. Zwei oder drei gut gewählte Beispiele schlagen oft eine ganze Seite voller Regeln; warum, erklärt unser Beitrag zu Few-Shot- und Zero-Shot-Prompting.
• Wissen – die Dokumente, Daten oder Suchergebnisse, aus denen die Antwort kommen soll, entweder von dir eingefügt oder automatisch abgerufen (oft RAG genannt, Retrieval-Augmented Generation).
• Verlauf und Gedächtnis – frühere Runden des Gesprächs und alles, was das Tool über dich oder das Projekt gespeichert hat.
• Tools und ihre Ergebnisse – Beschreibungen dessen, was das Modell tun darf (suchen, Code ausführen, eine Datei lesen), und die Ausgabe, die jedes Mal zurückkommt, wenn es das tut.
• Ausgabeformat – die Struktur, die du zurückerwartest, etwa eine Tabelle, JSON oder eine Wortgrenze.

Jede dieser Zutaten braucht Platz, und alle konkurrieren um die Aufmerksamkeit des Modells. Context Engineering heißt vor allem, sie auszubalancieren: von allem genug für die Aufgabe und nichts, was in eine andere Richtung zieht.

Warum mehr Kontext nicht besser ist

Kontextfenster sind auf Hunderttausende Token angewachsen, manche Modelle verarbeiten eine Million oder mehr. Da liegt es nahe, einfach alles hineinzukippen und das Modell sortieren zu lassen. In der Praxis geht das meist nach hinten los, und zwar aus vier Gründen:

• Die Aufmerksamkeit verdünnt sich – die bekannte Studie „Lost in the Middle“ hat gezeigt, dass Modelle Informationen am Anfang und am Ende einer langen Eingabe deutlich besser nutzen als solche, die in der Mitte vergraben sind. Anthropic beschreibt einen verwandten Effekt als Context Rot: Je größer der Kontext, desto schlechter kann das Modell sich an einzelne Teile davon erinnern und sie verwenden.
• Ablenkung – irrelevantes Material ist nicht neutral. Ein halb passendes Dokument ist eine Einladung, einen Satz in die Antwort zu ziehen, der dort nichts verloren hat.
• Widersprüche – zwei Versionen einer Richtlinie, eine alte und eine neue Anweisung, eine Notiz, die den Daten widerspricht. Das Modell folgt vielleicht der einen oder der anderen oder vermischt beide – und sagt dir nicht immer, dass es sich entscheiden musste.
• Kosten und Tempo – jedes Token wird bei jedem Aufruf verarbeitet, aufgeblähter Kontext macht Apps also langsamer und teurer im Betrieb.

Wenn ein fähiges Modell eine schlechte Antwort gibt, steckt meist eines von vier Kontextproblemen dahinter: Etwas hat gefehlt, etwas war veraltet, zwei Dinge haben sich widersprochen, oder der nützliche Teil war unter Rauschen vergraben. Es lohnt sich, das zu klären, bevor du den Prompt zum fünften Mal umformulierst. Fehlender Kontext ist außerdem eine Hauptursache für KI-Halluzinationen: Wenn die Fakten nicht da sind, füllt das Modell die Lücke mit etwas, das plausibel klingt.

Context Engineering im Chat-Alltag

Du musst nichts programmieren, um davon zu profitieren. Wenn du ChatGPT, Claude oder Gemini für die Arbeit nutzt, betreibst du schon jedes Mal Context Engineering, wenn du entscheidest, was du hineinkopierst – ob gut oder schlecht. Ein paar Gewohnheiten machen einen echten Unterschied:

• Ein Briefing voranstellen – gib vor der eigentlichen Anfrage den Hintergrund, den eine neue Kollegin bräuchte: für wen das Ergebnis ist, was schon entschieden ist und wie ein gutes Ergebnis aussieht.
• Die Quelle einfügen, nicht deine Zusammenfassung davon – wenn die Antwort zu einem Dokument passen muss, füge den relevanten Teil dieses Dokuments ein.
• Kürzen, bevor du einfügst – die drei relevanten Absätze eines Vertrags schlagen das komplette 40-seitige PDF.
• Die dauerhaften Speicherplätze pflegen – benutzerdefinierte Anweisungen, Projekte mit hochgeladenen Dateien und gespeicherte Erinnerungen sind Kontext, der automatisch geladen wird. Halte sie kurz und aktuell: Eine veraltete Erinnerung an einen Job, den du letztes Jahr verlassen hast, ist trotzdem Kontext.
• Neu anfangen, wenn ein Gespräch abdriftet – in einem langen Chat sammeln sich verworfene Ideen und korrigierte Fehler. Wenn sich in die Antworten altes Material mischt, öffne einen neuen Chat mit einer sauberen Zusammenfassung.

Ein wiederverwendbares Briefing sieht so aus:

Wenn die Antwort aus einer bestimmten Auswahl an Dokumenten kommen muss, nimmt dir ein Tool, das auf deinen eigenen Quellen aufbaut, einen Großteil dieser Arbeit ab. Wie das in der Praxis aussieht, zeigt unser Ratgeber NotebookLM nutzen.

Context Engineering für Agenten und KI-Apps

Am wichtigsten wird Context Engineering, wenn ein Modell über viele Schritte hinweg arbeitet. Ein KI-Agent, der sucht, Dateien liest und Tools aufruft, erzeugt mit jeder Aktion neuen Kontext. Ohne Steuerung füllt sich sein Fenster mit veralteten Tool-Ausgaben, bis er den Faden verliert. Die Techniken, mit denen Teams das verhindern, sind überraschend bodenständig:

• Just in time abrufen – statt alle Dokumente vorab zu laden, behältst du schlanke Verweise (Dateipfade, Links, gespeicherte Abfragen) und lässt den Agenten holen, was er braucht, genau dann, wenn er es braucht.
• Verdichten – nähert sich eine lange Sitzung der Grenze, fass das Wichtige zusammen (Entscheidungen, offene Probleme, zentrale Fakten) und mach mit der Zusammenfassung weiter. Alte Tool-Ergebnisse zu löschen ist die einfachste Variante.
• Notizen außerhalb des Fensters führen – lass den Agenten eine Fortschrittsdatei oder To-do-Liste führen, die er erneut lesen kann, damit wichtige Zwischenstände erhalten bleiben, auch wenn das Gespräch gekürzt wird.
• Die Arbeit aufteilen – Sub-Agenten erledigen eine fokussierte Aufgabe in einem sauberen Kontext und liefern eine kurze Zusammenfassung zurück, sodass der Haupt-Agent nicht jedes Detail jeder Suche mitschleppt.
• Wenige, klare Tools – Tools, die sich überschneiden und vage beschrieben sind, lassen das Modell raten, welches es nehmen soll. Auch jede Tool-Beschreibung ist Kontext.
• Den Systemprompt auf der richtigen Flughöhe ansetzen – so nennt Anthropic den Mittelweg zwischen starren Wenn-dann-Regeln und vagen Ermutigungen: konkret bei Zielen und Grenzen, flexibel beim Weg dorthin.

Das Verdichten kannst du in jedem langen Chat selbst ausprobieren, bevor du in einen neuen wechselst:

Eine Kontext-Checkliste zum Wiederverwenden

Geh diese Liste vor einer wichtigen Anfrage durch – oder wenn ein Assistent immer wieder denselben Fehler macht:

1. Ziel – sagt der Kontext, wofür das Ergebnis gedacht ist, nicht nur, was zu tun ist?
2. Quellen – liegt jede Tatsache, von der die Antwort abhängt, dem Modell wirklich vor?
3. Aktualität – ist etwas veraltet: ein altes Briefing, eine überholte Version, eine Erinnerung, die nicht mehr gilt?
4. Widersprüche – passen zwei Teile nicht zusammen? Entferne einen oder sag, welcher Vorrang hat.
5. Rauschen – was könntest du streichen, ohne etwas zu verlieren, das die Aufgabe braucht?
6. Bezeichnungen – sind Dokumente und Auszüge klar benannt und voneinander getrennt, sodass das Modell (und du) sie auseinanderhalten kann?
7. Reihenfolge – steht die wichtigste Anweisung am Anfang oder am Ende statt mitten in einem langen eingefügten Text?
8. Format – hast du das gewünschte Ergebnis gezeigt oder beschrieben?

Du kannst das Modell auch bitten, seinen Kontext vor der Antwort zu prüfen:

Was Context Engineering nicht lösen kann

Context Engineering ist nützlich, aber keine Zauberei, und ein Teil des Hypes darum verspricht mehr, als es hält. Diese Grenzen solltest du kennen:

• Es ersetzt keine fehlenden Fähigkeiten – perfekter Kontext bringt ein kleines Modell nicht dazu, wie ein großes zu denken, und macht kein Modell zuverlässig bei einer Art von Aufgabe, die es schlecht beherrscht.
• Es garantiert keine Quellentreue – selbst mit den richtigen Dokumenten vor sich kann ein Modell falsch lesen, übertreiben oder Quellen vermischen. Prüf die Aussagen, auf die es ankommt.
• Deine Quellen bestimmen die Obergrenze – sind die Dokumente falsch, einseitig oder veraltet, sind es die Antworten auch, nur genauso selbstsicher formuliert.
• Die Suche kann danebengreifen – eine automatische Suche in deinen Dokumenten liefert manchmal einen Beinahe-Treffer, und das Modell argumentiert dann sorgfältig auf Basis der falschen Textstelle.
• Nicht vertrauenswürdige Inhalte sind ein Risiko – Webseiten, E-Mails und Dateien, die du einer KI gibst, können versteckte Anweisungen enthalten, bekannt als Prompt Injection. Behandle alles, was das Modell liest, als Daten, nicht als Befehle, und lass alles, was sich nicht rückgängig machen lässt, von einem Menschen freigeben.
• Es ist Daueraufgabe – Kontext veraltet. Anweisungen, Erinnerungen und Referenzdateien müssen gepflegt werden wie jede andere Dokumentation.

Der Kern ist einfach: Ein Modell kann nur mit dem arbeiten, was es sieht, also entscheide bewusst, was das ist. Gib ihm das Ziel, die Fakten und ein Beispiel für ein gutes Ergebnis, lass den Ballast weg und prüf das Resultat. Diese Gewohnheit verbessert Antworten zuverlässiger als jede noch so clevere Formulierung.

Quellen

• Anthropic — Effektives Context Engineering für KI-Agenten (Englisch)
• Prompt Engineering Guide (DAIR.AI) — Leitfaden zu Context Engineering (Englisch)
• Liu et al. — Lost in the Middle: Wie Sprachmodelle lange Kontexte nutzen (arXiv, Englisch)