Context Engineering

Was ist Context Engineering?

Context Engineering ist die Disziplin, alles zu kontrollieren, was ein KI-Modell zur Inferenzzeit sieht: welche Dateien, Dokumente, Konversationsverläufe, Anweisungen und Tool-Ergebnisse in das Context Window gelangen, in welcher Form und in welcher Reihenfolge. Wo Prompt Engineering eine einzelne Anweisung formt, verwaltet Context Engineering das gesamte Sichtfeld des Modells über eine langlaufende Aufgabe hinweg.

Die wichtigsten Punkte

• Die Qualität des Modell-Outputs ist größtenteils eine Funktion der Input-Qualität. Die Mehrheit der Agenten-Fehlschläge in der Praxis sind Kontext-Fehlschläge: Die richtige Information fehlte, war vergraben oder veraltet.
• Das Context Window ist ein Budget, und jedes Token konkurriert. Die Aufgabe ist Kuration unter einer Einschränkung — entscheiden, was einen Platz verdient und was zusammengefasst oder verworfen wird.
• Mehr Kontext ist eine Kosten, kein kostenloses Upgrade. Irrelevantes Material verschlechtert Genauigkeit und Aufmerksamkeit ebenso wie es die Ausgaben erhöht — ein Fehlermuster namens Context Rot.
• In agentischen Systemen liegt hier der Hebel, weshalb Instruktionsdateien, Retrieval-Design, Compaction und Subagenten-Grenzen die tragenden Entscheidungen sind.

So funktioniert es

Alles, was ein Modell über Ihre Aufgabe weiß, kommt über einen Kanal an: die Tokens in seinem Kontext zur Inferenzzeit. Das Modell hat Trainingswissen, aber nichts über Ihre Codebasis, Ihr Ticket oder die letzte Stunde Arbeit, es sei denn, diese Tokens sind vorhanden. Context Engineering ist das Design dieses Kanals, und es zerfällt in drei wiederkehrende Probleme. Selektion: Von allem Verfügbaren, was braucht dieser Schritt der Aufgabe tatsächlich? Kompression: Für Material, das zählt, aber groß ist, was überlebt — Volltext, eine Zusammenfassung, oder nur ein Verweis, dem das Modell später folgen kann? Anordnung und Rahmung: Wo sitzt jedes Stück, und wie ist es beschriftet, damit Anweisungen, Referenzmaterial und nicht vertrauenswürdige Daten unterscheidbar bleiben?

In agentischen Workflows zeigen sich diese Entscheidungen als konkrete Maschinerie. Ein KI-Coding-Agent erhält nicht das Repository; er erhält Suchergebnisse, die Dateien, die er zu öffnen wählte, und den Output der Befehle, die er ausführte, was bedeutet, dass die Tools und ihre Beschreibungen selbst Context-Engineering-Flächen sind. Instruktionsdateien wie AGENTS.md injizieren dauerhaftes Projektwissen, Konventionen, Befehle und Grenzen zu Sitzungsbeginn, sodass es nie neu entdeckt werden muss. Retrieval-Augmented Generation zieht relevante Dokumente bei Bedarf herein, statt in jeder Anfrage präsent zu sein. Bei langen Aufgaben fasst Compaction älteren Verlauf zusammen, um Budget zurückzugewinnen, und Agent Memory hält fest, was die Sitzung überdauern soll. Wenn ein Fenster ein Problem nicht fassen kann, teilt Orchestrierung es auf: Subagenten arbeiten in frischen Fenstern und liefern Schlussfolgerungen statt Transkripte zurück, was Context Engineering auf Architekturebene angewendet ist.

Der rote Faden ist, dass all das Engineering im gewöhnlichen Sinn ist. Es gibt Budgets, Kompromisse, Fehlermodi und messbare Ergebnisse, und Teams, die den Kontext als gestaltetes Artefakt behandeln, bekommen kategorisch besseres Agentenverhalten als Teams, die alles zusammenwerfen und hoffen. Der Einsatz ist quantifizierbar: In Anthropics BrowseComp-Evaluation seines Multi-Agenten-Forschungssystems von 2025 erklärte Token-Nutzung allein 80 % der Leistungsvarianz [1].

Beispiel

Ein Agent produziert wiederholt falsche Fixes in einem großen Monorepo: plausible Patches, die nicht existierende Module referenzieren, Konventionen aus dem falschen Service. Der Instinkt des Teams ist, das Modell zu beschuldigen, aber das Transkript zeigt das echte Problem — einen Kontext vollgestopft mit einer riesigen generischen Instruktionsdatei, drei veralteten Architekturdokumenten und ganzen Datei-Dumps aus früheren Schritten, wobei die tatsächlich relevanten Service-Konventionen nirgendwo präsent sind. Sie bauen die Kontext-Pipeline neu: eine gekürzte Root-Instruktionsdatei, Per-Service-Konventionsdateien, die nur geladen werden, wenn der Agent diesen Service berührt, Retrieval, das die zehn relevantesten Code-Chunks statt ganzer Dateien zurückgibt, und Compaction nach jeder Teilaufgabe. Dasselbe Modell, dieselben Prompts, und das Problem der halluzinierten Module verschwindet größtenteils. Am Modell hat sich nichts geändert; an seinem Sichtfeld schon.

Häufige Missverständnisse

Die Intuition, die am gründlichsten scheitert, ist "im Zweifel einschließen." Große Context Windows machen es möglich, alles hineinzukippen, sodass Teams Agenten ausliefern, bei denen jede Anfrage die vollständige Instruktionsdatei, einen kompletten Wiki-Export und Tausende Zeilen offener Dateien mitträgt. Das Ergebnis ist schlechter, nicht sicherer. Attention über sehr lange Inputs ist unvollkommen, sodass kritische Details im Füllmaterial verlorengehen; nahezu relevantes, aber falsches Material — ein veraltetes Dokument, eine ähnliche Funktion aus einem anderen Service — zieht das Modell aktiv zu falschen Antworten; und jedes verschwendete Token wird bei jedem Aufruf bezahlt. Chromas technischer Bericht zu Context Rot von 2025 evaluierte 18 Modelle, darunter GPT-4.1, Claude 4 und Gemini 2.5, und fand, dass alle mit wachsender Input-Länge unzuverlässiger werden, selbst bei einfachen Aufgaben [2]. Relevanz schlägt Volumen. Die Disziplin heißt genau deshalb Engineering, weil sie bedeutet, Entscheidungen zu treffen, und nicht zu wählen ist selbst eine Wahl mit den schlechtesten Eigenschaften.

FAQ

Ersetzt Context Engineering Prompt Engineering? Es hat es aufgesogen. Prompt Engineering überlebt als das Handwerk, eine Komponente gut zu schreiben — die Anweisung, die Tool-Beschreibung, die Vorlage. Context Engineering ist die System-Ebenen-Disziplin, in der diese Komponenten leben, und in agentischer Arbeit dominieren die Entscheidungen auf Systemebene die Ergebnisse.

Warum entstand Context Engineering als eigene Disziplin? Weil Agenten das Input-Problem dynamisch gemacht haben. Ein Chat-Prompt wird einmal von einem Menschen komponiert; der Kontext eines Agenten wird bei jedem Schritt neu aus Tool-Ergebnissen, Dateien und Verlauf zusammengesetzt, über Aufgaben, die Stunden laufen. Die Volumina sind auch anders: Anthropic fand 2025, dass Agenten typischerweise etwa 4x mehr Tokens nutzen als Chat-Interaktionen, und Multi-Agenten-Systeme etwa 15x mehr [3]. Diesen Strom gut zu verwalten, erwies sich als der Ort, an dem der meiste Aufwand und der meiste Hebel beim Bau von Agenten tatsächlich liegen.

Was sind die grundlegenden Techniken, mit denen man anfängt? Instruktionsdateien kurz und wahr halten, eng statt breit abrufen, veralteten Verlauf bei langen Aufgaben zusammenfassen oder verwerfen, große Teilprobleme in Subagenten mit frischen Fenstern isolieren, und regelmäßig den tatsächlich zusammengestellten Kontext Ihres Agenten lesen. Letzteres ist die wertvollste Gewohnheit: Die meisten Kontext-Fehlschläge sind offensichtlich, sobald ein Mensch endlich hinschaut.

Quellen

1. Anthropic Engineering. "Token-Nutzung erklärte 80 % der Leistungsvarianz in der BrowseComp-Evaluation von Anthropics Multi-Agenten-Forschungssystem." https://www.anthropic.com/engineering/multi-agent-research-system. Abgerufen im August 2026.
2. Chroma Research. "Context-Rot-Bericht: 18 LLMs werden mit wachsender Input-Kontextlänge zunehmend unzuverlässiger." https://www.trychroma.com/research/context-rot. Abgerufen im August 2026.
3. Anthropic Engineering. "Agenten nutzen etwa 4x mehr Tokens als Chat-Interaktionen; Multi-Agenten-Systeme etwa 15x mehr." https://www.anthropic.com/engineering/multi-agent-research-system. Abgerufen im August 2026.