Context Engineering: Die eigentliche Disziplin hinter funktionierenden AI-Agenten

7. April 2026

Wer AI-Agenten baut, investiert meist in bessere Modelle oder groessere Context Windows. Dabei liegen die meisten Fehler nicht an der Modell-Faehigkeit, sondern daran, wie der Kontext konstruiert, weitergegeben und ueber die Zeit gepflegt wird.

Context Engineering ist die Disziplin, einem LLM genau die Informationen, Tools und Formate zu geben, die es fuer eine Aufgabe braucht -- und alles andere wegzulassen. Das Ziel: die kleinste Menge hochsignaler Tokens, die die hoechste Wahrscheinlichkeit fuer ein gutes Ergebnis erzeugt.

Vier Grundbewegungen

In der Praxis laesst sich Context Engineering auf vier Operationen reduzieren:

Context Offloading: Informationen in externe Systeme auslagern, statt alles im Kontext mitzuschleppen
Context Retrieval: Informationen dynamisch nachladen statt alles vorab reinzuladen
Context Isolation: Kontext pro Subtask trennen, damit ein Teilproblem nicht ein anderes kontaminiert
Context Reduction: History kuerzen, aber so, dass entscheidungsrelevante Fakten erhalten bleiben

Das Gegenteil -- Context Pollution -- ist der haeufigste Fehler: zu viel irrelevante, widerspruechliche oder redundante Information, die das Modell ablenkt.

Context Rot und Compaction

Auch innerhalb des technischen Limits degradiert die Leistung eines LLMs, wenn der Kontext waechst. Dieses Phaenomen heisst Context Rot. Die Ursache ist architektonisch: Im Transformer beobachtet jedes Token jedes andere (n²-Interaktion). Mehr Kontext bedeutet duennere Aufmerksamkeit pro Beziehung.

Context Compaction -- das Zusammenfassen und Neuinitialisieren des Kontexts -- ist die Standardantwort. Die Schwierigkeit liegt nicht im Zusammenfassen, sondern darin, was ueberlebt: gescheiterte Ansaetze, erstellte Artefakte, invalidierte Annahmen, offene Unsicherheiten. Eine saubere Zusammenfassung, die sich fuer Menschen gut liest, ist fuer einen Agenten oft wertlos.

Harness statt Modell

Viele vermeintliche Modell-Fehler sind tatsaechlich Harness-Fehler. Der Harness -- alles um das Modell herum, was den Kontext zusammenbaut und pflegt -- entscheidet ueber Prompt-Serialisierung, Tool-Routing, Retry-Policies und was zwischen Schritten erhalten bleibt.

Ein guter Harness ist eine deterministische Schale um einen stochastischen Kern. Er macht den Kontext lesbar, stabil und wiederherstellbar, damit das Modell sein begrenztes Reasoning-Budget fuer die eigentliche Aufgabe nutzen kann.

Kommunikation zwischen Agenten

Bei Multi-Agent-Systemen ist der Instinkt, allen Agenten den gesamten Kontext zu geben. Das fuehrt zu Context Pollution auf jeder Ebene plus massiven KV-Cache-Kosten.

Besser: Agenten kommunizieren ueber Artefakte statt ueber rohe Traces. Ein Such-Agent gibt nicht seine komplette Browsing-History weiter, sondern nur die extrahierten Fakten. Zwischenschritte, gescheiterte Versuche und Explorationen bleiben privat. Nur bei eng gekoppelten Aufgaben (z.B. Debugging) ist begrenztes Trace-Sharing sinnvoll -- aber bewusst und begrenzt, nicht als Default.

Toolsets klein und distinkt halten

Tool-Auswahl ist ein Kontextproblem, das als Faehigkeitsproblem getarnt ist. Je mehr Tools ein Agent hat, desto groesser der Aktionsraum und desto hoeher die Wahrscheinlichkeit falscher Entscheidungen. Tools muessen klar abgegrenzt sein, eindeutige Eingabeparameter haben und minimale funktionale Ueberlappung aufweisen.

Praxisbeispiel: 4.700 PDFs in 45 Minuten

Wie Context Engineering in der Praxis aussieht, zeigt ein Projekt zur Datenextraktion aus 4.700+ Engineering-Zeichnungen. Die Aufgabe: Revisionsnummern aus Title Blocks extrahieren -- manuell 160 Personenstunden Arbeit.

Die Loesung war ein Hybrid-Ansatz, der Context Engineering konsequent anwendet:

Cheapest viable method first: 70-80% der PDFs hatten extrahierbaren Text. PyMuPDF-Regeln erledigten diese Faelle deterministisch, ohne LLM, ohne Kosten.
Context Isolation: Die Suche wurde auf den unteren rechten Quadranten der Seite beschraenkt (wo Title Blocks leben), mit Blocklists gegen False Positives wie Gitterreferenz-Buchstaben und Revisions-Historien-Tabellen.
LLM nur fuer den Rest: Nur die 20-30% bildbasierten PDFs gingen an GPT-4 Vision. Die Prompts durchliefen mehrere Iterationen mit strukturierten Beispielen, expliziten Negativbeispielen und Anti-Memorisierungs-Warnungen.

Ergebnis: 96% Genauigkeit, 45 Minuten statt 4 Wochen, 10-15 Dollar API-Kosten statt 8.000+ Pfund Personalkosten. Neuere Modelle (GPT-5+) brachten bei dieser Aufgabe keinen messbaren Vorteil -- die Obergrenze lag beim Prompt und der Vorverarbeitung, nicht bei der Modell-Faehigkeit.

AI-Wirkung messen statt Adoption zaehlen

Context Engineering als Disziplin braucht auch passende Metriken. LinearBs APEX-Framework adressiert genau das: Statt AI-Adoption zu zaehlen (wie viele Entwickler nutzen Copilot?), misst es die tatsaechliche Wirkung entlang vier Achsen:

AI Leverage: Wie effektiv setzen Teams AI-Tools ein?
Predictability: Bleiben Delivery-Timelines zuverlaessig trotz mehr generiertem Code?
Efficiency: Ressourcennutzung und Waste-Reduktion
Developer Experience: Verbessern die Tools die Arbeit oder belasten sie?

Der Kerngedanke: Schnelleres Coding bedeutet nicht schnellere Delivery. Wenn AI-generierter Code die Review-Queues verstopft, verschiebt sich der Bottleneck nur. APEX verbindet AI-Aktivitaet mit echten Delivery-Ergebnissen.

Einordnung

Context Engineering ist keine Alternative zu Prompt Engineering -- es ist die uebergeordnete Disziplin. Prompt Engineering optimiert einzelne Anweisungen, Context Engineering optimiert das gesamte Informationssystem um das Modell herum. Wer die Memory-Patterns und RAG-Alternativen aus der letzten Woche gelesen hat, erkennt das Muster: Struktur schlaegt Aehnlichkeit, und weniger ist oft mehr.

Fuer die Praxis: Bevor man ein groesseres Modell oder ein groesseres Context Window einsetzt, lohnt es sich zu pruefen, ob der bestehende Kontext nicht einfach besser kuratiert werden muss.

Quellen

Nach oben