Context-Engineering: Kontext als knappe Ressource behandeln

Beim Bau von Agenten verschiebt sich die zentrale Fertigkeit. Es geht nicht mehr darum, den einen perfekten Prompt zu formulieren, sondern darum, bei jedem Schritt die richtige Teilmenge an Information im Kontextfenster zu haben. Diese Disziplin heisst Context-Engineering. Sie ist die technische Begründung für viele Agenten-Praktiken, von schlanken Instruktionsdateien bis zu Subagenten. Dieser Guide erklärt das Prinzip generisch und zeigt vier konkrete Techniken.

1. 🎯 Vom Prompt-Engineering zum Context-Engineering

Prompt-Engineering fragt: Wie formuliere ich diese eine Anweisung gut? Context-Engineering fragt: Welche Tokens sollen überhaupt im Fenster stehen, wenn das Modell denkt? Das ist die umfassendere Frage, weil ein Agent über viele Schritte läuft und sein Kontext sich bei jedem Schritt ändert: Tool-Ergebnisse kommen dazu, alte Zwischenstände werden irrelevant.

Anthropic definiert es als das fortlaufende Kuratieren der optimalen Token-Menge während der Inferenz. Das Leitprinzip lautet: die kleinste Menge an Tokens mit dem höchsten Signal finden, die das gewünschte Ergebnis am wahrscheinlichsten macht. Nicht “so viel Kontext wie möglich”, sondern “so viel wie nötig, so wenig wie geht”.

2. 🧠 Das Aufmerksamkeits-Budget

Warum ist mehr Kontext nicht einfach besser? Weil ein Modell ein begrenztes Aufmerksamkeits-Budget hat. Jedes zusätzliche Token zehrt daran. Technisch liegt das an der Transformer-Architektur: n Tokens erzeugen in etwa n-mal-n Beziehungen untereinander, die das Modell gewichten muss. Je voller das Fenster, desto schlechter erinnert sich das Modell zuverlässig an einzelne Inhalte. Dieses Phänomen wird “context rot” genannt: Qualität verfällt, nicht weil die Information fehlt, sondern weil sie in zu viel Rauschen ertrinkt.

Andrej Karpathy liefert das passende Bild: Ein Sprachmodell ist wie ein Kollege mit anterograder Amnesie, der nur Kurzzeitgedächtnis hat. Alles, was es “weiss”, muss im Kontextfenster stehen, und dieses Fenster ist klein und teuer. Man füllt es also nicht achtlos.

3. 📚 Analogie: der Schreibtisch in der Bibliothek

Stell dir Wissensarbeit an einem Schreibtisch in einer grossen Bibliothek vor. Das Regal ist riesig (alle verfügbaren Daten), aber der Schreibtisch ist klein (das Kontextfenster). Wer den ganzen Tisch mit Büchern volllädt, findet nichts mehr und arbeitet langsamer. Die Kunst ist, nur die zwei, drei relevanten Bände aufzuschlagen, den Rest im Regal zu lassen und gezielt nachzuholen, wenn man ihn braucht.

Das Aufmerksamkeits-Budget ist die Tischfläche. Context-Engineering ist die Disziplin, den Tisch aufgeräumt zu halten: das Richtige drauf, das Erledigte weg, den Rest griffbereit im Regal. Genau dieses Bild trägt die vier Techniken im nächsten Abschnitt.

4. 🛠️ Vier praktische Techniken

Schlanke Instruktionen. Die Anweisungsdatei (AGENTS.md oder vergleichbar) liegt von Anfang an im Kontext. Deshalb muss sie knapp sein. Faustregel: Bei jeder Zeile fragen, ob ihr Wegfall das Modell Fehler machen liesse. Wenn nein, streichen. Eine überladene Instruktionsdatei führt dazu, dass das Modell die wichtigen Anweisungen übersieht.

Just-in-time statt Vorab-Laden. Statt das gesamte Wissen vorab in den Kontext zu kippen oder aufwendig zu indexieren, hält der Agent nur leichte Verweise (Dateipfade, Suchanfragen, Links) und lädt den Inhalt erst, wenn er ihn braucht. Werkzeuge wie Datei-Suche (glob, grep) holen gezielt nach. Das umgeht veraltete Indizes und hält den Tisch frei.

Subagenten. Eine Teilaufgabe wird an einen Subagenten mit eigenem, frischem Kontextfenster delegiert. Dieser darf intern viel Kontext verbrauchen (zehntausende Tokens), gibt aber nur eine verdichtete Zusammenfassung von ein- bis zweitausend Tokens zurück. So bleibt das Hauptfenster sauber. Das ist dieselbe Logik wie beim agentischen Flywheel und beim Rollen-Setup: spezialisierte Einheiten mit klaren Grenzen.

Compaction und Notizen. Nähert sich ein langer Lauf der Fenstergrenze, fasst man den bisherigen Verlauf zusammen und startet mit dieser Zusammenfassung neu (Compaction). Ergänzend kann der Agent dauerhafte Notizen ausserhalb des Fensters schreiben und gezielt wieder einlesen (agentisches Gedächtnis). Beides ist der Versuch, die fehlende Langzeiterinnerung des Modells extern nachzubauen.

5. 🪜 So wendest du es an

  1. Audit der Instruktionsdatei. Streiche alles, was nicht nachweislich Fehler verhindert. Ziel: kurz und menschenlesbar.
  2. Ersetze Vorab-Dumps durch Verweise. Gib dem Agenten Wege, Information zu holen (Suche, Dateizugriff), statt alles vorzukauen.
  3. Lagere teure Teilaufgaben in Subagenten aus. Recherche, breite Suche, Exploration laufen isoliert und liefern nur das Destillat zurück.
  4. Plane für lange Läufe. Definiere, wann zusammengefasst (Compaction) und wann in Notizen ausgelagert wird.
  5. Miss das Token-Budget. Token-Verbrauch korreliert stark mit Leistung und mit Kosten. Wer ihn beobachtet, erkennt aufgeblähten Kontext früh.

6. 🧩 Konkret: mit Subagenten arbeiten (am Beispiel Claude Code)

Subagenten klingen abstrakt, sind aber in Claude Code einfach Dateien. Ein Subagent ist eine Markdown-Datei unter .claude/agents/ (projektweit) oder ~/.claude/agents/ (für alle deine Projekte). Die Frontmatter sagt, wer er ist und was er darf, der Rumpf ist sein System-Prompt:

# Datei: .claude/agents/recherche.md
---
name: recherche
description: Recherchiert ein Thema breit im Web und gibt eine knappe,
  zitierte Zusammenfassung zurück. Nutze diesen Agenten, wenn mehrere
  Quellen gesichtet werden müssen.
tools: WebSearch, WebFetch, Read
model: sonnet
---
Du bist ein Recherche-Agent. Sammle aus mehreren Quellen die relevanten
Fakten, prüfe sie gegeneinander und gib NUR eine verdichtete Zusammenfassung
mit Quellen-Links zurück, keine Rohtexte. Halte dich kurz.

Wie die Delegation passiert (der “Flow”). Du musst den Subagenten nicht von Hand aufrufen. Der Hauptagent liest deine Aufgabe und delegiert automatisch, wenn sie zur description passt. Stellst du also die Frage “Vergleiche drei Datenbanken anhand aktueller Quellen”, erkennt er “mehrere Quellen sichten” und schickt die Arbeit an recherche. Der entscheidende Punkt fürs Context-Engineering: Der Subagent läuft in einem eigenen Kontextfenster, darf darin zehntausende Tokens verbrauchen, und gibt nur die kurze Zusammenfassung zurück. Dein Hauptfenster bleibt sauber.

Erzwingen geht auch. Du kannst explizit sein: “Nutze den recherche-Agenten für jede der drei Datenbanken.” Dann startet er sie sogar parallel, jede in ihrem eigenen Fenster. Verwalten und neu anlegen kannst du Subagenten mit dem Befehl /agents.

Damit es zuverlässig automatisch passiert, drehst du an zwei Schrauben: Erstens die description handlungsorientiert formulieren (“Nutze diesen Agenten, wenn …”), denn sie ist der Auslöser. Zweitens eine Regel in die Instruktionsdatei schreiben, etwa in AGENTS.md: “Für Recherche-Aufgaben immer den recherche-Subagenten nutzen.” Damit wird das Delegieren Teil des Harness, statt von deinem Tagesform-Prompt abzuhängen. Das ist die Brücke zum agentischen Flywheel und zu den Instruktionsdateien.

Und der Bezug zum Rollen-Setup: Die sechs Rollen-Prompts aus dem agentischen Rollen-Setup sind genau solche Subagenten-Dateien. Sie haben bereits name- und description-Frontmatter plus einen System-Prompt. Du kannst sie direkt nach .claude/agents/ legen und hast einen QA-, einen Developer-, einen Security-Agenten, jeder mit eigenem, sauberem Kontext. Sie sind die “spezialisierten Einheiten mit klaren Grenzen”, von denen Abschnitt 4 spricht.

Anwendung: Second Brain

Mein Brain-Setup nutzt genau dieses Muster. Die AGENTS.md bleibt bewusst knapp und liegt vorab im Kontext, während die eigentlichen Wissensseiten erst bei Bedarf über Datei-Suche geladen werden, statt alles vorab zu indexieren. Der Ingest- und der Lint-Lauf eignen sich für Subagenten, die je einen Teil isoliert bearbeiten. Das passt zur Grundidee von LLM-Wiki trifft OKF: Wissen einmal kompiliert ablegen und gezielt nachladen, statt es bei jeder Frage neu in den Kontext zu zwingen.

📚 Weiterführende Links & Quellen

Intern:

Extern: