Der Komplexitäts-Burnout in der KI-Entwicklung
Die KI-Entwicklung leidet an einem Paradoxon: Die Modelle werden stärker, ihre Orchestrierung versinkt in technischer Redundanz. Frameworks wie LangChain, CrewAI oder AutoGen versprechen Automatisierung, erkaufen sie aber mit Engineering-Overhead — und mit einer Black Box, die schwer zu kontrollieren und noch schwerer zu warten ist. Schon eine simple Prompt-Änderung zwingt oft zu Eingriffen in den Anwendungscode.
Die Interpretable Context Methodology (ICM) von Jake Van Clief und David McDermott dreht das um. Statt Komplexität mit mehr Code zu bekämpfen, reaktiviert sie Prinzipien der Unix-Philosophie: Programme, die genau eine Sache gut machen, und Klartext als universelle Schnittstelle. Die These lautet: Die effizienteste Agenten-Architektur ist kein neuer Code-Stack, sondern eine durchdachte Dateisystem-Struktur.
Für Dienstleister heißt das weniger Abhängigkeit von Entwicklern im Tagesbetrieb und mehr Transparenz an jedem Schritt. Wer Agenten ohnehin Workflow-first statt als Chatbot denkt, findet hier das passende strukturelle Fundament.
Die Ordnerstruktur ist die Architektur
Der Kern von ICM: Die Orchestrierungslogik wandert aus dem Python-Code in das Dateisystem. Nummerierte Ordner (01_research, 02_script) repräsentieren die Phasen eines Workflows. Ein einzelner Agent — in der Praxis oft ein Team, bei dem ein Orchestrator-Modell Teilaufgaben an günstigere Modelle delegiert — navigiert durch diese Struktur.
Der zentrale Kontrollpunkt ist die Datei CONTEXT.md in jedem Phasen-Ordner. Ihre Inputs Table definiert per Selective Section Routing exakt, welche Abschnitte welcher Dateien geladen werden. Van Clief bringt es auf den Punkt: „The folder structure tells it what to do at each step ... the coordination logic lives in the filesystem, not in application code.“
Die Nummerierung kodiert die Ausführungsreihenfolge, die Ordnergrenzen erzwingen Separation of Concerns, und der Output einer Phase wird zum Input der nächsten. Koordination entsteht nicht durch versteckte Abstraktion, sondern durch eine physische Anordnung, die Mensch und Maschine gleich gut lesen.
workspace/
CLAUDE.md # Layer 0 – globale Identität & Workspace-Regeln
CONTEXT.md # Layer 1 – Task-Routing auf Workspace-Ebene
01_research/
CONTEXT.md # Layer 2 – Phasen-Kontrakt + Inputs Table
output/ # Layer 4 – Artefakt dieser Phase
02_script/
CONTEXT.md
output/
_config/ # Layer 3 – stabile Regeln (die "Fabrik")
references/ # Layer 3 – Markenstimme, Design-SystemLayered Context: der Sieg über „Lost in the Middle“
Monolithische Prompts haben ein Qualitätsproblem: Je länger der Kontext, desto schlechter die Nutzung. Die Studie „Lost in the Middle“ (Liu et al., Stanford) zeigt ein U-förmiges Muster — Modelle finden Informationen am Anfang und Ende zuverlässig, in der Mitte langer Kontexte (40.000+ Token) fällt die Leistung deutlich ab.
ICM verhindert das Problem, statt es nachträglich zu komprimieren: Layered Context Loading lädt pro Schritt nur das Relevante. Ein typischer Durchlauf fokussiert 2.000 bis 8.000 statt 30.000+ Token. Die fünfstufige Hierarchie sortiert, was das Modell wann sieht:
So „sieht“ das Modell in jeder Phase nur, was es für die aktuelle Transformation braucht — dasselbe Prinzip, das KI-lesbare Dokumentation verfolgt, hier angewandt auf den Arbeitsprozess selbst.
Layer 0 CLAUDE.md Globale Identität & Workspace-Struktur
Layer 1 CONTEXT.md Task-Routing auf Workspace-Ebene
Layer 2 <phase>/CONTEXT.md Phasen-Kontrakt + Inputs Table (Routing)
Layer 3 _config/, references/ Fabrik: stabile Regeln, Markenstimme, Skills
Layer 4 <phase>/output/ Produkt: flüchtige Arbeitsartefakte pro LaufFactory vs. Product: das Edit-Source-Prinzip
ICM trennt strikt zwischen Konfiguration („The Factory“, Layer 3) und Ausführung („The Product“, Layer 4). Layer 3 enthält die stabilen Skill- und Regel-Dateien — Markenstimme, Design-System, Constraints; einmal konfiguriert, über alle Durchläufe stabil. Layer 4 enthält die flüchtigen Artefakte, die sich bei jedem Lauf ändern.
Daraus folgt das Edit-Source-Prinzip: Tritt ein Fehler wiederholt auf, korrigiert man nicht das Artefakt in Layer 4 (das wäre wie das Patchen einer Binärdatei), sondern die Quelle in Layer 3 — die „Fabrik“. Nur so werden Qualitätssteigerungen dauerhaft. Das Modell bekommt klare Signale, was Constraint und was zu transformierender Input ist.
Die Idee stabiler, wiederverwendbarer Regel-Dateien ist eng verwandt mit Agent Skills (skill.md): kanonisches Nutzungswissen statt Prosa, einmal definiert und überall referenziert.
Jeder Output ist eine Edit Surface
Weil jedes Zwischenergebnis eine schlichte Markdown-Datei ist, wird der gesamte Prozess zur transparenten Edit Surface — Observability by Default. An den Phasenübergängen sitzen Review Gates mit zwei Mechanismen: Checkpoints, an denen der Agent für menschliche Steuerung pausiert, und Audits, Qualitäts-Checklisten, die das Modell vor dem Schreiben gegen die Vorgaben aus Layer 3 prüft.
In der Praxis zeigt sich ein U-förmiges Interventionsmuster: Menschen steuern stark am Anfang (Richtung) und am Ende (Alignment), die mittleren Phasen laufen meist autonom. Ist ein Rechercheergebnis in Phase 1 falsch, korrigiert man einfach die Datei im Ordner, bevor Phase 2 startet — und die KI setzt nahtlos dort an, wo der Mensch aufgehört hat.
Das ist Human-in-the-loop in seiner direktesten Form: kein spezielles UI, kein Approval-Workflow im Code — nur Dateien, die man liest und ändert.
Demokratisierung: die neue Klasse der AI-Architects
Indem ICM technische Orchestrierung in die vertraute Sprache von Ordnern und Texten übersetzt, senkt es die Einstiegshürde radikal. Fachanwender ohne Programmierhintergrund werden zu AI-Architects: Durch das Verschieben von Dateien und Editieren von Markdown bauen sie Systeme, für die früher ein Entwicklerteam nötig war. Lokale Skripte übernehmen die mechanischen Teile, die gar keine KI brauchen — Daten holen, Dateien verschieben, Output formatieren.
Die methodische Strenge bleibt dabei erhalten — etwa über Multi-pass Compilation, bei der Information über mehrere Phasen schrittweise veredelt wird. Das Protokoll ist Open Source unter MIT-Lizenz und akademisch dokumentiert; die wissenschaftliche Fassung erschien auf arXiv und entstand unter anderem im Umfeld der University of Edinburgh.
Fazit: die Continuity Layer
ICM ist mehr als saubere Organisation — es ist eine Antwort auf das Problem der transienten Intelligenz. Ohne persistente Struktur bleibt KI „amnesisch“: Jede Sitzung beginnt bei null, Wissen verflüchtigt sich mit dem Kontextfenster.
Die Dateisystem-Struktur fungiert als physisches Skelett, an dem Wissen über Sitzungen hinweg haften bleibt — eine physicalized memory, die ein einzelnes Kontextfenster überdauert. Genau das macht ICM zur belastbaren Infrastruktur für Agenten, die nicht nur reagieren, sondern kontinuierlich arbeiten.
Die eigentliche Pointe: Wenn die stärkste KI-Architektur kein neuer Code-Stack ist, sondern die Art, wie wir Dateien benennen und anordnen — dann liegt der Hebel für echte Kontrolle nicht im nächsten Framework, sondern in der Struktur Ihrer Ordner.
