Context Engineering: Warum der perfekte Prompt nur ein Baustein ist
Context Engineering ist die Disziplin hinter zuverlässigen KI-Systemen – und Prompt Engineering nur ein Baustein davon. Woher der Begriff kommt, warum mehr Kontext nicht automatisch besser ist und was das für KMU heißt.
Context Engineering klingt nach dem nächsten Begriff, den dir jemand auf LinkedIn als Karriere-Pflicht verkaufen will. Ist er auch – die halbe Timeline besteht aus genau diesen Posts. Dahinter steckt aber etwas, das in jedem LLM-Produkt arbeitet, das im Alltag verlässlich tut, was es soll. Und der Begriff rückt eine Sache gerade, die im Prompt-Hype der letzten Jahre unterging: Der einzelne Prompt ist nicht der Hebel. Er ist einer von vielen.
Wer 2026 ernsthaft etwas mit Sprachmodellen baut – einen Support-Bot, einen Agenten, eine Suche über die eigene Doku –, scheitert selten am Modell. Die Modelle sind gut. Gescheitert wird am Kontext. Am falschen, am fehlenden, am überladenen. Context Engineering ist die Disziplin, die genau das in den Griff nimmt, und Prompt Engineering steckt da als ein Teil drin. Kein Vorgänger, keine abgelöste Vorstufe.
TL;DR
Context Engineering ist die Disziplin, das gesamte Informationsumfeld eines Sprachmodells bewusst zu bauen – System-Prompt, Beispiele, abgerufenes Wissen, Gedächtnis, Tools, Historie. Prompt Engineering ist ein Teil davon, kein überholter Vorläufer.
- Der Begriff entstand im Juni 2025 – geprägt von Shopify-Chef Tobi Lütke, popularisiert von Andrej Karpathy, definiert von Philipp Schmid und Anthropic.
- Das Kontextfenster ist eine begrenzte Ressource. Mehr Text heißt nicht mehr Qualität – ab einer gewissen Länge wird es messbar schlechter.
- Für KMU heißt das: Nicht ein anderes Modell kaufen, sondern die Kontext-Architektur sauber bauen. RAG, Memory, Tool-Anbindung, Token-Management.
Wer den Begriff geprägt hat – und warum das keine Trivia ist
Der Begriff hat ein Geburtsdatum, und das ist erstaunlich frisch. Am 18. Juni 2025 schrieb Shopify-Gründer Tobi Lütke auf X, er möge „context engineering“ lieber als „prompt engineering“ – es beschreibe die eigentliche Kernkompetenz besser, nämlich die Kunst, einem Modell allen Kontext zu liefern, den es braucht, um eine Aufgabe überhaupt lösen zu können. Eine Woche später legte Andrej Karpathy nach, damals noch Gründer von Eureka Labs und nicht, wie manche Sekundärquellen es rückdatieren, bei Anthropic – dorthin wechselte er erst im Mai 2026. Karpathy nannte es „
„the delicate art and science of filling the context window with just the right information for the next step“.
Dass der Begriff hängenblieb, lag nicht an einem einzelnen Tweet. Harrison Chase von LangChain lieferte zwei Tage vor Karpathy die Arbeitsdefinition, die heute am häufigsten zitiert wird. Simon Willison, Django-Mitschöpfer und einer der nüchternsten LLM-Kommentatoren, sagte voraus, dass der Begriff bleiben würde. Und Walden Yan von Cognition hatte die Prinzipien schon einige Tage vor Lütkes Tweet aufgeschrieben, ohne sie so zu nennen. Es gibt also keinen Erfinder. Es gibt eine Begriffskoaleszenz im Juni 2025, an der ein halbes Dutzend Leute beteiligt war.
Warum ich das so genau aufdrösele: Wenn du den Begriff in deiner Firma einführst, wirst du gefragt, woher er kommt. Und die ehrliche Antwort – „mehrere Leute, fast gleichzeitig, niemand zuerst“ – ist glaubwürdiger als die LinkedIn-Version mit dem einen, großen Visionär.
Die eigentliche Definition – Kontext ist alles, was vor dem Modell landet
Die zugänglichste Definition stammt von Philipp Schmid, Senior AI Developer Relations Engineer bei Google DeepMind. Context Engineering sei die Disziplin, dynamische Systeme zu bauen, die einem Modell die richtigen Informationen und Werkzeuge im richtigen Format zur richtigen Zeit geben. Sein Satz, der seitdem durch jede zweite Präsentation wandert:
„Most agent failures are not model failures anymore, they are context failures.“
Auf Deutsch und ohne Pathos: wenn dein Agent Mist baut, liegt das meistens nicht am Modell, sondern an dem, was du ihm mitgegeben hast.
Schmid zählt sieben Komponenten auf, die zusammen den Kontext ergeben: der System-Prompt, der eigentliche User-Input, das Kurzzeitgedächtnis aus der laufenden Unterhaltung, ein Langzeitgedächtnis, abgerufenes Wissen aus einer Datenquelle, die verfügbaren Tools und das Format, in dem die Antwort rauskommen soll. Anthropic hat das im September 2025 architektonisch formalisiert und beschreibt Context Engineering als die Aufgabe, aus all den Tokens, die während einer Inferenz im Fenster landen können, die optimale Menge zu kuratieren. Klar, Anthropic verkauft mit Claude das Modell und hat ein Interesse daran, dass du dich um den Kontext kümmerst statt um die Konkurrenz – die Definition trägt trotzdem, weil sie technisch sauber ist.
Der Prompt ist in dieser Aufzählung eine Zeile von sieben. Genau hier sitzt die Brücke zum Prompt Engineering, und sie ist simpler, als die Buzzword-Debatte glauben macht:
| Dimension | Prompt Engineering | Context Engineering |
|---|---|---|
| Einheit | ein String, eine Anweisung | das gesamte Kontextfenster pro Schritt |
| Zeit | statisch hinterlegt | dynamisch, pro Anfrage neu zusammengebaut |
| Bestandteile | Wortwahl, Format, Rolle, Beispiele | dazu RAG, Memory, Tools, Tool-Outputs, Historie, Compaction |
| wer macht's | Mensch tippt | System konstruiert vor dem Modell-Call |
Prompt Engineering ist die „Gestaltung“ der statisch hinterlegten Anweisungen. Context Engineering umfasst das und kommt um alles herum, was zur Laufzeit dazukommt. Wer Context Engineering als Nachfolger im Sinne von Ablösung liest, hat beides leider missverstanden.
Warum das wichtig ist – das Kontextfenster ist kein Gratis-Speicher
Die naheliegende Reaktion auf all das lautet: Kontextfenster werden doch immer größer, eine Million Token bei Gemini 3.x, da kippe ich halt alles rein. Funktioniert nicht. Und das ist der Punkt, an dem Context Engineering von einer Begriffsklauberei zu einer Ingenieursfrage wird.
Chroma Research hat im Juli 2025 achtzehn Modelle getestet:,darunter: GPT-4.1, Claude 4, Gemini 2.5, Qwen3 und einen Effekt dokumentiert, den sie „Context Rot“ nennen. Modelle nutzen ihren Kontext nicht gleichmäßig. Je länger der Input, desto unzuverlässiger die Leistung, auch wenn alles technisch ins Fenster passt. Auf einem Gedächtnis-Benchmark schnitten alle Modelle bei einem fokussierten Prompt von rund 300 Token deutlich besser ab als bei rund 113.000 Token mit derselben relevanten Information drin. Hier das Hersteller-Sternchen: Chroma verkauft eine Vektordatenbank und hat ein handfestes Interesse daran, dass „mehr reinkippen“ nicht die Lösung ist. Die Befunde wurden von unabhängiger Seite reproduziert, die Methodik ist offengelegt – ich nehme sie ernst, aber nicht als neutrale Wahrheit vom Berg.
Der Effekt ist nicht neu. Schon 2023 zeigte die Stanford-Arbeit „Lost in the Middle“ eine U-förmige Kurve: Modelle finden Information am Anfang und Ende des Kontexts gut, in der Mitte schlecht. Damals fiel die Trefferquote bei GPT-3.5-Turbo von rund 74 Prozent auf der ersten Position auf etwa 60 Prozent in der Mitte. Ein alter Befund, drei Jahre ist in diesem Feld eine Ewigkeit, und neuere Long-Context-Modelle schwächen den Effekt auf einfachen Suchaufgaben ab. Bei echtem semantischem Verständnis bleibt die Schwäche aber. Anthropic begründet das mit einem „attention budget“ – die Transformer-Architektur erzeugt Beziehungen zwischen allen Token, und je länger der Kontext, desto dünner verteilt sich die Aufmerksamkeit.
Dazu kommt das Offensichtliche, das in der Architektur-Diskussion gern vergessen wird. Jeder Token kostet. Bei Claude Opus 4.8 sind das 5 Dollar pro Million Input-Token, und ein Agent, der in Schleifen läuft, schaufelt seinen Kontext bei jedem Schritt erneut durchs Modell. Wer ungefiltert alles mitschickt, zahlt für Müll und macht das Ergebnis schlechter. Beides gleichzeitig.
Und dann sind da die Fehler, die kein Modellfehler sind. Drew Breunig hat vier Versagensmuster katalogisiert, die sich rein aus dem Kontext ergeben: Eine Halluzination landet im Fenster und wird danach brav weiterzitiert. Zu viel Kontext drängt das Trainingswissen in den Hintergrund. Überflüssige Information wird trotzdem verwurstet. Oder zwei Quellen widersprechen sich, und das Modell weiß nicht, welcher es glauben soll. Keiner dieser Fälle wird besser, wenn du ein teureres Modell kaufst.
Prompt Engineering ist nicht tot – es ist eine Schicht geworden
Es gab im Sommer 2025 die übliche BWL-Analysten-Schlagzeile, Prompt Engineering sei „out“. Das ist Verkaufssprech mit einem wahren Kern, falsch zugespitzt. Prompt-Qualität ist nicht verschwunden, sie ist eine Ebene im Stack geworden. Der System-Prompt bleibt der Ort, an dem du dem Modell Rolle, Format und Leitplanken gibst. Few-Shot-Beispiele bleiben das Mittel, um Verhalten zu zeigen statt zu beschreiben. Was sich geändert hat: Diese Dinge sind nicht mehr das ganze Spiel, sondern ein paar Felder auf einem größeren Brett.
Wer in der eigenen Firma noch über den „perfekten Prompt“ diskutiert, während die Antworten an fehlendem Unternehmenswissen scheitern, hat das Problem auf der falschen Ebene. Der perfekteste Prompt der Welt holt keine Information her, die nie in den Kontext gekommen ist.
Die Bausteine – kurz und ohne Werkzeugkasten-Romantik
Vier Dinge tauchen in fast jeder ernsthaften Kontext-Architektur auf. RAG – Retrieval-Augmented Generation, seit Lewis et al. 2020 etabliert – holt vor der Antwort die passenden Stücke aus einer Wissensbasis und schiebt sie ins Fenster. Das reduziert Halluzinationen und bringt aktuelle Daten rein, ohne das Modell neu zu trainieren. Context Engineering ist aber nicht „RAG, neu lackiert“; RAG ist eine Technik im Kasten, nicht der Kasten.
Memory ist die Persistenz jenseits des Fensters: die laufende Unterhaltung als Kurzzeitgedächtnis, eine Datenbank oder strukturierte Notizen als Langzeitgedächtnis. Die Tool-Anbindung läuft heute oft über das Model Context Protocol, das Anthropic im November 2024 herausbrachte und am 9. Dezember 2025 an die Agentic AI Foundation übergab – einen Fonds unter dem Dach der Linux Foundation, gemeinsam gegründet mit Block und OpenAI. Der Marketing-Vergleich „USB-C für AI“ ist griffig und stammt naturgemäß von den Anbietern selbst. Compaction schließlich verdichtet lange Verläufe zu Zusammenfassungen, bevor das Fenster überläuft.
Das Muster hinter allen vieren ist dasselbe: nicht alles vorhalten, sondern das Richtige zur richtigen Zeit nachladen. Wie ein Mensch, der nicht jede Datei auswendig kennt, sondern weiß, in welchem Ordner sie liegt.
Was das für KMU heißt – ohne Beratungs-Powerpoint
Die gute Nachricht vorweg: Der Einstieg ist kein Big-Bang-Projekt, sondern eine Treppe. Stufe eins ist schlicht Verstehen – den Begriff einordnen und merken, dass die Diskussion über den perfekten Prompt am eigentlichen Hebel vorbeigeht. Wenn dein Team morgens dieselben Kontextdaten von Hand in den Chat tippt, bist du längst bei Stufe zwei: Inventarisieren, welche Quellen eigentlich in den Kontext gehörten – CRM, Wiki, Ticketsystem, Handbücher.
Stufe drei ist der erste RAG-Prototyp an einer eng abgegrenzten Quelle, etwa dem Produkthandbuch oder der FAQ. Der Auslöser dafür ist meist Schmerz: Das Modell halluziniert bei firmenspezifischen Fragen, weil es sie nie zu sehen bekam. Läuft das stabil, kommt mit der Tool-Anbindung Stufe vier, sobald sich wiederholbare, mehrschrittige Aufgaben mit klarem Nutzen abzeichnen. Und Stufe fünf – Langzeit-Memory und Token-Management – wird erst dann relevant, wenn Kosten oder Antwortzeiten anfangen wehzutun. Vorher ist das verfrühte Optimierung.
Mein nüchterner Take zum Schluss: Context Engineering ist kein neuer Hype, sondern der Name für die Arbeit, die schon immer den Unterschied zwischen einem beeindruckenden Demo und einem brauchbaren Produkt gemacht hat. Der Prompt war nie die ganze Geschichte. Er war nur der Teil, den man am leichtesten auf eine Konferenz-Slide schreiben konnte.