Context Engineering 2026: Was Prompt Engineering abgelöst hat

Dein System-Prompt ist sorgfältig formuliert. Deine Anweisungen sind eindeutig. Und trotzdem verliert dein Agent nach vierzig Tool-Aufrufen den Faden und vergisst eine Bedingung, die du am Anfang ausdrücklich genannt hast.

Das ist kein Prompting-Problem. Es ist ein Kontext-Problem — und genau deshalb hat sich die Disziplin leise umbenannt.

Context Engineering ist die Praxis, in jeder Runde zu entscheiden, was tatsächlich ins Fenster des Modells gelangt. Anthropic definiert es in seinem Leitfaden dazu als „die Menge an Strategien zum Kuratieren und Pflegen des optimalen Token-Satzes während der LLM-Inferenz“ — und versteht es als natürliche Fortsetzung des Prompt Engineerings, nicht als dessen Ersatz.

Dieser Leitfaden zeigt, was wirklich im Fenster steht, warum ein größeres nicht rettet und welche drei Techniken langlaufende Agenten kohärent halten.

Der Prompt ist nur ein kleiner Teil des Kontexts

Hier der entscheidende Perspektivwechsel. Wenn Leute sagen „das Modell liest meinen Prompt“, denken sie an ein Textfeld. Was das Modell in einer Runde tatsächlich liest, ist:

• Systemanweisungen — der Verhaltensvertrag
• Tool-Definitionen — jedes bereitgestellte Tool, inklusive allem, was ein MCP-Server anbietet
• Tool-Ergebnisse — die Rohausgabe jedes bisherigen Aufrufs
• Abgerufene Dokumente — was auch immer deine RAG-Schicht geliefert hat
• Few-Shot-Beispiele — die Muster, die du vorführst
• Nachrichtenhistorie — das gesamte bisherige Gespräch

Der Prompt ist ein Punkt auf dieser Liste, und meist nicht der größte. In einem langen Agentenlauf übertreffen allein die Tool-Ergebnisse oft alles andere.

Und das macht es zu einem Engineering-Problem statt zu einer Schreibaufgabe: Ein Agent in einer Schleife erzeugt in jeder Runde neuen Kontext. Jeder Tool-Aufruf produziert Ausgaben, die für die nächste Entscheidung zählen können oder nicht. Irgendetwas muss entscheiden, was überlebt. Dieses Etwas bist du.

Prompt Engineering ist eine abgeschlossene Aufgabe — schreiben, verfeinern, ausliefern. Context Engineering ist iterativ: Die Kuratierungsentscheidung fällt in jeder einzelnen Runde.

Warum ein größeres Fenster es nicht löst

Die naheliegende Antwort lautet „auf längere Kontextfenster warten“. Das ist keine Strategie, und der Grund ist messbar.

Context Rot

Je mehr Tokens im Fenster stehen, desto schlechter kann das Modell Informationen daraus korrekt abrufen.

Das ist keine Folklore. Chroma hat im Juli 2025 einen technischen Bericht genau dazu veröffentlicht und 18 Modelle getestet — Claude Opus 4 und Sonnet 4, o3, GPT-4.1, Gemini 2.5 Pro, Qwen3 und weitere. Entscheidend: Sie hielten die Aufgabenschwierigkeit konstant und variierten nur die Eingabelänge, was den Effekt isoliert, den die meisten Long-Context-Benchmarks mit „längere Eingaben sind schwerere Aufgaben“ vermischen.

Ihr Befund über alle Experimente hinweg: Die Leistung sinkt konsistent mit wachsender Eingabelänge. Der vollständige Code ist öffentlich, das Ergebnis also reproduzierbar und nicht anekdotisch.

Anthropic kommt zum selben Schluss und hält fest, dass manche Modelle sanfter degradieren, der Effekt aber „bei allen Modellen auftritt“.

Dass eine Information formal im Fenster steht, heißt nicht, dass das Modell sie zuverlässig nutzt.

Der architektonische Grund

Das ist kein Bug, den jemand patcht. Transformer lassen jedes Token auf jedes andere achten, was n² paarweise Beziehungen bei n Tokens bedeutet. Mit wachsender Kontextlänge wird die Fähigkeit, diese Beziehungen zu halten, immer dünner — Attention ist eine endliche Menge, die sich über eine größere Fläche verteilt.

Modelle werden zudem auf Daten trainiert, in denen kurze Sequenzen dominieren, haben also weniger Erfahrung und weniger spezialisierte Parameter für kontextweite Abhängigkeiten.

Das Ergebnis ist in Anthropics Formulierung ein Leistungsgefälle, keine harte Kante: Modelle bleiben bei langen Kontexten leistungsfähig, verlieren aber Präzision beim Abruf und beim Schlussfolgern über weite Distanzen.

Kontext ist ein Budget

Das nützliche Denkmodell — und ein vertrautes, wenn du Capacity Planning machst — ist, dass Modelle ein Attention-Budget haben. Jedes zusätzliche Token zehrt daran.

Daraus folgt das eine Prinzip, das man sich merken sollte:

Finde die kleinstmögliche Menge hochwertiger Tokens, die dein gewünschtes Ergebnis am wahrscheinlichsten macht.

Nicht die maximale Information, die hineinpasst. Das Minimum, mit dem es funktioniert.

Dass das nicht theoretisch ist, zeigt ein sauberes Experiment. Chroma ließ den Benchmark LongMemEval auf identischen Fragen zweimal laufen: mit einer fokussierten Eingabe, die nur die relevanten Ausschnitte enthält (~300 Tokens), und mit der vollständigen Eingabe samt umgebendem Gespräch (~113.000 Tokens). Gleiche Frage, gleiche Antwort in beiden Varianten vorhanden.

Jedes Modell schnitt bei der fokussierten Variante deutlich besser ab. Die Information war so oder so da — der Unterschied lag allein darin, wie viel Rauschen das Modell durchqueren musste.

Genau diese Lücke ist der gemessene Wert von Context Engineering.

Anatomie: Was ins Fenster gehört

System-Prompts — die richtige Flughöhe finden

Zwei Fehlerformen stehen an den Enden.

Am einen Extrem hardcoden Engineers spröde If-else-Logik in Prompts, um exaktes Verhalten zu skripten. Das ist brüchig und wird unwartbar. Am anderen schreiben sie vage Leitsätze, die dem Modell kein konkretes Signal geben und geteilten Kontext voraussetzen, den es nicht gibt.

Das Ziel liegt dazwischen: konkret genug zur Steuerung, flexibel genug für eigenes Urteil. Gliedere in klare Abschnitte — Hintergrund, Anweisungen, Tool-Hinweise, Ausgabeformat — und ziele auf das Minimum an Information, das dein Wunschverhalten vollständig beschreibt. Minimal heißt nicht kurz.

Tools — der häufigste Fehlerfall

Hier brechen die meisten Agenten tatsächlich, und Anthropic ist deutlich: aufgeblähte Tool-Sets, die zu viel abdecken oder mehrdeutige Entscheidungspunkte schaffen, sind der Fehler, den sie am häufigsten sehen.

Der Test ist elegant einfach:

Wenn ein menschlicher Engineer nicht eindeutig sagen kann, welches Tool in einer Situation zu verwenden ist, kann man das von einem KI-Agenten erst recht nicht erwarten.

Jede Tool-Definition kostet außerdem in jeder Runde Tokens. Zwanzig Tools, die du „für alle Fälle“ bereitgestellt hast, sind zwanzig Beschreibungen, die mit der eigentlichen Aufgabe um Aufmerksamkeit konkurrieren.

Die Chroma-Studie beziffert, warum das schadet. Sie testete Distraktoren — Inhalte, die thematisch relevant wirken, die Frage aber nicht beantworten — und fand, dass bereits ein einzelner Distraktor die Leistung gegenüber einer sauberen Basislinie messbar senkt. Vier davon verstärken den Schaden, und der Effekt wächst mit der Eingabelänge.

Auch die Fehlerformen unterscheiden sich je nach Modellfamilie, was bei der Auswahl relevant ist: Claude-Modelle enthalten sich bei Unsicherheit eher und sagen ausdrücklich, dass keine Antwort auffindbar ist, während GPT-Modelle häufiger selbstbewusst falsch antworten. Eine knapp danebenliegende Tool-Beschreibung ist genau so ein Distraktor.

Genau deshalb ist Tool-Filterung am Gateway wichtig — und deshalb ist sie eine Context-Engineering-Technik und nicht nur eine Sicherheitsmaßnahme. Wenn du einschränkst, welche Tools ein Schlüssel erreichen darf, erzwingst du nicht nur Least Privilege, du verkleinerst auch den Kontext jeder Anfrage. Die Mechanik habe ich in benutzerbezogener Zugriffskontrolle für MCP-Tools beschrieben; Sicherheits- und Kontextperspektive erweisen sich als derselbe Hebel.

Beispiele — kanonisch, nicht erschöpfend

Few-Shot-Beispiele wirken. Was nicht wirkt: jeden je erlebten Sonderfall in den Prompt zu stopfen, in der Hoffnung, alle Regeln abzudecken.

Kuratiere eine kleine Menge vielfältiger, kanonischer Beispiele, die das erwartete Verhalten zeigen. Wie Anthropic sagt: Für ein Modell sind Beispiele die Bilder, die mehr als tausend Worte sagen — und tausend Bilder braucht man nicht.

Just-in-Time schlägt Vorabladen

Die meisten KI-Anwendungen nutzen heute Embedding-basierten Abruf vor der Inferenz: alles möglicherweise Relevante holen, hineinstopfen, hoffen, dass das Modell das Richtige findet.

Die agentische Alternative ist Just-in-Time-Abruf. Der Agent hält leichte Bezeichner — Dateipfade, gespeicherte Abfragen, URLs — und lädt Daten zur Laufzeit über Tools, erst wenn sie sich als nötig erweisen.

Claude Code arbeitet so: Statt eine ganze Codebasis in den Kontext zu indexieren, nutzt es Primitive wie glob und grep, um zu navigieren und Dateien bei Bedarf zu holen — und umgeht damit veraltete Indizes vollständig.

Zwei Dinge lassen das besser funktionieren, als es klingt:

Metadaten tragen Signal. Eine Datei test_utils.py in tests/ bedeutet etwas anderes als derselbe Name in src/core_logic/. Ordnerhierarchien, Namenskonventionen und Zeitstempel sagen einem Agenten, wie und wann etwas zu nutzen ist — dieselben Hinweise, die ein menschlicher Engineer liest.

Progressive Disclosure. Der Agent erschließt Kontext schichtweise. Dateigrößen deuten Komplexität an, Namen den Zweck, Zeitstempel die Relevanz. Er baut Verständnis schrittweise auf und hält nur das Nötige im Arbeitsspeicher.

Der Trade-off ist real: Exploration zur Laufzeit ist langsamer als vorberechnete Daten zu lesen, und ein schlecht geführter Agent verbrennt Kontext in Sackgassen. Deshalb sind die stärksten Setups hybrid — etwas vorab laden für Tempo, den Rest explorieren lassen. Claude Code macht genau das: CLAUDE.md kommt naiv zu Beginn hinein, alles andere wird bei Bedarf geholt.

Wenn deine Abrufschicht derzeit alles vorab lädt, sind die RAG-Pipeline-Muster, über die ich geschrieben habe, der natürliche Ausgangspunkt, um sie selektiv zu machen.

Drei Techniken für lange Aufgaben

Wenn eine Aufgabe zehn Minuten bis Stunden dauert — eine große Migration, ein Rechercheprojekt — übersteigt die Tokenzahl jedes Fenster. Drei Techniken setzen genau hier an.

Compaction

Ein Gespräch kurz vor dem Limit zusammenfassen und mit der Zusammenfassung neu starten.

In Claude Code heißt das, die Nachrichtenhistorie zur Verdichtung ans Modell zurückzugeben: Architekturentscheidungen, offene Bugs und Implementierungsdetails bleiben erhalten; redundante Tool-Ausgaben und überholte Nachrichten fallen weg. Der Agent läuft mit dieser Zusammenfassung plus den zuletzt berührten Dateien weiter.

Die Kunst liegt im Weglassen. Zu aggressive Compaction verliert feine Zusammenhänge, deren Bedeutung erst später auffällt. Justiere den Compaction-Prompt, indem du zuerst die Vollständigkeit maximierst — alles Relevante erfassen — und dann die Präzision verbesserst.

Der sicherste Einstieg ist das Löschen von Tool-Ergebnissen: Ist ein Tool weit oben in der Historie aufgerufen worden, braucht der Agent seine Rohausgabe fast nie wieder.

Strukturiertes Notieren

Lass den Agenten Notizen in persistenten Speicher außerhalb des Fensters schreiben und bei Bedarf zurückholen. Eine NOTES.md, eine To-do-Liste, eine Scratch-Datei.

So halten Agenten Kohärenz über Kontext-Resets hinweg: Das Fenster leert sich, die Notizen überleben, der Agent liest sich selbst zurück in die Aufgabe. Das ist günstig, transparent und im Gegensatz zur Compaction verlustfrei für alles, was der Agent festgehalten hat.

Sub-Agenten-Architekturen

Statt eines Agenten, der das ganze Projekt trägt, startest du spezialisierte Sub-Agenten mit sauberen Kontextfenstern für fokussierte Teilaufgaben. Jeder verbrennt womöglich zehntausende Tokens beim Explorieren und gibt dann eine verdichtete Zusammenfassung von rund ein- bis zweitausend zurück.

Der führende Agent sieht das Chaos nie — nur das destillierte Ergebnis. Der detaillierte Suchkontext bleibt isoliert, wo er hingehört, und der Koordinator behält sein Fenster für die Synthese.

Welche wann

Sie lassen sich kombinieren. Ein führender Agent kann im eigenen Strang Compaction fahren und Exploration an Sub-Agenten delegieren, die ihre Fenster sauber halten.

Der Teil, den niemand erwähnt: Kontext kostet VRAM

Es gibt eine Hardware-Dimension, die in KI-Engineering-Diskussionen selten vorkommt.

Während der Generierung cached das Modell Keys und Values für jedes bisher verarbeitete Token — den KV-Cache — und der wächst linear mit der Kontextlänge. Bei einem selbst betriebenen Setup ist das kein Rundungsfehler; ein langer Kontext kann viele Gigabyte zusätzlich zu den Modellgewichten belegen und ist der häufigste Grund, warum ein Modell abstürzt, das „eigentlich passt“.

Ein aufgeblähter Kontext kostet dich also dreifach: schlechtere Erinnerung, höhere Latenz und Ausgaben und echte Gigabyte VRAM. Wenn du Modelle selbst betreibst, habe ich diese Speicherrechnung in Quantisierung erklärt durchgerechnet — der Abschnitt zum KV-Cache überschneidet sich direkt mit Context Engineering.

Eine praktische Checkliste

Bevor du das Modell verantwortlich machst:

1. Zähle deine Tools. Kannst du eindeutig sagen, welches Tool wann passt? Wenn nicht, kann es der Agent auch nicht. Ausmisten oder pro Anfrage filtern.
2. Alte Tool-Ergebnisse löschen. Der günstigste verfügbare Gewinn — alte Rohausgaben verdienen ihre Tokens fast nie.
3. Prüfe die Flughöhe deines System-Prompts. Hardcodierte If-else-Logik und vages Gerede sind beide Fehlerformen.
4. Kürze deine Beispiele auf wenige kanonische statt eines erschöpfenden Regelwerks.
5. Wechsle vom Vorabladen zu Just-in-Time, wo deine Daten dynamisch genug sind, um es zu rechtfertigen.
6. Wähle bewusst eine Long-Horizon-Strategie — Compaction, Notizen oder Sub-Agenten — statt zu hoffen, dass das Fenster reicht.
7. Miss nach. Wenn die Qualität mit längeren Sitzungen sinkt, ist das Context Rot und kein schlechter Prompt.

Das Fazit

Prompt Engineering ist nicht gestorben — es wurde absorbiert. Eine gute Anweisung zu schreiben bleibt notwendig; es ist nur nicht mehr die ganze Arbeit, denn der Prompt ist Minderheitsgesellschafter in einem Fenster voller Tools, Ergebnisse, Dokumente und Historie.

Der Wandel im Denken geht vom Schreiben zum Budgetieren. Kontext ist eine endliche Ressource mit abnehmendem Grenznutzen, und die Disziplin besteht darin, sie bewusst auszugeben: weniger Tools, saubere Historie, Daten bei Bedarf statt auf Vorrat.

Anthropics eigenes Fazit ist der richtige Schlusspunkt — auch wenn Modelle besser werden, bleibt „Kontext als kostbare, endliche Ressource zu behandeln zentral für den Bau zuverlässiger, wirksamer Agenten“. Größere Fenster heben die Decke. Sie nehmen dir die Auswahl nicht ab.