ki-praxis/manuskript/kapitel-05-context-engineering-write-select-compress-isolate.md

5. Context Engineering in der Praxis: Write – Select – Compress – Isolate

5.1 Der Context-Lifecycle

Kapitel 3 hat begründet, warum Context die Qualität dominiert. Kapitel 4 macht Session, Compact und Handoff operativ. Hier der Context-Lifecycle — Write, Select, Compress, Isolate — plus Model Routing.

These 2: Context Engineering ist die Disziplin, das kleinste hochsignalige Token-Set zu finden und zu halten, das die Wahrscheinlichkeit des gewünschten Outcomes maximiert — bei akzeptablen Kosten und Latenz.
These 3 (Kanon Kap. 3): Select first, nicht Permanent-Load.

Kein Prompt-Zauber: Budget- und Signal-Management für LLM + Harness.

---

5.2 Die vier Kern-Strategien

Dritter Debug-Turn. Der Testfilter war falsch; der Agent hat den vollen Suite-Output reingeholt. Die Spec sitzt in der Mitte. Das Modell klingt selbstsicher und repariert Noise. Niemand hat den Prompt „verschlimmbessert“ — der Budget-Posten hat die Session übernommen.

Bei Coding-Agents ist der größte Kostenposten Input. Die stillen Killer sind fast immer Tool-Outputs: ungefilterter cargo test, JSON-Blob, minifizierter Diff — und Zone A aus Kapitel 3 ist weg. Welcher Posten wie wächst und welche Strategie ihn steuert, steht in Kap. 3.6.

{width=90%}

Die Taxonomy Write – Select – Compress – Isolate ist ein verbreiteter Denkrahmen (u. a. LangChain Context Engineering, 2025) — kein Produktfeature. Gute Systeme kombinieren alle vier; schlechte greifen panisch nur zu Compact und wundern sich, warum die Summary nutzlos ist.

{width=90%}

Strategie	Was sie tut	Typische Mittel	Primärer Nutzen	Typisches Risiko
Write	Information außerhalb des Windows speichern	Scratchpads, AGENTS.md, Progress, Handoff, Memory-Dateien, Issue-Tracker	Überlebt Compact und Session-Reset; versionierbar	Veraltete Memory-Dateien = Context-Gift (Kap. 12)
Select	Nur das gerade Relevante holen	Agentic Search (grep/read), RAG, Knowledge Graphs, JIT-Retrieval	Weniger Rauschen, HEAD-treu bei guter Suche	Falsche Treffer; Index-Drift bei RAG/Graph
Compress	Vorhandenen Context verkleinern	Observation Masking, CLI-/Log-Filter, knappe Output-Richtlinien, /compact	Token, Latenz, oft schärferer Fokus	Detailverlust; falsche Summary verlängert Irrwege
Isolate	Arbeit in getrennte Windows splitten	Sub-Agents, Worktrees, Explore≠Execute-Session	Verhindert Contagion von Explore-Müll	Koordinations-Overhead; schlechte Übergaben

Operative Priorität (nicht Taxonomy-Reihenfolge)

Die Tabelle listet Write zuerst. Die Einsatzreihenfolge — und das, was das Band in der Abbildung nummeriert — ist eine andere Aussage:

1) Select  — holt nur, was die Task jetzt braucht
2) Write   — lagert Entscheidungen, DoD, Stand aus dem Chat aus
3) Compress — erst dann: Masking, Filter, Compact
4) Isolate — bei Komplexität oder Parallelität: neues Window

Compress zuerst ist der klassische Fehler: Du verdichtest Müll und zementierst den Irrweg. Select + Write senken den Druck, bevor du summarisierst. Handoff und neue Session (Kap. 4) sind Write + Isolate; Compact ist Compress; gezieltes Lesen statt Repo-Dump ist Select.

Write lagert in die unteren Memory-Ebenen (Episodic · Semantic · Procedural), damit Working klein bleiben kann — Betrieb in Kapitel 6. ACM (Agentic Context Management): der Agent steuert den eigenen Context mit — Compact vorschlagen, große Outputs in Dateien, Session-Grenze, Sub-Agent für Explore. Ziel: lossless im Repo, reasoning-fokussiert im Window.

---

5.3 Leichte Token-Reduktion: Muster vor Tools

Drei Tools, drei Dashboard-Screenshots, drei „−80 % Tokens“. In der Session: der Agent schreibt Romane, die Suite dumpte 4 000 Zeilen, der JSON-Blob blieb roh. Das Problem war nie „kein Tool“ — es war, welche Quelle du angreifst.

Drei Muster greifen verschiedene Quellen an. Sie lassen sich stacken — aber nicht drei Mal denselben Prozent-Claim addieren.

Muster	Angriffspunkt	Illustrative Instanzen (Stand driftet)
Knappe Output-Richtlinie	Modell-Prosa	Prompt/Skill „kurz antworten“; z. B. Caveman-ähnliche Richtlinien
CLI-/Log-Filter	Shell-/Tool-Output vor dem Window	Hooks, --quiet, head; z. B. RTK-ähnliche Proxies
Inbound-Compression	Strukturierte Payloads (JSON, Logs)	Proxies/Layer; z. B. Headroom-ähnliche Filter

Regel: Spalten Muster und Angriffspunkt entscheiden; Produktnamen nur als optionale Instanzen. Vendor-Claims (Marketing-Prozentzahlen) gelten für eine Quelle — etwa CLI-Filter, die im Schnitt 56 % und auf den lautesten Befehlen bis zu 90 % weniger Ausgabe nennen (RTK, rtk-ai.app, Abruf 2026-11-02) — nicht für die ganze Session, und nicht drei Mal addieren. Pairing darf normale Prosa; Debug braucht einen Bypass für volle Logs; Qualität an der DoD messen, nicht am Token-Dashboard.

5.4 Compress-Hebel: Masking und Compact

Zwei Compress-Hebel stecken oft schon in der Harness — sie greifen, nachdem Muster und Quelle klar sind:

• Observation Masking. Alte Tool-Results durch kurze Platzhalter ersetzen („observation omitted“). Billig, kein Extra-LLM-Call; Test-Logs von vor zwanzig Turns brauchst du selten roh. Oft vergleichbar oder besser als eine volle LLM-Summary. Reversibel: volles Log kann in einer Datei geschrieben bleiben (Write).
• Compact. Operativ: Kapitel 4. Hier nur: Compact schafft Platz, riskiert Detailverlust — Erste Hilfe, kein Ersatz für Select/Write.

Prompt Caching verkleinert keinen Context: Es verbilligt wiederholte Prefixe (System, Schemas, AGENTS.md) und gehört deshalb nicht zu den vier Strategien, sondern zu den Kosten-Hebeln. Grenzen und Risiken: Kap. 3.4; Priorität P0 in 5.8.

Kosten-Hebel außerhalb von Compress: Caching → stabile Prefixe verbilligen.

Messregel: Vorher/Nachher dieselbe Task-Klasse, getrennt nach Posten (prefix / tools / history / output).

---

5.5 Select: RAG vs. Knowledge Graphs vs. Agentic Search

„Wer ruft InvoiceService?“ — zehnmal Repo-Wandern, oder einmal Graph-Nachbarschaft und dann drei gezielte Reads. Select heißt just-in-time holen, was der nächste Schritt braucht — nicht „mehr Index-Produkte kaufen“.

Coding-Agents starten standardmäßig mit Agentic Search: greppen, globben, gezielt lesen. Live am HEAD, keine Index-Pflege, präzise bei Symbolen. Teuer wird es bei wiederholter Breiten-Exploration.

Stand: Manuskript-Snapshot August 2026. Die Ansätze überlappen; die Spalte „Wann einsetzen“ ist eine Heuristik für Coding-Tasks.

Ansatz	Stärke	Schwäche	Wann einsetzen
Agentic Search (grep/read)	Live am HEAD; keine Index-Pflege; präzise bei Symbolen	Teuer bei wiederholter Breiten-Exploration	Default für die meisten Coding-Tasks
RAG (Embeddings/Chunks)	Gut für Prose, Richtlinien, lange Docs, Runbooks	Chunk-Grenzen zerreißen Code-Beziehungen; Index-Drift	Doku-lastige Fragen, Support-Wissen
Knowledge Graph (z. B. Graphify, AST/tree-sitter)	Struktur: Imports, Calls, Nachbarschaft	Graph-Pflege; Kantenqualität variiert; kein Ersatz fürs Lesen	Große Codebases, Blast-Radius, „wer ruft X?“

AST-basierte Graphen beantworten strukturelle Fragen billiger als wiederholtes Repo-Wandern. Claims wie „Nx fewer tokens“ meinen meist Retrieval-Ersparnis gegenüber Blind-Reads — nicht „das Modell wird N-mal klüger“.

Do this: Graph für Navigation und Scope, dann Select der 2–5 entscheidenden Files per Read.
Avoid that: Graph-Report als alleinige Source of Truth ohne HEAD-Check. Nicht vorladen — holen, wenn der nächste Schritt es braucht.

---

5.6 Isolate: Sub-Agents — wann, wie, Hygiene

Explore-Sub hat 40 Dateien gelesen. Der Parent bekommt 15 Zeilen Fazit und Pfade — und schreibt den Fix ohne Explore-Müll im Window. Alltagsgewinn: Context-Isolation, nicht Parallelitäts-Theater.

Vier Konzepte, die nicht in einen Topf gehören:

Konzept	Was es steuert	Kanon
Context-Isolation (Sub-Agent, Session, Worktree)	Contagion im Window; Modellqualität	dieses Kapitel
Model Routing (welches Modell / welche Klasse)	Capability × Kosten × Latenz	5.7
Runtime-Isolation (Container, Sandbox, Permissions)	Host, Secrets, Blast Radius	Kapitel 18
Knowledge-Scope (was der Agent sehen darf)	Progressive Disclosure von Wissen	Kapitel 6

Context-Isolation schützt die Qualität des Fensters. Model Routing steuert Kosten und Latenz. Runtime-Isolation begrenzt den Schaden. Keines ersetzt das andere.

Wann Sub-Agents. Primär Isolation: Explore-Rauschen draußen; riskante Experimente in Worktree oder Sub; parallele Reviews in getrennten Windows; laute Recherche nur als Kurzfazit. Sekundär Spezialisierung: unabhängige Teilaufgaben mit File-Vertrag. Explore und Execute trennen (Kap. 7) ist der Alltagsfall: dasselbe Window für Explore-Müll und Patches liefert schlechter.

Wann kein Sub-Agent. Slice eng, DoD klar, Zone A. Sequenziell und lokal (eine Datei, ein Testfilter). Koordination teurer als der Nutzen (mehr Zeit im Briefing als im Diff). Schlechte Isolation ist teurer als keine: drei Agents, dieselben Files, kein Integrationsvertrag — verteilter Context Rot.

Instanziierungs-Hygiene — derselbe Minimumsatz wie ein guter Task-Prompt (Kap. 14), nur enger:

1. Enger Scope und eigene DoD (agent-prüfbar, wo möglich; Kap. 10)
2. Minimale Context-Übergabe — Pfade, Nebenbedingungen, Ausschlüsse, nötige Skills; nicht den ganzen Parent-Chat
3. Strukturiertes Hand-back — kompakt, signalstark
4. Stop-Regeln — max. Iterationen, Timeout, wann eskalieren (User oder stärkeres Modell, 5.7); Parallel-Writes erst nach Plan-Freigabe (Kap. 22); Low-Maturity: eine M-Stufe zurück (Kap. 21)
5. Isolation der Windows — Sub-Contexts teilen sich nicht History und Tool-Dumps
6. Integrationsvertrag bei parallelen Schreibern — wer darf welche Pfade anfassen

Hand-back ist die kompakte Rückgabe eines Sub-Agents an den Parent — Write in den Parent-Context, nicht Knowledge-Layer-Write-Back (Kap. 6) und nicht Session-Handoff (Kap. 4). Ohne Format wird Isolation zur teuren Illusion. Kanon-Minimalformat (Orchestrierungs-Delta: Kap. 22):

## Sub-Agent Hand-back
- Auftrag / Scope:
- DoD-Status: grün | rot | unklar (+ Commands/Exit-Codes)
- Ergebnis (max. ~15 Zeilen):
- Gelesene / geänderte Pfade:
- Offene Risiken / Annahmen:
- Nicht getan (Ausschlüsse):

Do this: enger Auftrag + Rückgabeformat + getrennte Write-Scopes.
Avoid that: „schau mal über alles“ ohne DoD, ohne Pfadliste, ohne Stop.

---

5.7 Model Routing: Capability, Kosten, Latenz

Isolation beantwortet: in welchem Window? Model Routing: mit welcher Capability und welchem Budget? Viele Harnesses erlauben pro Session, Sub-Agent oder Schritt ein anderes Modell — unter anderen Namen.

Kern: Nicht jede Teilaufgabe braucht das stärkste (teuerste, langsamste) Modell. Latenz ist gleichberechtigt mit Capability und Kosten. „Richtig und zu spät“ ist im Lieferalltag oft teurer als „gut genug und schnell verifiziert“.

Entscheidungsszene: Zwölf Dateien umbenennen — Strong Reasoning: drei Stunden, teuer, Diff okay. Derselbe Slice auf Fast/Cheap: Minuten, grüne Verify. Parallel: Migrations-Plan mit Public-API-Risiko auf Fast starten — und nach zwei widersprüchlichen Spec-Turns eskalieren. Routing ist Budget- und Risiko-Steuerung, kein Geiz.

Das sind Rollenprofile, keine Vendor-Hitliste (Kap. 1.4). Welches Modell hinter „Fast“ oder „Strong“ steckt, wechselt; die Entscheidungsfragen bleiben.

{width=90%}

Modell-Tiers (tool-agnostisch)

Tier	Profil	Typische Rollen im Coding-Alltag
Fast / Cheap	niedrige Latenz, günstig, ausreichend für Routine	mechanische Fixes, Format/Rename, kurzes Grep-Fazit, Boilerplate
Balanced	Alltagscode, mittelkomplex	Standard-Slices, Tests im bekannten Pattern, Refactors mit klarem Scope
Strong Reasoning	hohe Tiefe, teurer, langsamer	Architektur-Trade-offs, knifflige Bugs, Plan unter Unsicherheit
Specialized	Domain oder Modalität	Vision/UI-Screenshots, sehr lange Contexts — nur wenn die Task es verlangt

Default ist nicht Max-Tier. Max-Tier ist die Ausnahme mit Begründung (Risiko, Unsicherheit, gescheiterte billigere Versuche).

Entscheidungskriterien

Die Matrix ist eine Heuristik, kein Scorecard-Ritual. Ein Kriterium kann dominieren — Irreversibilität schlägt Latenzwunsch.

Kriterium	→ eher Fast / Cheap	→ eher Strong Reasoning
Reasoning-Tiefe	mechanisch, lokal, Pattern klar	multi-hop, widersprüchliche Spec, Architektur
Risiko / Irreversibilität	Branch-only, leicht revertierbar	Migration, Security, Public API, Prod-nah
Latenz	interaktives Pairing, enger Feedback-Loop	Batch/Background ok; Qualität vor Wartezeit
Kostenbudget	hoher Volumen-Anteil der Woche	seltener Turn, bei dem Fehler teuer ist
Context-Größe / -Komplexität	eng, selektiert, Zone A	breit, noisig — zuerst isolieren, dann tiern
Parallelisierbarkeit	viele Workers → Fast (sonst explodiert die Rechnung)	wenige kritische Pfade → Strong
Audit / Beobachtbarkeit	Routine, niedrige Review-Last	Compliance, Security-Review, erklärpflichtige Diffs

Faustregeln: Risk × Uncertainty nach oben; Volumen und Interaktivität nach unten. Latenz explizit budgetieren. Eskalieren vor Permanent-Max: Fast/Balanced starten, bei klaren Triggern upgraden. Voller, verrotteter Context auf Strong ist nur teurer Rot — erst Select/Isolate, dann Capability.

Praktische Muster

Muster	Mechanik	Wann es greift
Homogen	gleiches Tier, getrennte Windows	reiner Isolationsschutz ohne Routing-Komplexität
Heterogen	Planner/Architektur auf Strong → Worker auf Fast/Balanced	klarer Plan, viele mechanische Teilaufgaben
Cascading / Escalation	Fast starten → bei DoD-Rot, Widerspruch oder Unsicherheit Strong	Volumen + Qualitätsnetz; spart den Default-Max
Verify-with-stronger	Execute auf Balanced → kritische Prüfung auf Strong	Security, Public API, Migrations-Diffs

Cascading braucht Trigger: DoD nach N Versuchen rot; Unsicherheit; Public API oder Secrets; Reviewer auf Strong widerspricht dem Worker. Dieselbe Logik wie Kapitel 6: Capability on-demand — teures Reasoning erst, wenn Fast/Balanced nicht reicht oder das Risiko es verlangt. Isolation spart Contagion; Routing spart unnötige Capability; Hand-back spart Parent-Budget. Anti-Patterns (Always-Max, Spawn ohne Vertrag): 5.8 und Kap. 19.

---

5.8 Priorität und Sofort-Checkliste

Reihenfolge: P0 = Session/Handoff/Compact (Kap. 4), schlanke AGENTS.md, Ignore-Grenzen, Caching. P1 = Filter/Masking, knappe Outputs, Explore≠Execute (+ Hand-back), Routing-Default. P2+ = Graph/RAG, heterogenes Routing, ACM. P3 (volle Orchestrierung) nur, wenn P0/P1 sitzen — sonst multiplizierst du Rot: Kapitel 22. Context Engineering steuert was im Window liegt; Karpathy-Skills (Kap. 13) steuern was der Agent damit darf.

Heute (P0)

• Context-Auslastung sichtbar (oder grob schätzen)
• Templates: Handoff, Compact-Hints (Anhang A); Progress unter templates/progress-template.md
• AGENTS.md: Compact vorschlagen, keine Secrets, Session-Grenzen
• Eine Ignore-Grenze gegen Such-Müll (node_modules, Build-Artefakte, …)

Diese Woche (P1)

• CLI-Output: Observation-Filter oder Test-Filter/head/--quiet; Masking oder „Log in Datei, Chat kurz“
• Output-Richtlinie: knapper Agent (Pairing-Ausnahme)
• Explore ≠ Execute (Session oder Sub) mit Hand-back
• Eine Task-Klasse: Default-Tier (Fast/Balanced) + Escalate-Trigger

P2+ (Graph/RAG, Inbound-Compression, Verify-with-stronger) nur bei Bedarf — Stufen und Trigger: 5.7; Hebel unten. Messung: Vorher/Nachher einer Task-Klasse (Rot, Nacharbeit, Latenzgefühl).

Wann zuerst welcher Hebel — Nachschlagewerk, kein Ritual.

Situation	Zuerst	Dann	Später / optional
Sofort, fast immer	Cache-stabile Prefixe; schlanke AGENTS.md; Handoff	Masking / Log-Filter; Compact-Hints	Feintuning der Tool-Stack
CLI-/Tool-heavy	CLI-/Observation-Filter; --quiet/Test-Filter	knappe Output-Richtlinie	Inbound-Compression, falls JSON/Logs dominieren
Lange Multi-Turn	Write (Progress/Handoff); proaktives Compact	Masking alter Observations	Neue Session an Themengrenze
Große Codebase	Agentic Search + Ignore-Grenzen	Graph für Struktur	RAG für Docs/Runbooks — nicht als Code-Wahrheit

Spawn ohne Vertrag: 5.6. Default-Tier und Escalate: 5.7. Weitere Do/Avoid-Paare: Kap. 19.5 (Context) und 19.9 (Plattform).

Debug ohne Filter

Agent läuft test → 4 000 Zeilen im Context. Zehn Turns später liegt die DoD in der Mitte; Compact ohne Hint erfindet die Ursache. Zone B, Geld weg, Diff unbrauchbar.

Derselbe Bug, gefiltert

• Select: gezielter Testfilter
• Compress: nur Assertion und Stack-Kopf
• Write: Hypothese ins Progress
• Isolate: nach grünem Fix neue Session, Handoff mit DoD

Derselbe Bug, anderer Lifecycle.

---

Key Takeaways

• Context Engineering maximiert Outcome-Wahrscheinlichkeit pro Token — nicht Füllstand.
• Taxonomy Write – Select – Compress – Isolate; operative Priorität Select → Write → Compress → Isolate.
• Tool-Outputs dominieren oft Budget; Filter/Masking greifen härter als Prompt-Feinschliff.
• Sub-Agents isolieren Context (Hand-back Pflicht); Model Routing weist Capability zu — Default ist nicht Max.

Praktische nächste Schritte

1. Eine P0- und eine P1-Maßnahme aus 5.8 fünf Arbeitstage führen.
2. ACM-Mindestregeln und eine Routing-Skizze in AGENTS.md verankern.
3. Grobe Messung: weniger Rot, weniger Nacharbeit, spürbare Latenz.
4. Weiter: Kapitel 6.