Anatomie einer Claw: 84 Hooks als Orchestrierungsschicht

Der erste Hook brauchte vier Minuten zum Schreiben. Er verhinderte, dass das Modell in einem reinen Anthropic-Workflow OpenAI-Produkte vorschlug. Zwei Monate später war aus diesem einzelnen Hook 84 geworden. Die 84 Hooks waren mit 43 Skills, 19 spezialisierten Agenten und 30 Bibliotheksmodulen verbunden. Irgendwann war die Sammlung keine Ansammlung von Skripten mehr, sondern eine Orchestrierungsschicht.

Ich habe das nicht so geplant. Niemand setzt sich hin und sagt: „Ich werde 15.000 Zeilen Agenteninfrastruktur bauen.” Sie lösen ein Problem. Dann ein weiteres. Dann lösen Sie das Problem der Interaktion zwischen den Problemen. Wenn Sie die Architektur bemerken, existiert sie bereits.

Andrej Karpathy bemerkte es ebenfalls. Im Februar 2026 beschrieb er „Claws” als eine neue Berechnungsschicht: Orchestrierung, Scheduling, Kontextverwaltung und Tool-Routing, aufgebaut auf LLM-Agenten – genauso wie Agenten auf LLMs aufgebaut sind.¹ Diese Einordnung kristallisierte etwas heraus, das Praktiker gebaut hatten, ohne es zu benennen. Dieser Beitrag ist die Anatomie eines solchen Systems: was es enthält, wie es gewachsen ist, wo es funktioniert und wo es scheitert.

TL;DR

Karpathys „Claws”-Schicht beschreibt Orchestrierungssysteme, die auf Agenten-CLIs aufgebaut sind. Ich habe eines organisch über zwei Monate auf Claude Code entwickelt: 84 Hooks über 15 Ereignistypen, 43 Skills, 19 Agenten und über 30 Bibliotheksmodule. Das System bildet sauber fünf Claws-Funktionen ab (Orchestrierung, Scheduling, Kontextverwaltung, Tool-Routing, Qualitätsdurchsetzung) mit einer bemerkenswerten Lücke (deklarative Workflow-Definitionen). Zentrale Erkenntnis: Die Trennung von Planung und Ausführung entstand als natürliche Eigenschaft der Hook-basierten Orchestrierung, nicht als Designziel. Lattners Beobachtung, dass „Urteilsvermögen und Abstraktion der Kern bleiben, während KI die Implementierung automatisiert”, bildet sich direkt auf die Hook-Architektur ab: Governance-Hooks üben Urteilsvermögen aus, Automatisierungs-Hooks führen die Implementierung durch.

Die Claws-Taxonomie

Karpathys Beschreibung identifiziert fünf Funktionen, die eine Claws-Schicht ausführt. Jede Funktion hat ein direktes Gegenstück im Hook-System, das ich in den letzten zwei Monaten auf Claude Code aufgebaut habe.¹

Die Taxonomie ist nützlich, weil sie Zuständigkeiten trennt, die Praktiker tendenziell verwoben aufbauen. Meine frühen Hooks vermischten Kontextverwaltung mit Qualitätsdurchsetzung. Der Kostenverfolgungs-Hook injizierte sowohl Budgetkontext (Kontextverwaltung) als auch blockierte teure Operationen (Qualitätsdurchsetzung). Die Trennung in separate Hooks verbesserte die Zuverlässigkeit, da jeder Hook unabhängig fehlschlagen konnte, ohne die andere Funktion zu beeinträchtigen.

Das Gesamtsystem

Die Zahlen vom Februar 2026:

Die Hook-Verteilung über Ereignistypen zeigt, wo sich die Orchestrierungskomplexität konzentriert:

UserPromptSubmit trägt das größte Gewicht, da es bei jeder Benutzernachricht ausgelöst wird. Der Dispatcher (prompt-dispatcher.sh) führt neun Hooks sequenziell bei jedem Prompt aus: Sicherheitsfilterung, Analysen, Nutzungsverfolgung, Systemüberwachung, Zielinjektion, Zeitschätzungsblockierung, Kontextinjektion, Gedächtnisthemeninjektion und Kontextdrucküberwachung.²

Jeder Hook fügt Latenz hinzu. Neun sequenzielle Hooks ergeben insgesamt gemessene 200 ms pro Prompt. Der Dispatcher führt sie sequenziell (nicht parallel) aus, weil gleichzeitige Hook-Schreibvorgänge in gemeinsam genutzte JSON-Zustandsdateien in frühen Tests zu Datenbeschädigung führten. Zwei Hooks, die gleichzeitig in jiro.state.json schrieben, erzeugten abgeschnittenes JSON, das jeden nachfolgenden Hook zum Absturz brachte. Sequenzielle Ausführung ist langsamer, aber sicher. Der Overhead von 200 ms ist für Benutzer unsichtbar, da die menschliche Tippgeschwindigkeit der Engpass ist, nicht die Hook-Latenz.

Wie es gewachsen ist

Das Wachstum war nicht linear. Es folgte einem Muster aus Problem-Lösung-Integrationszyklen.

Phase 1: Einzelzweck-Hooks (Woche 1–2). Jeder Hook löste ein Problem. enforce-opus-model.sh blockierte Nicht-Opus-Modellanfragen. no-time-estimates.sh entfernte Aufwandsschätzungen aus Antworten. filter-sensitive.sh fing Anmeldedaten in Tool-Aufrufen ab. Diese Hooks arbeiteten unabhängig. Kein Hook wusste von einem anderen Hook.

Phase 2: Koordinationsprobleme (Woche 3–4). Hooks begannen, sich gegenseitig zu stören. Der Anmeldedatenfilter blockierte legitime API-Aufrufe. Der Modelldurchsetzer kollidierte mit dem Spawnen von Subagenten. Die Lösung: Dispatcher. Ein einzelner Einstiegspunkt (prompt-dispatcher.sh) ersetzte sieben einzelne UserPromptSubmit-Hooks, kontrollierte die Ausführungsreihenfolge und teilte den Zustand über eine gecachte Stdin-Pipe.

Phase 3: Zusammengesetzte Fähigkeiten (Woche 5–8). Einzelne Hooks komponierten sich zu Systemen. Die Qualitätsschleife verband Pre-Tool-Hooks (Probleme abfangen, bevor sie auftreten) mit Post-Tool-Hooks (Ergebnisse verifizieren, nachdem sie aufgetreten sind) über eine gemeinsame Zustandsdatei (jiro.state.json). Das Deliberationssystem nutzte Rekursionsschutz, Spawn-Budgets und Konsensprotokolle, um mehrere Agenten ohne Endlosschleifen zu koordinieren. Ralph (die autonome Entwicklungsschleife) verband PRD-Dateien mit Claude-Spawning, Testverifizierung und Code-Review in einer einzigen orchestrierten Pipeline.

Phase 4: Selbstwahrnehmung (Woche 9+). Das System wurde groß genug, um Werkzeuge zum Verständnis seiner selbst zu benötigen. Semantische Suche über das Hook-System (/find-Skill) ermöglichte es Agenten, Hooks nach Zweck statt nach Dateinamen zu finden. Leistungsüberwachung (/perf-Skill) verfolgte, ob der Overhead des Systems selbst die Maschine verlangsamte. Ein Kontextdruckmonitor warnte, wenn der von der Orchestrierungsschicht injizierte Kontext zu viel des Kontextfensters des Modells verbrauchte.

Der Übergang von Einzelzweck-Hooks zu selbstüberwachender Infrastruktur spiegelt ein Muster wider, das Chris Lattner in seiner Rezension des Claude-C-Compiler-Projekts identifizierte: „Gute Software hängt von Urteilsvermögen, Kommunikation und klarer Abstraktion ab. KI hat dies verstärkt.”³ Die Architektur des Hook-Systems offenbart dieselbe Wahrheit. Die wertvollen Hooks sind nicht diejenigen, die Aufgaben automatisieren. Die wertvollen Hooks sind diejenigen, die Urteilsvermögen darüber kodieren, wann und wie Aufgaben automatisiert werden sollten.

Urteilsvermögen-Hooks vs. Automatisierungs-Hooks

Lattners Rezension des Claude-C-Compilers unterschied zwischen dem, was KI gut automatisiert (Implementierung), und dem, was grundlegend menschlich bleibt (Urteilsvermögen und Abstraktion).³ Diese Unterscheidung bildet sich direkt auf das Hook-System ab.

Urteilsvermögen-Hooks entscheiden, ob etwas geschehen soll. Sie kodieren Richtlinien, keine Abläufe.

Automatisierungs-Hooks führen vorbestimmte Aktionen aus. Sie kodieren Abläufe, keine Richtlinien.

Die Urteilsvermögen-Hooks sind schwieriger zu schreiben, schwieriger zu testen und wertvoller. quality-gate.sh erforderte sieben benannte Fehlermodi, sechs Nachweiskritierien und einen Erkenner für abschwächende Sprache. inject-context.sh erforderte fünf Zeilen Bash. Aber beide sind notwendig. Automatisierungs-Hooks liefern die Daten, die Urteilsvermögen-Hooks auswerten. sysmon-snapshot.sh (Automatisierung) speist Daten in den Leistungsmonitor, der entscheidet, ob eine Reduzierung der Agentenzahl empfohlen werden soll (Urteilsvermögen).

Das Verhältnis ist wichtig. In einer gesunden Orchestrierungsschicht sollten Urteilsvermögen-Hooks die Automatisierungs-Hooks zahlenmäßig übertreffen. Wenn die meisten Hooks nur Daten injizieren oder Metriken aufzeichnen, automatisiert das System gut, aber steuert schlecht. Eine verifizierte Zählung des aktuellen Systems: 35 Urteilsvermögen-Hooks, 44 Automatisierungs-Hooks, ungefähr 4:5. Automatisierung führt noch. Das Verhältnis begann bei ungefähr 1:6 (fast ausschließlich Injektions- und Protokollierungs-Hooks) und verschob sich über zwei Monate in Richtung Urteilsvermögen, als Governance-Beschränkungen hinzugefügt wurden, nachdem Ausfälle auftraten, die reine Automatisierung nicht verhindern konnte. Das Verhältnis hat noch keine Parität erreicht, was selbst ein nützliches Signal ist: Dieses System steuert immer noch weniger, als es automatisiert.

Trennung von Planung und Ausführung

Boris Tanes Beitrag „How I use Claude Code” erzielte 936 Punkte auf Hacker News, indem er ein Workflow-Muster beschrieb: Planung von Ausführung trennen.⁴ Mit einer Claude-Sitzung planen (recherchieren, skizzieren, entwerfen), dann mit einer frischen Sitzung ausführen, die den Plan als strukturierte Eingabe erhält. Das Muster fand Anklang, weil es ein reales Problem löst: Planung und Ausführung konkurrieren um Platz im Kontextfenster.

Das Hook-System gelangte über einen anderen Weg zur selben Trennung. Das Deliberationssystem startet spezialisierte Agenten, die Ansätze recherchieren und diskutieren. Das Ergebnis ist ein strukturiertes PRD (Product Requirements Document) mit Stories, Akzeptanzkriterien und Verifizierungstypen. Die Ralph-Schleife liest das PRD und startet frische Claude-Instanzen, um jede Story zu implementieren. Planungsagenten implementieren nie. Implementierungsagenten planen nie.

Diese Trennung war kein Designziel. Sie entstand aus zwei unabhängigen Beschränkungen:

1. Kontextfensterdruck. Planung erfordert das Lesen vieler Dateien und das Erkunden von Optionen. Implementierung erfordert fokussierten Kontext auf die aktuelle Aufgabe. Beides im selben Kontextfenster unterzubringen bedeutet, dass keines genügend Platz erhält. Separate Sitzungen geben jeder Phase vollen Kontext.

2. Unabhängigkeit der Qualitätsverifizierung. Wenn derselbe Agent plant und implementiert, kann er seine eigene Implementierung nicht objektiv gegen den Plan verifizieren. Ein frischer Agent mit nur dem Plan und dem Code bietet unabhängige Verifizierung. Die Ralph-Schleife erzwingt dies: Implementierungsagenten führen Tests durch, aber drei separate Review-Agenten (Korrektheit, Sicherheit, Konventionen) verifizieren die Ergebnisse.

Die Konvergenz zwischen Tanes manuellem Workflow und dem automatisierten Hook-System legt nahe, dass die Trennung von Planung und Ausführung eine natürliche Eigenschaft agentischer Systeme ist, nicht nur eine Praktikerpräferenz. Jedes System, das Kontextfenster verwaltet und Ausgaben verifiziert, wird letztendlich Planung von Ausführung trennen, weil die Alternative (beides in einem Kontext zu erledigen) in beiden Phasen schlechtere Ergebnisse liefert.

Wo das Hook-System versagt

Die Architektur hat drei signifikante Schwächen, die ein zweckgebaut entwickeltes Orchestrierungs-Framework beheben würde.

Keine deklarativen Workflow-Definitionen. Jeder Workflow ist imperativ in Bash-Skripten kodiert. Die Ralph-Schleife umfasst 1.320 Zeilen Bash, die eine spezifische Sequenz kodieren: PRD lesen, Story auswählen, Kontext sammeln, Claude starten, Tests ausführen, Reviews durchführen, Fehler behandeln, Zustand aktualisieren. Eine Änderung des Workflows erfordert die Bearbeitung von Bash. Ein deklaratives System würde Workflows als Daten (YAML, JSON) definieren, die ein Interpreter ausführt. Deklarative Workflows sind leichter zu ändern, zu komponieren und zu visualisieren. Imperative Skripte sind anfänglich leichter zu schreiben, aber schwieriger zu warten, wenn sie wachsen.

Hook-Reihenfolge ist fragil. Der Prompt-Dispatcher führt Hooks in einer fest kodierten Reihenfolge aus. Das Verschieben von memory-capsule-inject.sh vor inject-context.sh würde die Kapselinjektion beschädigen, da sie von der Sitzungs-ID abhängt, die inject-context.sh auflöst. Diese Abhängigkeiten sind implizit (in der Reihenfolge des Dispatchers kodiert) statt explizit (als Abhängigkeiten zwischen Hooks deklariert). Ein zweckgebaut entwickeltes System würde Hook-Abhängigkeiten als DAG ausdrücken und die Ausführungsreihenfolge topologisch sortieren.

Keine Workflow-Visualisierung. Mit 84 Hooks erfordert das Verständnis des vollständigen Ausführungspfads jeder Benutzeraktion das Lesen von Dispatcher-Code und manuelles Verfolgen von Hook-Ketten. Es gibt kein Werkzeug, das zeigt: „Wenn der Benutzer eine Nachricht eingibt, werden diese 9 Hooks in dieser Reihenfolge ausgelöst, und Hook 3 ruft Bibliotheksfunktion X auf, die in Zustandsdatei Y schreibt.” Das System ist über Protokolle beobachtbar, aber nicht über seine Struktur. Ein zweckgebaut entwickeltes Orchestrierungs-Framework würde einen visuellen Graphen von Hook-Abhängigkeiten, Datenflüssen und Ausführungspfaden bereitstellen.

Diese Schwächen teilen eine gemeinsame Ursache: Das System wuchs organisch aus der Lösung einzelner Probleme, anstatt als kohärente Orchestrierungsschicht entworfen zu werden. Organisches Wachstum erzeugt Systeme, die funktionieren (alle 84 Hooks arbeiten korrekt in der Produktion), aber als Ganzes schwer nachzuvollziehen sind. Der Kompromiss ist real: Die Orchestrierungsschicht von vornherein zu entwerfen hätte eine bessere Struktur, aber schlechtere Fähigkeiten hervorgebracht, da viele Fähigkeiten (Gedächtniskapseln, Ausgabe-Whitelists, Spawn-Budgets) als Reaktion auf Ausfälle erfunden wurden, die vor ihrem Auftreten nicht vorhersehbar waren.

Was Praktiker mitnehmen sollten

Wenn Sie eine Orchestrierungsschicht auf einem Agenten-CLI aufbauen, lassen sich drei Muster aus diesem System direkt übertragen.

Beginnen Sie mit Dispatchern, nicht mit einzelnen Hooks. Die größte architektonische Verbesserung war der Ersatz von sieben einzelnen UserPromptSubmit-Hooks durch einen einzigen Dispatcher, der sie sequenziell ausführt. Wenn Sie mehr als drei Hooks für einen Ereignistyp erwarten, bauen Sie zuerst den Dispatcher. Die 30 Minuten für das Schreiben eines Dispatchers ersparen Stunden beim Debuggen von Hook-Interaktionsfehlern. Das minimale Muster:

#!/bin/bash
# dispatcher.sh — sequential hook execution with shared stdin
HANDLERS=("inject-context.sh" "track-usage.sh" "quality-gate.sh")
HOOK_DIR="$(dirname "$0")/handlers"
INPUT=$(cat)  # Cache stdin once (each handler gets the same input)

for handler in "${HANDLERS[@]}"; do
    [ -x "$HOOK_DIR/$handler" ] && echo "$INPUT" | "$HOOK_DIR/$handler"
done

Registrieren Sie diesen einzelnen Dispatcher als Ihren Hook-Einstiegspunkt. Fügen Sie Handler zum Array hinzu, wenn Sie sie entwickeln. Jeder Handler liest dasselbe gecachte Stdin (die Hook-Ereignisnutzlast) und schreibt unabhängig auf Stdout.

Trennen Sie Urteilsvermögen von Automatisierung frühzeitig. Wenn Sie einen neuen Hook schreiben, fragen Sie sich: „Entscheidet dieser Hook, ob etwas geschehen soll, oder führt er eine vorbestimmte Aktion aus?” Urteilsvermögen-Hooks benötigen mehr Tests, mehr Behandlung von Grenzfällen und mehr Iteration. Automatisierungs-Hooks benötigen Zuverlässigkeit und Leistung. Beide gleich zu behandeln führt zu unzureichend getesteten Urteilsvermögen-Hooks und überentwickelten Automatisierungs-Hooks.

Lassen Sie die Trennung von Planung und Ausführung natürlich entstehen. Erzwingen Sie die Trennung nicht am ersten Tag. Bauen Sie das Einfachste, das funktioniert. Wenn Sie bemerken, dass das Kontextfenster Ihres Agenten für sowohl Planung als auch Implementierung zu voll ist, trennen Sie sie. Wenn Sie bemerken, dass Ihr Agent seine eigene Arbeit nicht objektiv verifizieren kann, fügen Sie unabhängige Review-Agenten hinzu. Die Trennung wird sich als offensichtlich anfühlen, wenn die Beschränkungen sie erfordern.

Der Hook-basierte Ansatz hat einen Vorteil gegenüber zweckgebaut entwickelten Orchestrierungs-Frameworks: keine Bindung. Jeder Hook ist unabhängig. Sie können einen Hook, zehn Hooks oder vierundachtzig Hooks einsetzen. Sie können jeden Hook löschen, ohne andere zu beschädigen (vorausgesetzt, Sie pflegen den Dispatcher). Es gibt kein Framework zum Lernen, keine Abhängigkeit zum Verwalten, keine Laufzeitumgebung zum Betreiben. Die Orchestrierungsschicht besteht nur aus Dateien.

Karpathy nannte es eine neue Berechnungsschicht. Die Implementierung ist älter als der Name. Praktiker bauen Claws, seit sie zum ersten Mal ein Shell-Skript geschrieben haben, um einen Agenten-CLI-Aufruf zu umhüllen. Der Unterschied zwischen einem Shell-Skript und einer Orchestrierungsschicht ist kein Unterschied in der Art. Es ist ein Unterschied darin, wie viele Probleme Sie gelöst haben und wie viele dieser Lösungen sich gegenseitig lösen mussten.

Quellen