Wenn du einem Sprachmodell relevante Informationen gibst, aber an der falschen Stelle im Kontext, sinkt seine Genauigkeit um rund 20 Prozentpunkte. Das ist das Ergebnis von Nelson F. Liu et al. in “Lost in the Middle: How Language Models Use Long Contexts” (Transactions of the Association for Computational Linguistics, 2024). Relevante Dokumente in der Mitte eines 20-Dokumente-Kontexts: 55 % Trefferquote. Am Anfang: 75 %. GPT-3.5-Turbo fiel sogar unter seine eigene Baseline von 56 %. Das Modell lieferte mit Kontext schlechtere Ergebnisse als ohne ihn überhaupt.
Das ist kein Randproblem. Das ist die unsichtbare Variable hinter den meisten gescheiterten KI-Projekten.
Was Käufer glauben und was wirklich entscheidet
Die verbreitete Annahme beim Kauf einer KI-Lösung lautet: Gutes Modell plus guter Prompt ergibt gutes Ergebnis. Beide Variablen dominieren Demos und Kaufentscheidungen.
Die dritte Variable bleibt unsichtbar: Was landet wann im Kontextfenster?
Welche Dokumente lädt das System? In welcher Reihenfolge? Wie viel Verlauf bleibt erhalten, was fällt raus? All das sind Architekturentscheidungen. Sie passieren vor dem Prompt. Und sie entscheiden über die Qualität des Outputs mehr als die Modellwahl selbst.
Tobi Lütke, CEO von Shopify, hat dafür einen Begriff geprägt, den Simon Willison am 27. Juni 2025 auf simonwillison.net festgehalten hat: Context Engineering. Lütkes Definition: “the art of providing all the context for the task to be plausibly solvable by the LLM.” Andrej Karpathy lieferte die technische Aufschlüsselung: Context Engineering umfasst Aufgabenbeschreibungen, Beispiele, RAG-Ergebnisse, multimodale Daten, Tool-Outputs, Zustand sowie Komprimierung.
Keine Prompt-Frage. Eine Systemfrage.
Was passiert, wenn niemand diese Frage stellt
Klarna hat im Februar 2024 per Pressemitteilung verkündet, dass sein KI-Assistent im ersten Monat 2,3 Millionen Gespräche übernahm, entsprechend 700 Vollzeitstellen. Klingt nach Erfolg.
Bis Mitte 2025 räumte CEO Sebastian Siemiatkowski gegenüber Bloomberg ein: “We focused too much on efficiency and cost. The result was lower quality, and that’s not sustainable.” Das Unternehmen begann, Human Agents wieder einzustellen, teils dieselben Personen, die vorher entlassen worden waren.
Was war das Kernproblem? Der Assistent hatte nicht die richtigen Informationen zur richtigen Zeit. Kundendaten, Bestellhistorien, Servicekontexte: Das alles muss koordiniert ins Kontextfenster. Fehlt ein Teil davon oder sitzt er an der falschen Stelle, gibt das Modell schwache Antworten — egal wie gut das Modell selbst ist.
Das Muster ist nicht Klarna-spezifisch. Es ist strukturell.
Das Kontext-Fenster wird größer. Das Problem auch.
Hier kommt der naheliegendste Einwand: Moderne Modelle haben Kontextfenster von einer Million Token. Bei so viel Platz spielt Position doch keine Rolle mehr.
Spielt sie. Needle-in-a-Haystack-Tests an Gemini 1.5 Pro zeigen weiterhin Ausfälle in der Kontextmitte, auch bei einer Million Token. Kein Fehler veralteter Modelle — ein strukturelles Muster, das größere Kontext-Fenster abschwächen, aber nicht beseitigen.
Dazu kommt ein wirtschaftlicher Aspekt: Transformer-Inferenz skaliert quadratisch mit der Kontextlänge. Ein schlecht konstruierter Kontext, der auf ein großes Kontext-Fenster ausgedehnt wird, kostet nicht linear mehr. Er kostet überproportional mehr. Schlechtes Context Engineering wird mit größeren Kontext-Fenstern teurer, nicht billiger.
Und Produktionssysteme mit mehreren Agenten sind keine sauberen Einzel-Prompt-Tests. Jeder Agent hat eigene Systemanweisungen und einen Verlauf, der koordiniert werden muss. Ein großes Kontext-Fenster löst das Koordinationsproblem nicht.
Was Context Engineering konkret bedeutet
Karpathys Aufschlüsselung nennt sieben Bestandteile: Aufgabenbeschreibungen, Few-Shot-Beispiele, RAG-Ergebnisse, verwandte Daten, Tools, Verlauf und Komprimierung.
Jeder dieser Bestandteile ist eine Designentscheidung:
Welche Dokumente zieht das System bei einer Anfrage? In welcher Reihenfolge landen sie im Kontext? Wie wird der Verlauf komprimiert, wenn der Kontext voll wird? Was bekommt ein Agent aus dem Output eines anderen Agenten zu sehen?
Ein Prompt-Ingenieur beantwortet diese Fragen nicht — er schreibt Anweisungen. Beantwortet werden sie beim Systemdesign oder gar nicht. Und wenn sie niemand beantwortet, entsteht der Kontext zufällig. Die Grundlagen des Prompt Engineerings helfen, die richtigen Anweisungen zu schreiben. Aber Anweisungen sind nur ein Teil dessen, was im Kontext landet.
Warum das jetzt wichtiger wird
Laut Gartner-Prognose vom Juni 2025 werden 40 % aller Enterprise-Applikationen bis Ende 2026 KI-Agenten enthalten, ein Sprung von unter 5 % im Jahr 2025. Gleichzeitig erwartet Gartner, dass über 40 % dieser Agentic-AI-Projekte bis Ende 2027 abgebrochen werden.
Agenten multiplizieren das Kontextfenster-Problem. Jeder Agent im Unternehmenseinsatz operiert in einem eigenen Kontext, der koordiniert werden muss. Ein schlechtes Design eskaliert nicht linear — es eskaliert mit der Anzahl der Agenten.
Wer jetzt eine Agentic-AI-Infrastruktur aufbaut, ohne Context Engineering als Architekturfrage zu behandeln, baut auf wackeligem Fundament.
Drei Fragen vor jeder KI-Integration
Bevor du ein Modell evaluierst, lohnen diese drei Fragen:
Welche Informationen braucht das Modell für diese Aufgabe? Und woher kommen sie?
In welcher Reihenfolge sollen diese Informationen im Kontext erscheinen?
Was passiert, wenn der Kontext voll wird: Was bleibt, was fällt weg?
Wer diese Fragen beim Kauf nicht stellt, kauft eine Lösung, deren Qualität von der Antwort abhängt, ohne zu wissen, wer die Antwort gibt. Die Studie zeigt, was passiert, wenn niemand sie gibt: Das Modell liefert schlechtere Ergebnisse als ohne Kontext überhaupt.
Context Engineering endet nicht beim Go-live
Die drei Fragen sind der Einstieg. Nicht der Abschluss.
Context Engineering ist keine Einrichtungsaufgabe. Es ist eine fortlaufende Architekturdisziplin: Wenn sich Datenquellen ändern, ändern sich die relevanten Kontexte. Wenn Agenten hinzukommen, multiplizieren sich die Koordinationsanforderungen. Wenn das Produkt wächst, wächst die Komplexität mit.
Die Unternehmen, die KI-Projekte nach sechs Monaten abbrechen, haben das meistens nicht am Modell erkannt. Und nicht am Prompt. Sie haben erkannt, dass niemand verantwortlich war für das, was im Kontext landet — und dass diese Frage beim Kauf niemand gestellt hat.
Wie das konkret aussieht, zeigen unsere Use Cases — von der automatisierten Kundenkommunikation bis zum internen Wissensmanagement.
Die Frage ist nicht, ob du das richtige Modell gewählt hast. Die Frage ist, ob jemand in deinem Team für den Kontext verantwortlich ist und auch bleibt.