Context Engineering: Warum der Prompt nicht das Problem ist

Andrej Karpathy: “Context engineering -- the delicate art and science of filling the context window with just the right information for the next step.”

Shopify-CEO Tobi Luetke: “The art of providing all the context for the task to be plausibly solvable by the LLM.”

Prompt Engineering war die richtige Disziplin fuer 2023. Ein Modell-Aufruf, ein statischer System-Prompt. Agenten haben dieses Modell zerstoert.

Harrison Chase (LangChain CEO) beschreibt das Kernproblem: “You don't actually know what the context at step 14 will be, because there's 13 steps before that that could pull arbitrary things in.”

• Prompt Engineering: Die Worte der Anweisung. “Wie formuliere ich das?”
• Context Engineering: Die gesamte Informationsumgebung. “Was soll das Modell wissen?”

Damon McMillan veroeffentlichte im Februar 2026 die groesste empirische Studie zu Context Engineering: 9.649 Experimente ueber 11 Modelle, 4 Datenformate, Schemata von 10 bis 10.000 Tabellen.

1. Modellwahl dominiert alles andere. Die Wahl des Modells hat mehr Einfluss als jede Prompt-Optimierung.
2. Dateibasierter Kontext hilft Frontier-Modellen. Frontier-Modelle arbeiten besser wenn sie Kontext aus Dateien abrufen statt alles auf einmal zu bekommen.
3. Format ist weniger wichtig als erwartet. YAML, JSON, Markdown -- der Unterschied ist minimal.
4. Context Rot ist real. LLM-Genauigkeit sinkt je mehr Tokens im Kontext sind -- auch wenn das Window nicht voll ist.
5. Die Mitte ist ein blinder Fleck. Performance faellt um 30%+ wenn kritische Informationen in der Mitte stehen. Anfang und Ende sind sicher.

1. System Prompt -- Rollen-Definition, Verhaltensregeln (Entwickler kontrolliert)
2. User Prompt -- Die eigentliche Aufgabe (Nutzer kontrolliert)
3. Konversationshistorie -- Vorherige Nachrichten (System)
4. Retrievte Dokumente -- RAG-Ergebnisse, Wissensbasis (Retrieval Pipeline)
5. Tool-Beschreibungen -- Verfuegbare APIs, Funktionssignaturen (Entwickler)
6. Few-Shot-Beispiele -- Input/Output-Paare (Entwickler/Nutzer)
7. Memory -- Nutzer-Praeferenzen, vergangene Interaktionen (Memory Pipeline)

Context Engineering ist die Disziplin, alle sieben Schichten so zu orchestrieren, dass die richtigen Tokens zur richtigen Zeit in der richtigen Reihenfolge ankommen.

1. Relevanz: Nur was gebraucht wird. Nicht die letzten 500 Nachrichten laden.
2. Suffizienz: Genug aber nicht zu viel. Jedes Extra-Token kompetiert um Attention.
3. Isolation: Tool-Outputs von einem Schritt sollten nicht den Kontext fuer unabhaengige naechste Schritte verschmutzen.
4. Oekonomie: Tokens kosten Geld und Qualitaet. ToolSearch reduziert Token-Verbrauch um ~85%.
5. Provenienz: Das Modell muss wissen koennen ob eine Information aus einer vertrauenswuerdigen Quelle stammt.

• Stufe 1: Metadata Layer (immer geladen) -- CLAUDE.md, Frontmatter, Basis-Konfiguration. ~15K Tokens (7.5%)
• Stufe 2: Core Instructions (bei Bedarf) -- Skills, Agent-Definitionen, aktiver Task-Kontext. ~60K Tokens (30%)
• Stufe 3: Referenced Files (rekursiv entdeckt) -- Docs, Code, Datenbanken per Grep/Read abgerufen. ~100K+ Tokens (50%+)

Das verhindert Context Rot -- die Performance-Degradierung durch zu viel upfront geladenen Kontext. Databricks zeigte: Die Accuracy sinkt bereits bei ~32K Tokens signifikant -- lange bevor das Million-Token-Limit erreicht ist.

Firecrawl und andere Practitioner haben vier distinkte Context-Failure-Modes identifiziert, die jeweils unterschiedliche Loesungen erfordern:

1. Context Poisoning: Falsche oder veraltete Informationen im Kontext fuehren zu ueberzeugend falschen Outputs. Loesung: Datenvalidierung und Freshness-Checks in der Retrieval-Pipeline.
2. Context Distraction: Zu viel irrelevante Information verwirrt das Modell. Wie ein Student der zu viel Referenzmaterial bekommt und den Fokus verliert. Loesung: Aggressives Filtern, nur task-relevante Dokumente laden.
3. Context Confusion: Widersprüchliche Informationen aus verschiedenen Quellen. Das Modell muss entscheiden welche Quelle Prioritaet hat -- ohne klare Hierarchie. Loesung: Explizite Quellenhierarchie definieren.
4. Context Clash: System-Prompt und User-Prompt widersprechen sich. Oder: Tool-Output widerspricht geladenem Dokument. Loesung: Klare Trust-Boundaries und Conflict-Resolution-Regeln.

In Agentic-Coding-Systemen wie unserem UltraLoop treten alle vier Failure-Modes regelmaessig auf -- besonders Context Distraction (zu viel Codebase-Kontext geladen) und Context Poisoning (veraltete Dokumentation in CLAUDE.md). Progressive Disclosure loest beide: Nur laden was fuer den aktuellen Task relevant ist, und veraltete Eintraege aktiv entfernen.

Context Engineering ist keine Theorie fuer uns -- es ist das Architekturprinzip hinter unserem gesamten Agent-System:

• CLAUDE.md: Die "Source of Truth" fuer jeden Agent -- Projektregeln, Konventionen, Workflow-Definitionen. Evoliert mit jedem Bug und jeder Erkenntnis.
• Skills-System: 17 spezialisierte Skills die als Context-Bausteine fungieren. Jeder Skill laedt nur die Informationen die fuer seine Aufgabe relevant sind -- nicht alles auf einmal.
• UltraBrain: Unser Open-Source MCP-Plugin fuer Cross-Session-Memory. Persistentes Wissen ueber Sessions hinweg, ohne das Context Window zu belasten.
• Agent-Isolation: Sub-Agents erhalten ihren eigenen Context, nicht den des Lead-Agents. Verhindert Context Distraction durch irrelevante uebergeordnete Informationen.

Die Formel die wir taaeglich validieren: Weniger Kontext mit hoeherer Relevanz schlaegt mehr Kontext mit niedrigerer Relevanz -- exponentiell, nicht linear.

Quellen

• Karpathy, A. (2025): Context Engineering Definition
• Luetke, T. (2025): Context Engineering fuer Practitioners
• McMillan, D. (2026): 9.649 Experiments on Context Engineering
• Firecrawl (2026): Context Engineering vs Prompt Engineering
• Databricks (2025): Context Window Accuracy Study (~32K Token Threshold)
• Chase, H. / LangChain: Agentic Context Management