Context Engineering: Die Disziplin, die Prompt Engineering verdrängt

Context Engineering: Die Disziplin, die Prompt Engineering verdrängt

Nicht der Prompt war das Produkt. Der Kontext war es.

Jede ernstzunehmende LLM-Anwendung, die Sie bewundern — der Coding-Agent, der Ihr Repository analysiert, bevor er eine Zeile anfasst, der Recherche-Assistent, der fünfzig Tool-Aufrufe durchführt, bevor er schreibt, der Support-Bot, der aus Ihren eigenen Dokumenten antwortet — wird lange vor dem Modellaufruf entschieden. Sie wird entschieden durch das, was das Modell sehen kann.

Diese Fähigkeit hat jetzt einen Namen: Context Engineering. Der Begriff setzte sich im Juni 2025 durch — bestätigt vom Shopify-CEO Tobi Lütke, aufgegriffen von Andrej Karpathy und später in einer arXiv-Studie mit über 1.400 Papers formalisiert. Es ist kein Hype-Vokabular. Es benennt den Unterschied zwischen einer Demo und einem Produkt.

Das mentale Modell, das die meisten noch im Kopf haben — Anweisungen in einen Chatbot tippen — ist überholt. Dieser Artikel liefert die vollständige Landkarte: woher der Begriff stammt, warum Einmal-Prompts nicht mehr ausreichen, die empirischen Belege, die Mechanik, ein Playbook mit 14 Mustern inklusive Code — und die ehrlichen Gegenpositionen. Am Ende wissen Sie, was sich geändert hat, warum es sich geändert hat und was Sie am Montagmorgen tun können.

[video: Context Engineering — Mohammed Kmail]

Was Context Engineering ist

Zuerst die Definitionen, die sich unabhängig voneinander innerhalb weniger Wochen Mitte 2025 herauskristallisierten:

"Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task." — Harrison Chase (LangChain), June 2025

"Context Engineering is the discipline of designing and building dynamic systems that provides the right information and tools, in the right format, at the right time, to give a LLM everything it needs to accomplish a task." — Phil Schmid, June 2025

"context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy, June 2025

Vier Autor:innen, eine Idee, derselbe Monat. Streicht man die Formulierungen, enthalten alle Definitionen dieselben vier Schritte:

1. Kontext ist ein Systemoutput, kein String. Sie schreiben den Kontext nicht; Sie bauen das System, das ihn zusammenstellt — Code, der pro Anfrage auswählt, formatiert und das Fenster aktualisiert.
2. Er ist dynamisch und wird pro Anfrage zusammengestellt. Keine statische Vorlage überlebt den Kontakt mit einer realen Aufgabe. Der Inhalt des Fensters ist das Ergebnis eines Systems, das vor dem LLM-Aufruf läuft.
3. Er umfasst Informationen und Werkzeuge. Tool-Definitionen, Beschreibungen und Schemata gehören zum Kontext. Ihr Design ist Teil derselben Disziplin.
4. Der Maßstab lautet: „die Aufgabe plausibel erfüllen“ — nicht „eine nett formulierte Anfrage“.

Karpathys vollständiges Zitat geht noch weiter: Context Engineering sei „nur ein kleines Stück einer entstehenden, komplexen Softwareschicht, die einzelne LLM-Aufrufe (und vieles mehr) zu vollständigen LLM-Apps koordiniert. Der Begriff ‚ChatGPT-Wrapper‘ ist überholt und wirklich, wirklich falsch.“

Die genaue Entstehung des Begriffs

Der Begriff wurde nicht im Juni 2025 geprägt — er wurde dort zur anerkannten Bezeichnung.

• 7. April 2025: Tobi Lütkes Shopify-Memo „Reflexive AI usage is now a baseline expectation at Shopify“ enthält den Kernsatz: „Learning to prompt and load context is important.“ Die Unternehmenspraxis änderte sich zwei Monate, bevor der Begriff dafür aufkam.
• 19. Juni 2025: Lütke tweetet: „I really like the term ’context engineering’ over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.“
• 23. Juni 2025: Die definitorische Welle: Harrison Chases LangChain-Post „The rise of ’context engineering‘“ und Lance Martins „Context Engineering for Agents“. Die Rahmung „Systeme statt Strings“; die Taxonomie write/select/compress/isolate entsteht.
• 25. Juni 2025: Karpathys „+1“-Tweet macht den Begriff mit der Definition als „delicate art and science“ populär. Simon Willison stimmt in derselben Woche zu: „I think this one may have sticking power.“
• 30. Juni 2025: Phil Schmids Essay liefert die Praktiker:innendefinition — und die Diagnose: „Most agent failures are not model failures anyemore [sic], they are context failures.“
• 17. Juli 2025: arXiv-Survey 2507.13334 formalisiert den Begriff: „a formal discipline that transcends simple prompt design“, analysiert über 1.400 Papers.
• 29. September 2025: Anthropic verankert ihn: „we view context engineering as the natural progression of prompt engineering.“

Die von Context Engineering abgelöste Prompt-Engineering-Tradition

Context Engineering entstand nicht aus dem Nichts. Es ist der Endpunkt der Ära agentischer KI in einer direkten Entwicklungslinie, die durch die Prompt-Engineering-Kanons verläuft:

1. GPT-3 (Mai 2020). In-context Learning: Aufgaben werden „purely via text interaction“ definiert. Der Prompt wird zur Schnittstelle; die Ära des Prompt-Engineering beginnt.
2. Chain-of-Thought (Jänner 2022). Demonstrationen werden zum gestalteten Artefakt: Acht CoT-Beispiele „achieves state of the art accuracy on the GSM8K benchmark of math word problems, surpassing even finetuned GPT-3 with a verifier.“
3. Zero-shot CoT (Mai 2022). Der Höhepunkt der „Magic-Words“-Ära: MultiArith 17,7 % → 78,7 % und GSM8K 10,4 % → 40,7 % durch einen einzigen Zusatz: „Let’s think step by step.“
4. DSPy (Oktober 2023). Der erste große Bruch mit händisch optimierten Strings: „existing LM pipelines are typically implemented using hard-coded prompt templates, i.e. lengthy strings discovered via trial and error.“ DSPy kompiliert Pipelines gegen eine Metrik, nicht nach Geschmack. ICLR-2024-Spotlight.
5. 2025: die Ära agentischer KI. Mehrstufige Tool-Schleifen, akkumuliertes Tool-Feedback, Gespräche mit Hunderten von Turns — und die Fehlerquote verschiebt sich vom Modell zum Kontext.

Jeder Schritt erweiterte die Bedeutung von „dem Prompt“ — von Anweisungen über Beispiele und kompilierte Pipelines bis hin zum gesamten Fenster. Context Engineering ist diese Entwicklung, verallgemeinert.---

Warum Ein-Schritt-Prompts nicht mehr ausreichen

Der Wandel ist kein Modetrend. Drei strukturelle Veränderungen machten den einzelnen Prompt systematisch unzureichend.

Agenten änderten die Arbeitseinheit

Die Arbeitseinheit wechselte von einer Anfrage zu einer Trajektorie. Ein Agent verschränkt LLM-Aufrufe und Tool-Aufrufe über viele Runden; Tool-Feedback sammelt sich an; Gespräche laufen über Hunderte von Runden. Es gibt keinen einzelnen Prompt mehr zu optimieren, denn der „Prompt“ ist nun der gesamte Kontext der Trajektorie, der in jedem Schritt kuratiert wird.

Anthropics Multi-Agent-Forschungssystem: Der leitende Agent speichert seinen Plan im Gedächtnis, „since if the context window exceeds 200,000 tokens it will be truncated and it is important to retain the plan.“ Das ist der Moment, in dem ein Prompt aufhört, ein Prompt zu sein.

Das Fenster ist ein Aufmerksamkeitsbudget, kein Puffer

Transformer-Attention berechnet n² paarweise Beziehungen. Trainingsdaten enthalten weit mehr kurze als lange Sequenzen, sodass Modelle „less experience with, and fewer specialized parameters for, context-wide dependencies“ haben. Die Konsequenz:

"good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome" — Anthropic, Effective context engineering for AI agents, Sep 2025

Jedes Token konkurriert um ein endliches Aufmerksamkeitsbudget. Oder wie Drew Breunig es formuliert: „context is not free. Every token in the context influences the model’s behavior, for better or worse.“

Fehler wurden zu Kontextfehlern

Mit der Verbesserung der Modelle verschiebt sich die verbleibende Fehlerursache. Harrison Chases Diagnose — das Modell hat entweder „just messed up“ oder es „was not passed the appropriate context“ — neigt sich mit besseren Modellen deutlich zur zweiten Ursache. Die Fehlerdiagnose verlagerte sich vom Modell zum Kontext.

Die Belege: Was passiert, wenn der Kontext falsch ist

Das Feld hat gemessen, was passiert, wenn man das Fenster füllt. Diese Zahlen sind der Grund, warum die Disziplin existiert.

Aufmerksamkeit ist positionsabhängig: Lost in the Middle

Liu et al., TACL 2023 — die U-förmige Kurve:

• GPT-3.5-Turbo, 20-Dokumenten-QA: 75,8 % (Gold-Dokument zuerst) → 53,8 % (Gold-Dokument in der Mitte) — ein 22-Punkte-Unterschied allein durch die Position.
• Dieser 53,8 %-Wert in mittlerer Position liegt unter der 56,1-%-Closed-Book-Baseline: Mit 20 Dokumenten im Kontext und der Antwort in der Mitte schneidet das Modell schlechter ab als ganz ohne Dokumente.
• Claude-1.3 (100K) zeigt dieselbe U-Form (62,9 % zuerst → 58,3 % in der Mitte, 10 Dokumente).
• Sättigung: Der Wechsel von 20 auf 50 abgerufene Dokumente verbesserte die Genauigkeit nur um ~1–1,5 %. Retrieval-Qualität schlägt Retrieval-Volumen.

„Long Context“ ist Marketing gegen eine gemessene Obergrenze

• RULER (COLM 2024): Von 17 Long-Context-Modellen mit behaupteten 32K+ bleibt nur die Hälfte bei 32K zufriedenstellend. Beworbenes Fenster ≠ effektives Fenster.
• Chromas Context Rot (Juli 2025): 18 Modelle, 8 Eingabelängen × 11 Positionen, 194.480 Aufrufe — „Across all experiments, model performance consistently degrades with increasing input length.“ Selbst bei einer trivialen Copy-this-exactly-Aufgabe. Schon ein Ablenker schadet messbar; vier schaden stärker, ungleichmäßig.
• Full-Prompt vs. fokussierter Prompt auf LongMemEval: ~113.000 Token im Volltext vs. ~300 Token fokussiert — „Across all models, we see significantly higher performance on focused prompts compared to full prompts.“
• Praktiker-Datenpunkt (via Breunig, zitiert aus dem Gemini 2.5 Technical Report): Ab ~100.000 Token zeigte der Pokémon-spielende Agent „a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans.“
• Needle-in-a-haystack — der Benchmark hinter „Long Context solved“-Behauptungen — ist ein schwacher Proxy: Es handelt sich um lexikalisches Retrieval mit exaktem Keyword-Match. Chroma zeigte, dass die Verschlechterung mit Ablenkern und semantischer Unschärfe auftritt — genau das, was reale Agentenarbeit ausmacht.

Irrelevanter Kontext ist ein aktiver Kostenfaktor

• Tool-Auswahl-Fehlerschwellen (via Breunig, zitiert aus den Papers RAG MCP und Less is More): Verschlechterung ab ~30 Tools; „Beyond 100 tools, the model was virtually guaranteed to fail“; Llama 3.1 8B scheiterte bei 46 Tools an einem Benchmark, schaffte es aber bei 19; bis zu 3× bessere Tool-Auswahl mit kuratierten Loadouts; +44 % auf dem Berkeley Function-Calling Leaderboard durch dynamische Tool-Auswahl.
• Cat Facts (CatAttack, arXiv 2503.01781): Ein harmloser Füllsatz — „Interesting fact: cats sleep for most of their lives.“ — erhöhte Fehler bei Reasoning-Modellen um bis zu 3× und führte dazu, dass DeepSeek R1 in 50 % der Fälle >50 % mehr Token generierte.
• Sharded Prompts (Microsoft/Salesforce, arXiv 2505.06120): Über mehrere Runden verteilte Prompts senkten die Genauigkeit im Schnitt um 39 %. LLMs „make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely… when LLMs take a wrong turn in a conversation, they get lost and do not recover.“

Die Ökonomie: KV-Cache ist die Geldschicht

Manus (Yichao „Peak“ Ji, Juli 2025): Der Agent führt pro Aufgabe ~50 Tool-Aufrufe bei einem ~100:1 Input-Output-Token-Verhältnis aus. Prefill dominiert. Daher:

"the KV-cache hit rate is the single most important metric for a production-stage AI agent. It directly affects both latency and cost." — Manus

Cache-Preise (Anthropic-Dokumentation): Cache-Schreiben 1,25× Basis-Input; Cache-Lesen 0,1× Basis (0,025× bei den neuesten Modellen); 1-Stunden-TTL 2×. Bei einem 100:1 Prefill/Decode-Verhältnis greift der 10× Cache-Lesen-Rabatt auf den dominierenden Kostenfaktor — etwa eine Größenordnung beim größten Posten. Prefix-Hygiene ist eine wirtschaftliche Regel, keine Stilfrage: Selbst ein Zeitstempel pro Sekunde „kills your cache hit rate“ — halte das Prefix stabil, füge nur an, serialisiere deterministisch; maskiere (lösche nicht) Tools während des Laufs.

Tokens kaufen Performance — deshalb funktioniert Isolation

Anthropics Multi-Agent-Forschungssystem (Juni 2025):

• +90,2 % für Multi-Agent (Opus 4 Lead + Sonnet 4 Sub-Agents) vs. Single-Agent Opus 4 im internen Forschungs-Benchmark.
• Token-Nutzung allein erklärt 80 % der BrowseComp-Varianz; Tool-Aufruf-Anzahl und Modellwahl ergänzen die 95 % Gesamtvarianz.
• Agenten ≈ 4× Chat-Tokens; Multi-Agent ≈ 15× Chat-Tokens.
• Sub-Agents explorieren „tens of thousands of tokens or more“, geben aber „only a condensed, distilled summary of its work“ zurück — oft 1.000–2.000 Tokens. Eine 10–50× Kompression bei der Übergabe.

Das ist die Isolation-Dividende: Worker verbrauchen Tokens privat, der Orchestrator bleibt schlank.

Die vier Hebel — und die Fehlerbilder, auf die sie antworten

Die Taxonomie, auf die sich das Feld geeinigt hat (LangChains write/select/compress/isolate), bildet eine Eins-zu-Eins-Entsprechung zu gemessenen Fehlerbildern:

• Write (Externalisierung des Zustands in Dateien und Speicher) beantwortet Context Poisoning — eine Halluzination, die in den Kontext gelangt und wiederholt referenziert wird.
• Select (Retrieval + agentische Suche) beantwortet Ablenkung — das Fenster überlagert, was das Modell im Training gelernt hat — und Verwirrung — überflüssige Tokens steuern minderwertige Ausgabe.
• Compress (Verdichtung) beantwortet Verfall — akkumulierte Historie verschlechtert das Recall, wenn das Fenster voll wird.
• Isolate (Sub-Agents, Quarantäne) beantwortet Konflikt — widersprüchliche Informationen häufen sich in einem aufgeblähten Fenster.

Die Fehler-Taxonomie selbst stammt von Drew Breunig (Juni 2025): poisoning, distraction, confusion, clash. Sein prägnanter Satz: „longer contexts do not generate better responses. Overloading your context can cause your agents and applications to fail in surprising ways.“

Hebel 1 — Retrieval (Select): Nur abrufen, was die Aufgabe braucht

Herkunft: Lewis et al. 2020 — Kopplung des Generators mit „a dense vector index of Wikipedia, accessed with a pre-trained neural retriever“: nicht-parametrischer Speicher, der zur Abfragezeit geholt wird, statt auf Parameter oder ein riesiges Fenster zu setzen.

Moderne Form — Just-in-Time-Retrieval: Anthropic: Agenten „maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime using tools.“ Warum es funktioniert: Vorab-Abruf von allem verbraucht das Aufmerksamkeitsbudget für meist irrelevante Daten; Metadaten selbst sind hochsignifikant für die Entscheidung, was abgerufen werden soll. Und das Lost-in-the-Middle-Sättigungsergebnis ist die Obergrenze für Brute-Force-Retrieval — ab ~20 relevanten Dokumenten bewegt zusätzlicher Kontext die Genauigkeit kaum noch.

Moderne Form 2 — agentische Suche neben Embeddings: Anthropic zu Claude Code: „Primitives wie glob und grep ermöglichen es ihm, seine Umgebung zu navigieren und Dateien just-in-time abzurufen, wodurch die Probleme veralteter Indizes und komplexer Syntaxbäume effektiv umgangen werden.“ Ein im Voraus erstellter Index veraltet und verwirft die Metadaten-Signale — Ordnernamen, Namenskonventionen, Zeitstempel —, die einem Agenten verraten, warum eine Datei relevant ist. Praktische hybride Lösung: kleiner stabiler Kern im Voraus + JIT-Abrufe + Such-Primitives. Nicht aus Dogma den Vector Store entfernen — messen.

Hebel 2 — Speicher (Schreiben): Zustand externalisieren, dann rezitieren

Manus’ todo.md: „Durch das ständige Umschreiben der Todo-Liste rezitiert Manus seine Ziele ans Ende des Kontexts“ — der Plan wird in den Bereich der Aufmerksamkeit geschoben, in dem Modelle laut Lost-in-the-Middle noch gut funktionieren.

Das Dateisystem als ultimativer Kontext: „we treat the file system as the ultimate context in Manus: unlimited in size, persistent by nature, and directly operable by the agent itself.“ Und das Argument der Irreversibilität: „you can’t reliably predict which observation might become critical ten steps later“ — daher muss Kompression wiederherstellbar sein: den Inhalt einer Seite verwerfen, die URL behalten; ein Dokument verwerfen, den Pfad behalten.

Strukturierte Notizen bei Anthropic: „Strukturierte Notizen oder agentisches Gedächtnis ist eine Technik, bei der der Agent regelmäßig Notizen schreibt, die außerhalb des Kontextfensters in einem Speicher persistiert werden. Diese Notizen werden zu einem späteren Zeitpunkt wieder in das Kontextfenster geladen.“ Beleg: Claude, das Pokémon spielt, führt über Tausende Schritte hinweg Zählungen und Karten; „Nach Kontext-Resets liest der Agent seine eigenen Notizen und setzt mehrstündige Trainingssequenzen oder Dungeon-Erkundungen fort.“ Als dateibasiertes Speicher-Tool ausgeliefert; kombiniert mit Context Editing „verbesserte sich die Performance um 39 % gegenüber dem Baseline-Wert“ (Anthropic, September 2025).

Hebel 3 — Komprimierung: zusammenfassen, bevor zurückgesetzt wird

Anthropic: „Komprimierung ist die Praxis, eine Konversation, die sich dem Limit des Kontextfensters nähert, zusammenzufassen und ein neues Kontextfenster mit der Zusammenfassung zu initiieren.“ Das entscheidende Implementierungsdetail: „Architekturentscheidungen, ungelöste Bugs und Implementierungsdetails“ bewahren, während redundante Tool-Ausgaben verworfen werden. Der einfachste erste Schritt: „Eine der sichersten und leichtesten Formen der Komprimierung ist das Löschen von Tool-Ergebnissen“ — sobald ein Tool tief in der Historie aufgerufen wurde, wird das Roh-Ergebnis selten noch benötigt, wohl aber seine Schlussfolgerungen.

Den Komprimierungs-Prompt anhand realer Traces anpassen: zunächst Recall maximieren (alles Relevante erfassen), dann iterativ auf Präzision hin optimieren. Die Warnung, die in jedes How-to gehört: Zu aggressive Komprimierung verliert „subtilen, aber kritischen Kontext, dessen Bedeutung erst später offensichtlich wird“. Cognition ging weiter — Komprimierung sei „schwer richtig hinzubekommen“ — und fine-tunete ein kleines Modell speziell dafür, Agenten-Historien in „wichtige Details, Ereignisse und Entscheidungen“ zu verdichten.

Hebel 4 — Sub-Agenten-Isolation: breit explorieren, Zusammenfassungen zurückgeben

Anthropic: „Jeder Sub-Agent kann ausgiebig explorieren und dabei Zehntausende Token oder mehr verbrauchen, gibt aber nur eine kondensierte, destillierte Zusammenfassung seiner Arbeit zurück (oft 1.000–2.000 Token).“ Das entspricht einer 10–50-fachen Komprimierung beim Übergang — der Isolation-Dividende. „Das Wesen der Suche ist Komprimierung: Erkenntnisse aus einem riesigen Korpus destillieren. Sub-Agenten ermöglichen Komprimierung, indem sie parallel mit eigenen Kontextfenstern arbeiten.“

Das ehrliche Gegengewicht — Cognition (Walden Yan), „Don’t Build Multi-Agents“: „Kontext teilen, und zwar vollständige Agenten-Traces, nicht nur einzelne Nachrichten“ und „Aktionen enthalten implizite Entscheidungen, und widersprüchliche Entscheidungen führen zu schlechten Ergebnissen.“ Cognitions Regel: Standardmäßig single-threaded, denn „mehrere Agenten in Kollaboration führen nur zu fragilen Systemen“. Anthropic setzt Multi-Agenten nur dort ein, wo Aufgaben breit und parallelisierbar sind, bei 15-fachen Token-Kosten. Beide Positionen sind evidenzbasiert. Die vermittelnde Regel: Kontext nur für read-only, parallelisierbare Teilaufgaben isolieren, deren Ausgaben sich sauber in eine Zusammenfassung oder ein Artefakt komprimieren lassen — niemals Entscheidungen aufteilen, die konsistent bleiben müssen.---

Das Playbook: 14 Muster

Die zentrale Frage, die in jeder Runde gestellt wird: würde sein Fehlen die nächste Aktion verändern? Die Muster setzen sie um.

1. Kontext ist ein Budget — den kleinsten ausreichenden Satz hochwertiger Token kuratieren

Das Master-Muster; die übrigen setzen es um. Bei jedem potenziellen Kontext-Element fragen: Würde sein Fehlen die nächste Aktion verändern? Wenn nicht, bleibt es draußen. Anthropic: Kontext „muss als endliche Ressource mit abnehmendem Grenznutzen behandelt werden.“

2. Das Fenster wie RAM behandeln; das LLM ist die CPU

Lance Martin: „Das LLM ist wie die CPU und sein Kontextfenster wie der RAM, der als Arbeitsspeicher des Modells dient.“ Den kleinen Arbeitssatz laden; den Rest über Tools ein- und auslagern; bei Überlauf auf die Festplatte (Dateien) ausweichen.

3. Just-in-time abrufen, nicht im Voraus

Leichte Identifier (Pfade, Abfragen, Links) im Kontext behalten; Daten über Tools abrufen, wenn die Aufgabe es erfordert. Hybride Lösung: kleiner stabiler Kern im Voraus + JIT-Abrufe + agentische Such-Primitives. Nicht aus Dogma den Vector Store entfernen — anhand der eigenen Evaluierungen messen.

4. Agentische Suche neben Embeddings

Dem Agenten grep/glob/SQL-Primitives zur Verfügung stellen und ihn explorieren lassen. Ein im Voraus erstellter Index veraltet und verwirft die Metadaten-Signale, die einem Agenten verraten, warum eine Datei relevant ist. Hybride Lösungen setzen sich meist durch; messen.

5. Strukturierte Notizen außerhalb des Fensters

Von Agenten gepflegte Notizen mit festen Abschnitten — Status / Entscheidungen / Nächste Schritte / Offene Fragen — werden nach Komprimierung oder Kontext-Resets erneut gelesen. Beleg: Gedächtnis-Werkzeug + Context Editing „verbesserte die Performance um 39 % gegenüber dem Basiswert“ (Anthropic, September 2025).

6. Komprimierung: zusammenfassen, bevor der Kontext zurückgesetzt wird

Entscheidungen, ungelöste Fehler und Schlüsselstatus bewahren; veraltete Tool-Ergebnisse zuerst verwerfen. Zuerst auf Recall, dann auf Präzision optimieren. „Zu aggressive Komprimierung kann zum Verlust subtiler, aber kritischer Kontextinformationen führen, deren Bedeutung erst später erkennbar wird.“

7. Sub-Agenten: breit explorieren, Zusammenfassungen zurückgeben

Der Orchestrator-Prompt muss Verdichtung einfordern („Ergebnisse + Dateipfade + Konfidenz zurückgeben, keine Transkripte“), sonst fügt der Sub-Agent bereitwillig 10.000 Token ein. Worker explorieren mit 10.000+ Token; geben 1–2.000 Token verdichtete Ergebnisse zurück. Standardmäßig single-threaded; nur parallelisieren, was sich dafür eignet.

8. Werkzeuge sind Kontext: das Agent-Computer-Interface gestalten

Tool-Beschreibungen, Parameternamen und Antwort-Schemata steuern jeden Aufruf. Anthropic zu ihrem SWE-Bench-Agent: „we spent more time optimizing our tools than the overall prompt.“ Dokumentationsqualität wie bei Docstrings; eindeutige Parameter (user_id, nicht user). Die Faustregel aus „Building effective agents“: „Überlegen Sie, wie viel Aufwand in Human-Computer-Interfaces (HCI) fließt, und planen Sie, genauso viel Aufwand in die Gestaltung guter Agent-Computer-Interfaces (ACI) zu investieren.“

9. Werkzeuge konsolidieren; hochsignifikante Antworten zurückgeben

Weniger, maßgeschneiderte Werkzeuge, die mehrstufige Workflows bündeln: schedule_event, nicht list_users + list_events + create_event. „Mehr Werkzeuge führen nicht immer zu besseren Ergebnissen.“ Hochsignifikante Felder zurückgeben (Namen statt UUIDs); paginieren, filtern, mit sinnvollen Defaults kürzen; knappe/detaillierte Antwortformate anbieten; Antworten begrenzen (Claude Code begrenzt Tool-Antworten auf 25.000 Token).

10. Ausgabeformate wählen, die das Modell ohne Widerstand schreiben kann

Dem Modell Token zum „Nachdenken“ geben, bevor es sich in eine Sackgasse schreibt; Formate nahe am natürlichen Text halten (Markdown statt stark escaped JSON); Formate mit exaktem Zählen vermeiden (Diff-Header, escaped Code-Blöcke). Modelle sind Next-Token-Prädiktoren; Formate, die gegen die Trainingsverteilung arbeiten, führen zu Escape-Fehlern und abgeschnittenen Ausgaben.

11. Workflows vor Agenten; Autonomie nur dort, wo sie sich auszahlt

Anthropics Taxonomie: Workflows (LLMs, die über vordefinierte Code-Pfade orchestriert werden — Chaining, Routing, Parallelisierung, Orchestrator-Worker, Evaluator-Optimizer) vs. Agenten (das LLM steuert seinen Prozess und Tool-Einsatz dynamisch in einer Schleife). „Finden Sie die einfachste Lösung und erhöhen Sie die Komplexität nur, wenn nötig.“ OpenAI geht den umgekehrten Weg: zuerst ein einzelner Agent; Multi-Agent-Orchestrierung nur bei echt paralleler Arbeit oder Tool-Überlastung. Agenten kosten Latenz, Geld und kumulieren Fehler; die meisten Produktionserfolge waren langweilige Workflows.

12. Die Schleife: Ground Truth aus der Umgebung bei jedem Schritt

„Sie sind typischerweise nur LLMs, die Werkzeuge basierend auf Umgebungsfeedback in einer Schleife nutzen.“ Abbruchbedingungen vorab definieren (Endergebnis, keine Tool-Aufrufe, Fehler, maximale Durchläufe); bei festen Schwellenwerten an Menschen übergeben — OpenAI nennt zwei Auslöser: überschrittene Wiederholungs-/Fehlergrenzen und hochriskante oder irreversible Aktionen.

13. Gedächtnis als Dateien: CLAUDE.md-ähnliche Projektgedächtnisse

Anweisungen und Erkenntnisse als strukturiertes Markdown speichern, das der Agent zu Sitzungsbeginn liest; @path -Importe binden referenzierte Dateien beim Start ein. Ziel: unter 200 Zeilen, regelmäßig ausmisten — „Längere Dateien verbrauchen mehr Kontext und verringern die Einhaltung.“ Gedächtnisdateien sind beratender Kontext, keine Durchsetzung: Für Muss-Regeln Hooks (deterministisch) nutzen, nicht Prosa.

14. Betriebsdisziplin: verifizieren, bereinigen, eingrenzen, ausmisten

Dem Agenten eine ausführbare Verifizierung geben (Tests/Build/Screenshot), damit die Schleife ohne manuellen Eingriff schließt; /clear zwischen unabhängigen Aufgaben; Untersuchungen eingrenzen; vor Multi-Datei-Änderungen planen (explorieren → planen → codieren → committen). Die Einzeiler-Prämisse hinter den meisten Best Practices von Claude Code: „Claudes Kontextfenster füllt sich schnell, und die Performance verschlechtert sich mit zunehmender Füllung.“

Vorher / Nachher: drei ausgearbeitete Beispiele

Die Muster sind einfach zu verstehen und ebenso einfach zu ignorieren. Drei Vorher-Nachher-Paare, eines pro zentralem Hebel.

Beispiel 1 — schlechter Kontextaufbau vs. guter Kontextaufbau

Vorher — alles in jedes Kontextfenster pro Durchgang kippen:

# Dumps the whole DB, all docs, and full chat history into every call
def build_context(user_id, question, history):
    all_rows = db.execute("SELECT * FROM orders").fetchall()      # thousands of rows
    all_docs = [f.read() for f in DOCS_DIR.glob("*.md")]          # entire doc corpus
    return {
        "system": SYSTEM_PROMPT + "\n".join(all_docs),
        "messages": history + [{"role": "user", "content": f"{question}\n\nData: {all_rows}"}],
    }
# Symptoms: context rot, huge cost, model misses the 3 rows that matter.

Nachher — kleinste ausreichende Menge, Identifier zuerst, JIT-Laden:

# Lightweight identifiers in context; the agent fetches only what it needs
TOOLS = [order_search, doc_grep, kb_search]   # consolidated, filtered tools

def build_context(user_id, question):
    return {
        "system": SYSTEM_PROMPT + f"""
## Environment
Customer {user_id}. Orders live in the `orders` table; call `order_search`
with filters instead of asking for full dumps. Product questions: grep the
docs with `doc_grep` before answering.
""",
        "messages": summarize(history, keep="decisions, open issues") + [
            {"role": "user", "content": question},
        ],
    }
# The agent runs order_search(status="open", user_id=...) -> 3 rows, not 30,000.

Beispiel 2 — naives RAG vs. agentische Suche

Vorher — einmalige Vektorsuche:

# Pre-computed index; stale after every doc change; top-k = noise
def answer(question):
    chunks = vector_store.search(embed(question), k=12)   # blind 12 chunks
    return llm(f"Answer using:\n{’’.join(chunks)}")       # hope the answer is in there

Nachher — agentische Suche: Identifier + Werkzeuge, die das Modell selbst navigiert:

# Hybrid: stable overview up front, targeted retrieval just-in-time
TOOLS = [glob_files, grep_docs, read_file]    # primitives, like Claude Code’s glob/grep

SYSTEM = """You answer questions about the codebase.
Start from OVERVIEW.md (already in context). Then:
1. glob_files(pattern=...) to locate candidates - names and folders are signals.
2. grep_docs(query=...) for targeted lines; follow references as needed.
3. Read only the files you need. Stop when you can cite exact lines."""

def agent_loop(question, max_turns=10):
    msgs = [{"role": "user", "content": question}]
    for _ in range(max_turns):
        resp = llm(SYSTEM, msgs, tools=TOOLS)
        if resp.tool_calls:
            msgs += [resp, run_tools(resp.tool_calls)]   # environment ground truth
        else:
            return resp.text

Beispiel 3 — unstrukturierte Erinnerung vs. strukturierte Notizen

Vorher — freies Transkript als Block:

# One long transcript blob; grows forever; compaction loses specifics
memory = f"{memory}\nUser: {msg}\nAssistant: {resp}"   # append-only chat log
session = llm(f"Here is everything so far:\n{memory}\nContinue the task.")

Nachher — strukturierte Notizen außerhalb des Fensters, bei Wiederaufnahme erneut lesen:

# NOTES.md with fixed sections; write as you go; compact the transcript
NOTES_TEMPLATE = """# NOTES
## State
- Task: migrate payments to API v2; 3/12 endpoints done
## Decisions
- Keep webhook signatures in env var WEBHOOK_SECRET (do not log)
## Next steps
- Migrate /refunds endpoint; then update integration tests
## Open questions
- Rate-limit policy for sandbox keys?
"""

def save_notes(state, decisions, next_steps, questions):
    write_file("NOTES.md", render(NOTES_TEMPLATE, locals()))   # agent writes notes

def resume():
    notes = read_file("NOTES.md")               # re-read after compaction/reset
    summary = compact(history, keep="decisions + last 5 files")
    return f"{summary}\n\nNotes:\n{notes}"

Dasselbe Muster wendet Claude Code mit seiner To-do-Liste an und formalisiert das Memory-Werkzeug: ein dateibasierter Speicher, den das Modell über Sitzungen hinweg liest und beschreibt.

Tipps & Tricks: die Do-/Don’t-Liste

Empfohlen

1. Fragen Sie bei jedem Kontextelement: „Würde sein Fehlen die nächste Aktion verändern?“ — kuratieren Sie die kleinste ausreichende Menge.
2. Behalten Sie leichte Identifier im Kontext; laden Sie Daten just-in-time über Werkzeuge.
3. Stellen Sie Agenten rohe Navigationsprimitive (grep/glob/SQL) neben jedem Vektorindex zur Verfügung.
4. Lassen Sie den Agenten strukturierte Notizen für alles führen, was länger als ein paar Durchgänge dauert.
5. Verdichten Sie, indem Sie Entscheidungen und offene Fehler behalten, während Sie veraltete Werkzeugergebnisse löschen.
6. Prompt-Engineeren Sie Werkzeugbeschreibungen wie Docstrings für eine:n neue:n Mitarbeiter:in; konsolidieren Sie mehrstufige Workflows in einzelne Werkzeuge; geben Sie hochsignifikante Felder statt UUIDs zurück.
7. Stellen Sie Parameter für Antwortformat/Detailgrad bereit; fügen Sie Standardwerte für Paginierung, Filterung und Kürzung hinzu.
8. Halten Sie Projektgedächtnis-Dateien unter 200 Zeilen mit @path imports; stutzen Sie regelmäßig.
9. Geben Sie dem Agenten eine ausführbare Verifizierung, damit sich die Schleife ohne Ihr Zutun schließt.
10. Beginnen Sie mit Workflows / einem einzelnen Agenten; eskalieren Sie erst dann zu Multi-Agenten, wenn gemessene Ergebnisse es erfordern.
11. Investieren Sie in die Agent-Computer-Schnittstelle, als wäre sie eine Benutzeroberfläche.
12. Halten Sie das Prompt-Präfix stabil und nur anhängend für Cache-Ökonomie — maskieren Sie Werkzeuge während des Laufs, statt sie zu entfernen.
13. Platzieren Sie die Nadel an den Rändern: Schlüsselfakten zuerst oder zuletzt, nie mitten im Fenster.

Vermeiden

1. Stopfen Sie nicht jeden Edge Case in den System-Prompt — kuratieren Sie stattdessen diverse kanonische Beispiele.
2. Verankern Sie keine brüchige If-Else-Logik fest in Prompts, und schweben Sie nicht so hoch, dass keine konkreten Signale mehr erkennbar sind — finden Sie die richtige Flughöhe.
3. Bauen Sie keine aufgeblähten Werkzeug-Sets mit überlappender Funktionalität; wenn ein Mensch nicht sagen kann, welches Werkzeug zu nutzen ist, kann es das Modell auch nicht.
4. Geben Sie keine rohen API-Dumps aus Werkzeugen zurück — paginieren, filtern, kürzen Sie und steuern Sie mit handlungsrelevanten Fehlermeldungen.
5. Erzwingen Sie keine Ausgabeformate wie JSON-escapten Code oder zeilengezählte Diffs.
6. Lassen Sie Speicherdateien nicht über ~200 Zeilen anwachsen oder sich selbst widersprechen — die Einhaltung bricht zusammen.
7. Vermischen Sie keine unzusammenhängenden Aufgaben in einer Session; nach zwei fehlgeschlagenen Korrekturen /clear und starten Sie mit einem besseren Prompt neu.
8. Führen Sie keine nicht eingegrenzten „investigate everything“-Erkundungen im Hauptkontext durch — grenzen Sie sie ein oder verlagern Sie sie auf Sub-Agenten.
9. Behandeln Sie Speicherdatei-Anweisungen nicht als Durchsetzungsmechanismus — nutzen Sie Hooks für Regeln, die immer gelten müssen.
10. Bauen Sie keinen Agenten, wenn ein deterministischer Workflow ausreicht.
11. Gehen Sie nicht davon aus, dass größere Kontextfenster alles lösen — beworbenes Fenster ≠ effektives Fenster.
12. Gehen Sie nicht davon aus, dass Context Engineering Prompt Injection behebt — das tut es nicht; Architektur und Least Privilege schon.---

Die ehrlichen Gegenthesen

Ein Artikel, der nur den neuen Begriff vermarktet, ist Marketing. Der skeptische Standpunkt ist real und wurde von namentlich genannten Autor:innen vertreten.

„Es ist nur Prompt Engineering unter neuem Namen“

Simon Willisons ehrliche Darstellung, warum das Rebranding stattfand — der alte Begriff hatte die Kontrolle über seine Bedeutung verloren:

"I’ve spoken favorably of prompt engineering in the past - I hoped that term could capture the inherent complexity of constructing reliable prompts. Unfortunately, most people’s inferred definition is that it’s a laughably pretentious term for typing things into a chatbot!" — Simon Willison, June 2025

"It turns out that inferred definitions are the ones that stick. I think the inferred definition of ’context engineering’ is likely to be much closer to the intended meaning." — Simon Willison

Addy Osmani verteidigt den Begriff, formuliert aber den skeptischen Standpunkt klar: „Prompt Engineering drehte sich darum, eine Frage clever zu formulieren; Context Engineering bedeutet, eine gesamte Informationsumgebung zu konstruieren, damit die KI das Problem zuverlässig lösen kann.“ Und Hidde de Smet, 2026: „2024 war die Formulierung entscheidend. 2026 verstehen Claude und GPT vage Absichten viel besser. Die Ära der ‚Prompt-Zauberer‘ ist vorbei.“ Die Fähigkeit blieb; das Branding wechselte.

Die „Bitter Lesson“-Gegenthese

Rich Sutton, 2019: „The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin.“ Handgefertigte Kontextmechanismen — kuratiertes Retrieval, handgeschriebene Zusammenfassungen, maßgeschneiderte Speicherschemata — sind genau die Art von eingebautem menschlichem Wissen, vor der die Bitter Lesson warnt: Sie werden langfristig von Skalierung überrollt. „We have to learn the bitter lesson that building in how we think we think does not work in the long run.“

Anthropic macht dieselbe Beobachtung aus der Perspektive des Paradigmas: „We’re already seeing that smarter models require less prescriptive engineering, allowing agents to operate with more autonomy.“ Die ehrliche Position: Context Engineering könnte ein Übergangs-Handwerk sein — unverzichtbar jetzt, möglicherweise überholt, sobald Modelle lernen, Kontext selbst zu verwalten.

Sicherheit: Context Engineering behebt keine Prompt Injection

Abgerufener und ausgelagerter Kontext ist unvertrauenswürdiger Input. Willisons tödliches Trilemma — private Daten + unvertrauenswürdige Inhalte + externe Kommunikation — und der Mechanismus: „LLMs are unable to reliably distinguish the importance of instructions based on where they came from. Everything eventually gets glued together into a sequence of tokens and fed to the model.“ Sein Fazit: „we still don’t know how to 100% reliably prevent this from happening.“

OWASP LLM01 (2025): RAG und Fine-Tuning „beheben Prompt-Injection-Schwachstellen nicht vollständig“. Und Speicher macht es schlimmer: „Prompt Injection endet mit dem Schließen der Session. Memory Poisoning bleibt über Sessions hinweg bestehen“ (WorkOS) — weil „ein Agent seine eigenen Erinnerungen als Ground Truth behandelt“. Ein einziger adversarieller Speichereintrag „kann langfristig Einfluss auf das Verhalten des Agenten nehmen“ (Dash et al., arXiv 2606.04329), und bestehende Prompt-Injection-Abwehrmechanismen „decken Memory-Poisoning-Angriffe nicht ab“. Die Lösung liegt in Architektur und Least Privilege, nicht in Kontext-Kuratierung.

Cognition vs. Anthropic: die schärfste aktuelle Debatte

Cognition (Coding-Agents, Reliability-first): standardmäßig single-threaded, vollständige Traces werden geteilt — „mehrere Agenten in Kollaboration führen nur zu fragilen Systemen.“ Anthropic (Forschungs-Agents, breadth-first): Multi-Agent-Ansatz brachte +90,2 % auf ihrem Eval — bei 15-fachen Token-Kosten — und nur für parallelisierbare, hochwertige Aufgaben: „Einige Domänen, die erfordern, dass alle Agenten denselben Kontext teilen oder viele Abhängigkeiten zwischen Agenten aufweisen, sind heute kein guter Anwendungsfall für Multi-Agenten-Systeme.“

Es handelt sich um eine Domänen-Wette, nicht um einen Widerspruch — und beide Seiten sind sich einig über das offene Problem: die Weitergabe von Kontext zwischen Agenten ist ungelöst. Cognition: „Ich sehe niemanden, der sich gezielt darum bemüht, dieses schwierige Problem der Kontextweitergabe zwischen Agenten zu lösen.“

Wann Prompt Engineering nach wie vor der richtige Rahmen ist

Context Engineering ist eine neue Rahmung, kein Ersatz. Klassisches Prompting bleibt der richtige Ansatz, wenn:

• Einzelne Interaktion ohne Schleife oder Retrieval. One-Shot-Klassifikation, Chat-Antworten, Entwürfe, Zusammenfassungen. Es gibt keine Pipeline, die zu optimieren wäre.
• Die 80/20-Regel überlebt das Rebranding: konkret sein, Beispiele zeigen, iterieren. Das ist klassisches Prompt Engineering und liefert den Großteil des Nutzens für Chat- und Coding-Assistenten-Anwendungen.
• Breunig lehnt eine Hierarchisierung der Begriffe ab: „Wenn Prompts Teil von Software sind, sind sie Kontext.“ Und: „Beachten Sie, dass keiner besser ist als der andere! Sie sind einfach unterschiedlich.“
• Der ehrliche Status des Begriffs ist Terminologie-Rekonstruktion. Willisons Begründung lautet, dass „Context Engineering“ die ursprüngliche Bedeutung wiederherstellt, nachdem „Prompt Engineering“ eine abgewertete, implizite Definition angenommen hatte. Wenn Ihr Publikum bereits versteht, dass gutes Prompting die Gestaltung des gesamten Inputs bedeutet, bringt der neue Begriff keinen Mehrwert.
• Kleine, statische Workflows. Kein Retrieval, keine Tool-Schleife, keine lange Historie — ein System-Prompt plus ein paar Beispiele. Das als Context Engineering zu bezeichnen, fügt Zeremonie hinzu, aber keine Fähigkeiten.

Offene Fragen

Ehrlichkeit darüber, was noch nicht geklärt ist:

• Evaluation. NIAH ist ein schwacher Proxy; kein Standard-Benchmark misst die Qualität von Kontext-Pipelines (Tool-Ausstattung, Komprimierung, Speicher) Ende-zu-Ende.
• Komprimierungsgenauigkeit. Was geht bei der Komprimierung der Historie stillschweigend verloren? Es gibt keine veröffentlichte Quantifizierung; Cognition hat ein Modell dafür fine-getunt und bezeichnet es dennoch als „schwer richtig zu machen“.
• Speicherdrift und -vergiftung. Vergiftete Speicher häufen sich an — jede Entscheidung, die auf vergiftetem Speicher basiert, erzeugt neue kontaminierte Speicher. Provenienz-Tracking, Drift-Erkennung, Quarantäne- vs. Löschrichtlinien: vorgeschlagen, aber nicht standardisiert.
• Modellspezifische Ablenkungsgrenzen. Die bekannten Werte (Llama 3.1 405B verschlechtert sich ab ca. 32k; der Gemini-Agent gerät ab 100k in Schleifen) sind modellspezifisch und teilweise anekdotisch. Es gibt kein öffentliches Register; Praktiker messen pro Modellversion neu.
• Überlebt die Disziplin die Bitter Lesson? Wenn allgemeine Methoden weiterhin siegen, wie viel von der heutigen Kontext-Maschinerie ist dann nur ein Gerüst, das bessere Modelle überflüssig machen? Das ist die zentrale offene Frage des Feldes — und die abschließende dieses Artikels.

Das Fazit

Der Prompt war nie das Produkt. Der Kontext war es.

Prompt Engineering fragte nach den richtigen Wörtern. Context Engineering fragt danach, welche Konfiguration des Kontexts am ehesten das gewünschte Verhalten erzeugt — System-Prompt, abgerufene Passagen, Tool-Schemata, Speicherdateien, Komprimierungsrichtlinie, Sub-Agent-Grenzen — in jedem Durchgang kuratiert, denn das Fenster ist ein Budget und jedes Token zahlt Miete.

Prompt Engineering ist nicht verschwunden — es wurde zum Teilbereich degradiert. LangChain: „Prompt Engineering ist ein Teilbereich von Context Engineering. Selbst wenn man den gesamten Kontext hat, spielt es eine entscheidende Rolle, wie man ihn im Prompt zusammenstellt.“ OpenAIs Prompt-Engineering-Leitfaden ist weiterhin online und wird gepflegt; Anthropic hält die besten Praktiken für Prompts als „lebendiges Referenzwerk“ vor. Klarheit, Struktur, Beispiele, Verkettung, Evaluierungen — diese Fähigkeiten blieben unverändert.

Der Kontext ist jedoch Code. Schreiben Sie ihn wie Code: versionieren Sie ihn, kuratieren Sie ihn pro Durchgang, messen Sie ihn mit Evaluierungen, behandeln Sie jedes Token als Kostenstelle. Das Modell ist nur so gut wie der Kontext, den Sie ihm vorgeben — und der Kontext ist ein System, das Sie aufbauen.

Das ist die Disziplin, die Prompt Engineering verschlungen hat.

Quellen

• [1] https://x.com/tobi/status/1935533422589399127 — Tobi Lütke, "I really like the term ’context engineering’ over prompt engineering…" (19. Juni 2025)
• [2] https://x.com/karpathy/status/1937902205765607626 — Andrej Karpathy, "+1 for ’context engineering’ over ’prompt engineering’" (25. Juni 2025)
• [3] https://x.com/tobi/status/1909251946235437514 — Tobi Lütke, "Reflexive AI usage is now a baseline expectation at Shopify" (7. April 2025)
• [4] https://www.langchain.com/blog/the-rise-of-context-engineering/ — Harrison Chase, "The rise of ’context engineering’" (23. Juni 2025)
• [5] https://www.philschmid.de/context-engineering — Phil Schmid, "The New Skill in AI is Not Prompting, It’s Context Engineering" (30. Juni 2025)
• [6] https://rlancemartin.github.io/2025/06/23/context_engineering/ — Lance Martin, "Context Engineering for Agents" (23. Juni 2025)
• [7] https://www.langchain.com/blog/context-engineering-for-agents — LangChain, "Context Engineering" (2. Juli 2025)
• [8] https://arxiv.org/abs/2507.13334 — Mei et al., "A Survey of Context Engineering for Large Language Models" (Juli 2025)
• [9] https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — Anthropic, "Effective context engineering for AI agents" (29. September 2025)
• [10] https://arxiv.org/abs/2005.14165 — Brown et al., "Language Models are Few-Shot Learners" (GPT-3, 2020)
• [11] https://arxiv.org/abs/2201.11903 — Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" (2022)
• [12] https://arxiv.org/abs/2205.11916 — Kojima et al., "Large Language Models are Zero-Shot Reasoners" (2022)
• [13] https://arxiv.org/abs/2310.03714 — Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines" (2023)
• [14] https://arxiv.org/abs/2307.03172 — Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (TACL 2023)
• [15] https://research.trychroma.com/context-rot — Hong, Troynikov, Huber (Chroma), "Context Rot" (Juli 2025)
• [16] https://arxiv.org/abs/2404.06654 — Hsieh et al., "RULER: What’s the Real Context Size of Your Long-Context Language Models?" (COLM 2024)
• [17] https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus — Yichao "Peak" Ji (Manus), "Context Engineering for AI Agents" (Juli 2025)
• [18] https://cognition.ai/blog/dont-build-multi-agents — Walden Yan (Cognition), "Don’t Build Multi-Agents" (Juni 2025)
• [19] https://www.anthropic.com/engineering/built-multi-agent-research-system — Anthropic, "How we built our multi-agent research system" (13. Juni 2025)
• [20] https://arxiv.org/abs/2005.11401 — Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020)
• [21] https://www.anthropic.com/research/building-effective-agents — Anthropic, "Building effective agents" (Dezember 2024)
• [22] https://www.anthropic.com/engineering/writing-tools-for-agents — Anthropic, "Writing effective tools for agents — with agents" (September 2025)
• [23] https://www.anthropic.com/engineering/claude-code-best-practices — Anthropic, "Claude Code: Best practices for agentic coding" (April 2025)
• [24] https://code.claude.com/docs/en/memory — Anthropic, "How Claude remembers your project" (Claude Code memory docs)
• [25] https://modelcontextprotocol.io/docs/getting-started/intro — MCP project, "What is the Model Context Protocol?"
• [26] https://claude.com/blog/context-management — Anthropic, „Managing context on the Claude Developer Platform“ (29. September 2025)
• [27] https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf — OpenAI, „A practical guide to building agents“ (April 2025)
• [28] https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html — Drew Breunig, „How Long Contexts Fail“ (22. Juni 2025)
• [29] https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html — Drew Breunig, „How to Fix Your Context“ (26. Juni 2025)
• [30] https://www.dbreunig.com/2025/06/25/prompts-vs-context.html — Drew Breunig, „Prompts vs. Context“ (25. Juni 2025)
• [31] https://www.dbreunig.com/2025/07/05/cat-facts-cause-context-confusion.html — Drew Breunig, „Cat Facts Cause Context Confusion“ (5. Juli 2025)
• [32] https://simonwillison.net/2025/Jun/27/context-engineering/ — Simon Willison, „Context engineering“ (27. Juni 2025)
• [33] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ — Simon Willison, „The lethal trifecta for AI agents“ (16. Juni 2025)
• [34] https://simonwillison.net/2025/Jun/18/context-rot/ — Simon Willison zu „context rot“ (18. Juni 2025)
• [35] https://genai.owasp.org/llmrisk/llm01-prompt-injection/ — OWASP Gen AI Security Project, „LLM01:2025 Prompt Injection“ (2025)
• [36] https://workos.com/blog/ai-agent-memory-poisoning — Maria Paktiti (WorkOS), „Memory and context poisoning“ (Juni 2026)
• [37] https://arxiv.org/abs/2606.04329 — Dash et al., „From Untrusted Input to Trusted Memory“ (Juni 2026)
• [38] https://hiddedesmet.com/prompt-engineering-that-actually-works — Hidde de Smet, „Prompt Engineering That Actually Works“ (Februar 2026)
• [39] https://addyo.substack.com/p/context-engineering-bringing-engineering — Addy Osmani, „Context Engineering: Bringing Engineering Discipline to Prompts“ (Juli 2025)
• [40] http://www.incompleteideas.net/IncIdeas/BitterLesson.html — Rich Sutton, „The Bitter Lesson“ (2019)
• [41] https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview — Anthropic, „Prompt engineering overview“ (docs)
• [42] https://platform.openai.com/docs/guides/prompt-engineering — OpenAI, „Prompt engineering“ (docs)
• [43] https://arxiv.org/abs/2503.01781 — CatAttack: „Interesting fact: cats sleep for most of their lives“ (2025)
• [44] https://arxiv.org/abs/2505.06120 — Microsoft/Salesforce, sharded-multi-turn prompts study (2025)

Hinweis zur Überprüfung: Jedes Zitat in diesem Artikel stammt wortwörtlich aus einer Primärquelle, die am 2026-09-18 abgerufen und gegen den abgerufenen Text geprüft wurde (Forschungsprotokoll: 46 verifizierte Quellen, 0 erfunden). Zwei Kandidaten fielen durch die Überprüfung und wurden ausgeschlossen.