Phillip Pham, AI Developer bei Pexon Consulting | 9 Min. Lesezeit | 22.09.2026
TL;DR: Context Engineering in fünf Sätzen
Context Engineering ist die Auswahl und Pflege der Informationen, die ein Sprachmodell in jedem Schritt sieht: Systemprompt, Werkzeuge, Verlauf und geladene Daten. Mehr Kontext macht Modelle nicht besser, sondern ungenauer. Gute Agenten laden Daten erst bei Bedarf. Lange Aufgaben brauchen Compaction, Notizen und Subagenten. Pexon Consulting (ISO 27001) baut das in Agenten-Plattformen ein.
| Disziplin | Optimiert | Typische Frage |
|---|---|---|
| Prompt Engineering | eine Anfrage | Wie formuliere ich die Aufgabe? |
| Context Engineering | ein Kontextfenster | Welche Informationen gehören jetzt hinein? |
| Harness Engineering | Sitzungen und Agenten hinweg | Wie findet der nächste Lauf den Stand, und wer prüft das Ergebnis? |
| Loop Engineering | wiederkehrende Läufe | Was weckt den Agenten, ohne dass jemand promptet? |
Das Problem: Mehr Kontext macht Agenten schlechter
Das klingt paradox, ist aber gut belegt. Anthropic beschreibt das Phänomen in seinem Engineering-Artikel „Effective context engineering for AI agents“ vom 29. September 2025 als Context Rot: Je mehr Tokens im Kontextfenster stehen, desto schlechter kann das Modell einzelne Informationen daraus abrufen. Die Ursache ist ein begrenztes Aufmerksamkeitsbudget. Jedes zusätzliche Token verbraucht einen Teil davon.
Für einen Chat mit drei Fragen ist das egal. Für einen Agenten, der über eine Stunde Dateien liest, Werkzeuge aufruft und Ergebnisse sammelt, ist es das Kernproblem. Nach vierzig Werkzeugaufrufen steht das Kontextfenster voller alter Suchergebnisse, und die eigentliche Aufgabe vom Anfang ist nur noch eine Zeile unter vielen.
Große Kontextfenster lösen das nicht. Sie verschieben nur den Punkt, an dem es kippt. Deshalb halten wir die verbreitete Haltung „wir nehmen einfach das Modell mit dem größten Fenster und laden alles hinein“ für den teuersten Fehler beim Agentenbau: Man zahlt für jedes Token und bekommt schlechtere Antworten.
Was ist Context Engineering?
Anthropic definiert Context Engineering als die Strategien, mit denen man die optimale Menge an Tokens während der Inferenz auswählt und pflegt. Prompt Engineering ist darin ein Teil. Context Engineering umfasst zusätzlich alles, was sonst im Fenster landet:
- Systemprompt: die Regeln und die Rolle des Agenten
- Werkzeugbeschreibungen: jedes Tool kostet Kontext, bevor es überhaupt genutzt wird
- Beispiele: wenige, typische statt vieler Sonderfälle
- Verlauf: Nachrichten, Werkzeugaufrufe und deren Ergebnisse
- Externe Daten: Dokumente, Suchtreffer, Dateien, Datenbankauszüge
Der Unterschied zum Prompt Engineering liegt in der Zeitachse. Ein Prompt wird einmal geschrieben. Der Kontext eines Agenten ändert sich mit jedem Schritt, und jemand muss entscheiden, was bleibt, was geht und was nachgeladen wird. Dieser Jemand ist heute meist niemand, und genau daran scheitern viele Piloten.
Die vier Hebel im Kontextfenster
Systemprompt in der richtigen Höhe. Anthropic spricht von der „richtigen Flughöhe“: konkret genug, um das Verhalten zu lenken, aber allgemein genug, um dem Modell Spielraum für eigene Heuristiken zu lassen. Zu tief heißt: hart codierte Wenn-dann-Logik, die bei der ersten Ausnahme bricht. Zu hoch heißt: vage Ziele, die geteiltes Wissen voraussetzen, das das Modell nicht hat.
Wenige, klare Werkzeuge. Jedes Tool mit Beschreibung und Parametern belegt Platz. Überschneiden sich zwei Tools, weiß das Modell nicht, welches es nehmen soll. Unsere Regel aus Projekten: Wenn ein Mensch nicht in einem Satz sagen kann, wann welches Tool dran ist, kann das Modell es auch nicht.
Beispiele statt Regelkataloge. Drei gut gewählte Beispiele zeigen das erwartete Verhalten besser als eine Liste mit zwanzig Sonderfällen.
Daten erst bei Bedarf laden. Das ist der größte Hebel, deshalb bekommt er einen eigenen Abschnitt.
Just in time statt alles vorab laden
Viele RAG-Systeme laden vor der ersten Antwort die zehn ähnlichsten Textstücke in den Kontext, ob sie passen oder nicht. Agenten können es anders machen: Sie halten nur Verweise, etwa Dateipfade, Tabellennamen oder Links, und laden den Inhalt erst, wenn sie ihn brauchen.
Claude Code arbeitet so. Es liest nicht das ganze Repository ein, sondern sucht gezielt mit Werkzeugen wie Grep und Glob und öffnet dann einzelne Dateien. Der Kontext bleibt klein, und das Modell sieht zu jedem Zeitpunkt, was für den aktuellen Schritt zählt. Warum diese exakte Suche bei Agenten so gut funktioniert, steht in unserem Artikel über BM25 und die Suche von KI-Agenten.
Der Preis dafür ist Zeit: Jedes Nachladen ist ein weiterer Schritt. In der Praxis mischen wir deshalb. Was fast jede Aufgabe braucht, etwa Projektregeln oder die Beschreibung der Datenstruktur, steht fest im Kontext. Alles andere wird geholt.
Lange Aufgaben: Compaction, Notizen, Subagenten
Irgendwann reicht auch der sparsamste Kontext nicht mehr. Für Aufgaben über viele Stunden nennt Anthropic drei Techniken, die heute auf der Claude-Plattform als Funktionen bereitstehen:
| Technik | Was passiert | Auf der Claude API (Stand 09/2026) |
|---|---|---|
| Compaction | Ältere Verlaufsteile werden durch eine Zusammenfassung ersetzt | Beta, auf Abruf mit Header compact-2026-09-04 oder ab einer Token-Schwelle |
| Context Editing | Alte Werkzeugergebnisse oder Denkblöcke werden nach Regel entfernt | Beta, Header context-management-2025-06-27 |
| Strukturierte Notizen | Der Agent schreibt Wichtiges in Dateien außerhalb des Fensters | Beta, Memory Tool memory_20250818 |
| Subagenten | Spezialisierte Agenten arbeiten mit eigenem Fenster und liefern nur eine Zusammenfassung zurück | Muster, in Claude Code und im Agent SDK |
Die Compaction ab einer Token-Schwelle gibt es seit Februar 2026, die Compaction auf Abruf seit dem 14. September 2026. Sie ersetzt die Zusammenfassung, die Entwickler bisher selbst geschrieben haben, kann im Hintergrund laufen und die letzten Nachrichten wörtlich stehen lassen.
Context Editing ist der unterschätzte Teil. Ein Beispiel aus der Anthropic-Dokumentation, leicht gekürzt: Ab 30.000 Eingabe-Tokens werden alte Werkzeugergebnisse entfernt, die letzten drei bleiben, Ergebnisse der Websuche bleiben immer.
curl https://api.anthropic.com/v1/messages \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "anthropic-beta: context-management-2025-06-27" \
--header "content-type: application/json" \
--data '{
"model": "claude-opus-5",
"max_tokens": 4096,
"messages": [{"role": "user", "content": "Prüfe die offenen Tickets."}],
"context_management": {
"edits": [{
"type": "clear_tool_uses_20250919",
"trigger": {"type": "input_tokens", "value": 30000},
"keep": {"type": "tool_uses", "value": 3},
"exclude_tools": ["web_search"]
}]
}
}'
Zusammen mit dem Memory Tool wird daraus ein sauberer Ablauf: Kurz bevor alte Ergebnisse verschwinden, bekommt Claude laut Doku eine Warnung und kann Wichtiges in eine Datei schreiben. Anthropic zeigt das Prinzip mit einem Agenten, der über Stunden Pokémon spielt und sich Fortschritt, Ziele und Karten in Notizen merkt.
Worauf wir in Projekten achten
Aus unseren Agenten-Projekten fünf Punkte, die fast immer den Unterschied machen:
- Kontext messen, nicht schätzen. Wie viele Tokens verbrauchen Systemprompt, Tools und ein typischer Verlauf? In Claude Code zeigt
/contextdie Aufteilung. Ohne diese Zahl ist jede Optimierung geraten. - Werkzeuge ausdünnen. Zwanzig MCP-Server anzubinden, weil es geht, kostet Kontext bei jedem Aufruf. Wir binden nur an, was die Aufgabe braucht.
- Werkzeugergebnisse kürzen. Ein Tool, das 5.000 Zeilen Log zurückgibt, ist falsch gebaut. Es sollte filtern und zusammenfassen, bevor der Agent es sieht.
- Zustand in Dateien, nicht im Verlauf. Was der nächste Schritt wissen muss, gehört in eine Notiz oder eine Fortschrittsdatei, nicht in Nachricht 83.
- Am Ergebnis testen. Ob ein kleinerer Kontext hilft, zeigt nur ein Test mit echten Aufgaben: richtige Antwort, Zahl der Schritte, Kosten.
Wir raten ausdrücklich davon ab, Context Engineering als Prompt-Feinschliff zu behandeln. Es ist Architektur: welche Daten wo liegen, welche Tools es gibt und wann was gelöscht wird. Wer das nicht plant, bekommt einen Agenten, der in der Demo glänzt und nach einer Stunde Echtbetrieb den Faden verliert.
Häufig gestellte Fragen
Was ist Context Engineering?
Context Engineering ist die Auswahl und Pflege aller Informationen, die ein Sprachmodell bei jedem Schritt sieht: Systemprompt, Werkzeugbeschreibungen, Beispiele, Verlauf und geladene Daten. Ziel ist der kleinste Kontext, der für die Aufgabe reicht, weil Modelle mit wachsendem Kontext Details schlechter wiederfinden.
Was ist der Unterschied zwischen Prompt Engineering und Context Engineering?
Prompt Engineering optimiert die Formulierung einer Anfrage. Context Engineering optimiert alles, was im Kontextfenster steht, und zwar über viele Schritte hinweg. Bei einem einzelnen Chat fällt beides fast zusammen, bei Agenten mit Werkzeugen und langen Aufgaben wird Context Engineering zur Hauptarbeit.
Was bedeutet Context Rot?
Context Rot beschreibt, dass Sprachmodelle Informationen schlechter abrufen, je mehr Tokens im Kontextfenster stehen. Anthropic führt das auf ein begrenztes Aufmerksamkeitsbudget zurück. Große Kontextfenster verschieben das Problem, sie lösen es nicht. Deshalb lohnt es sich, Kontext klein zu halten.
Was ist der Unterschied zwischen Compaction und Context Editing?
Compaction ersetzt ältere Teile des Verlaufs durch eine Zusammenfassung. Context Editing entfernt nach festen Regeln bestimmte Inhalte, etwa alte Werkzeugergebnisse oder Denkblöcke, ohne zusammenzufassen. Beide sind auf der Claude API im September 2026 in der Beta und lassen sich mit dem Memory Tool (ebenfalls Beta) kombinieren.
Braucht jedes Unternehmen Context Engineering?
Für einfache Chat-Anwendungen reicht meist ein guter Systemprompt. Sobald Agenten Werkzeuge aufrufen, lange Aufgaben bearbeiten oder mit vielen Dokumenten arbeiten, wird Context Engineering Pflicht. Dann entscheidet es über Kosten und Qualität mehr als die Wahl des Modells.
Nächster Schritt
Verwandte Themen
→KI-Agenten auf der eigenen Plattform
→Agent Harness: warum das Modell nicht alles ist
→Loop Engineering mit Claude Code
→BM25: wie KI-Agenten suchen



