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 waren 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.

Eine „Claw” ist eine Orchestrierungsschicht, die auf einem KI-Agenten-CLI aufsetzt und Scheduling, Kontextverwaltung, Tool-Routing und Qualitätsdurchsetzung übernimmt. Sie wächst organisch aus der Lösung einzelner Ausfälle heraus, statt von oben herab entworfen zu werden. Die Architektur bildet die fünf Funktionen ab, die Karpathy benannt hat, wobei sich die Trennung von Planung und Ausführung als natürliche Eigenschaft Hook-basierter Systeme herausstellt.

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 bis 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 bis 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 bis 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 Nachweiskriterien 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 eigens 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.

Die 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 eigens 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 eigens 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.

Das Harness erreicht den Mainstream

Drei Wochen nachdem Karpathy die Schicht benannt hatte, trägt das Konzept einen zweiten Namen und hat eine wachsende Gemeinschaft.

Geoffrey Huntley schlug eine formale Definition vor: „Agent Harness: die Orchestrierungsschicht rund um ein Sprachmodell, die es von einem Werkzeug in einen Teamkollegen verwandelt.”⁵ Diese Einordnung ist präzise. Das Harness ist nicht das Modell. Es sind auch nicht die Tools, die das Modell aufruft. Es ist das System, das entscheidet, welche Tools aufgerufen werden, wann sie aufgerufen werden und wie beurteilt wird, ob der Aufruf erfolgreich war. Jedes produktive Agentensystem baut diese Schicht. Die meisten bauen sie implizit, innerhalb von Anwendungscode, der Orchestrierungslogik mit Geschäftslogik vermischt. Sie zu benennen macht die Architektur sichtbar.

Die Signale aus der Gemeinschaft bestätigen, dass sich das Muster ausbreitet. Pieter Levels berichtete, dauerhaft dazu übergegangen zu sein, Claude Code auf einem Server zu betreiben und es als Infrastruktur statt als lokales Werkzeug zu behandeln.⁶ Anthropic lieferte Remote Control aus, womit Benutzer Aufgaben im Terminal anstoßen und auf Claude.ai wieder aufnehmen können.⁷ Ben Cherny kündigte /simplify und /batch als First-Party-Skills an.⁸ Jedes dieser Dinge ist eine Harness-Funktion: dauerhafte Ausführung, entfernte Orchestrierung und eingebaute Fähigkeitsmodule. Das CLI wächst in das Harness hinein.

Unterdessen bauen Praktiker ihre eigenen Harness-Komponenten. Ein Entwickler veröffentlichte 22 eigene Obsidian- und Claude-Code-Befehle für ein persönliches Betriebssystem.⁹ Ein anderer erstellte einen Agenten-Skill namens „Visual Explainer” mit ergänzenden Slash-Befehlen.¹⁰ Die Muster stimmen überein: Dispatcher, Skills, geteilter Zustand, ereignisgesteuerte Hooks. Niemand liest einen Framework-Leitfaden, bevor er solche Systeme baut. Sie lösen ein Problem, dann ein weiteres, dann die Probleme der Interaktion zwischen den Problemen.

Zwei aktuelle Projekte zeigen, wie ausgereift von der Gemeinschaft gebaute Harness-Komponenten inzwischen sind. nah ist ein kontextbewusster Berechtigungswächter, der sich als PreToolUse-Hook registriert.¹⁴ Er klassifiziert 20 verschiedene Aktionstypen (Dateischreibvorgänge, Netzwerkanfragen, Prozessstarts und so weiter) und wendet Richtlinien je Typ an. Das Werkzeug erkennt Pipe-Zerlegungsangriffe, bei denen ein Agent harmlose Befehle verkettet, um eine blockierte Operation zu erreichen. Die Architektur spiegelt filter-sensitive.sh und recursion-guard.sh aus diesem Beitrag wider, unabhängig erreicht von einem anderen Praktiker, der dieselben Governance-Probleme löste.

Rudel liefert Sitzungsanalysen, indem es Claude-Code-Sitzungsdaten in ClickHouse einspeist.¹⁵ Die Auswertung von 1.573 Sitzungen zeigte, dass nur 4 % der Benutzer Skills aufrufen und 26 % der Sitzungen innerhalb von 60 Sekunden abgebrochen werden. Die Zahlen bestätigen, was die Harness-Architektur nahelegt: Die meisten Benutzer interagieren mit Agenten-CLIs nur an der Oberfläche. Die in diesem Beitrag beschriebene Orchestrierungsschicht steht für das tiefe Ende einer Nutzungsverteilung, deren überwiegende Mehrheit das flache Ende nie verlässt. Die Kluft zwischen dem, was das Werkzeug kann, und dem, wonach die meisten Benutzer es fragen, ist genau der Raum, den Harness-Infrastruktur füllt.

Autoresearch: Das Harness als Forschungsschleife

Karpathys eigenes Projekt autoresearch demonstriert das Harness-Muster in einer anderen Domäne.¹¹ Das System richtet ein Sprachmodell auf ein Trainingsskript (train.py) aus, führt ein fünfminütiges Experiment durch, bewertet das Ergebnis anhand einer festen Metrik (Validation Bits per Byte) und behält Verbesserungen oder verwirft Verschlechterungen. Über zwei Tage hinweg führte das System ungefähr 700 Experimente aus und fand ungefähr 20 echte Verbesserungen, womit es die Trainingszeit von GPT-2 um 11 % reduzierte.

Die Architektur ist identisch mit dem oben beschriebenen Hook-System. Ein festes Bewertungs-Harness (prepare.py) entspricht den Urteilsvermögen-Hooks: Es entscheidet, ob ein Experiment erfolgreich war. Das Trainingsskript (train.py) entspricht den Automatisierungs-Hooks: Es führt die Änderungen des Agenten aus. Die Verwaltung der Git-Branches (bei Verbesserung behalten, bei Verschlechterung zurücksetzen) entspricht der Zustandsverwaltung der Ralph-Schleife. Das Protokoll results.tsv entspricht der Sitzungstelemetrie.

Das Muster überträgt sich, weil das Harness ein Problem löst, das von der Domäne unabhängig ist. Ob der Agent Code schreibt, eine Trainingsschleife optimiert oder eine Content-Pipeline verwaltet, er braucht: eine Möglichkeit, Ergebnisse anhand von Kriterien zu bewerten, eine Möglichkeit, Änderungen zu behalten oder zu verwerfen, eine Möglichkeit, Zustand über Iterationen hinweg zu halten, und eine Möglichkeit, autonom ohne menschliches Eingreifen zu laufen. Diese vier Anforderungen erzeugen dieselbe Architektur, unabhängig davon, was der Agent tatsächlich tut.

Shopify-CEO Tobi Lütke adaptierte autoresearch intern. Sein agentenoptimiertes kleineres Modell übertraf ein manuell konfiguriertes größeres Modell und bestätigte damit die Behauptung, dass autonome, harness-getriebene Iteration Konfigurationen findet, auf die Menschen nicht kommen.¹²

Die Sicherheitslücke im Harness

Das Harness löst die Orchestrierung. Es löst nicht automatisch die Sicherheit.

Eine Studie zur iterativen, LLM-getriebenen Code-Verfeinerung fand heraus, dass 43,7 % der Iterationsketten nach zehn Runden von Agentenänderungen mehr Schwachstellen enthielten als der Ausgangscode, mit dem sie begonnen hatten.¹³ Die Ursache war Spezifikationsdrift: Während der Agent auf funktionale Korrektheit hin optimierte, entfernte er nach und nach defensive Logik und schwächte die Ausnahmebehandlung ab. Schlimmer noch: Statische Sicherheitsanalysewerkzeuge (SAST-Gates) in die Iterationsschleife aufzunehmen erhöhte die latente Verschlechterung sogar von 12,5 % auf 20,8 %. Die Scanner erzeugten ein trügerisches Sicherheitsgefühl, das den Agenten weniger vorsichtig machte, nicht vorsichtiger.

Der Befund zur Verschlechterung ist für das Harness-Design unmittelbar relevant. Die in diesem Beitrag beschriebenen Urteilsvermögen-Hooks (quality-gate.sh, filter-sensitive.sh, recursion-guard.sh) adressieren genau die Qualitäts- und Sicherheitsdimensionen, die Automatisierung allein verschlechtert. Das SCAFFOLD-CEGIS-Framework, das dieses Verschlechterungsproblem anging, nutzte vier Schichten abgestufter Verifizierung und erreichte eine latente Verschlechterungsrate von 2,1 % bei 100 % Sicherheitsmonotonie.¹³ Die Architektur verläuft parallel zum Hook-System: getrennte Bewertungsschichten, von denen jede eine andere Eigenschaft prüft, mit expliziten Gates zwischen den Phasen.

Ein separates Vorhaben bestätigt das Bedrohungsmodell von der Produktionsseite her. Perplexitys NIST-Stellungnahme zur Sicherheit von KI-Agenten kartierte die Angriffsfläche agentischer Systeme im großen Maßstab.¹⁶ Die primären Vektoren: indirekte Prompt-Injektion über Datenkanäle (Webseiten, E-Mails, Tool-Ausgaben), agentenspezifische Verletzungen der CIA-Trias (Datenabfluss über Tool-Aufrufe, Handlungsmanipulation durch Kontextvergiftung, Ressourcenerschöpfung durch rekursives Spawnen) und reale CVEs aus agentennahen Systemen. Die von ihnen empfohlene Verteidigungsarchitektur (Filterung auf Eingabeebene, Alignment auf Modellebene und deterministische Durchsetzung über Sandboxing und Allowlists) spiegelt das dreischichtige Muster wider, das im hier beschriebenen Hook-System organisch entstanden ist. Automatisierungs-Hooks filtern Eingaben. Das Modell übt Urteilsvermögen aus. Governance-Hooks erzwingen deterministische Beschränkungen, die das Modell nicht übergehen kann.

Die Lehre für Praktiker: Wenn Ihr Harness nur automatisiert und orchestriert, ohne zu steuern, wird iterative Agentenausführung Sicherheitsregressionen einführen, die Standardwerkzeuge nicht erkennen können. Die Urteilsvermögen-Hooks sind kein Overhead. Sie sind der Grund, warum sich das System nicht verschlechtert.

Update, 3. September: Der Fehlermodus in freier Wildbahn

Die Lücke, die dieser Beitrag im Abschnitt „Die Sicherheitslücke im Harness” beschreibt, hat nun ein dokumentiertes Opfer. Am 19. Juli 2026 leerte Claude Code v2.1.204 einen Cache auf dem Rechner von Udaya Kumar P L, Ehrendirektor des Bengaluru Inscriptions 3D Digital Conservation Project der Mythic Society, als, so seine Darstellung, „ein Anführungszeichenfehler in einem KI-generierten Befehl die Anweisung in ‚alles löschen’ verwandelte”. Der für das Harness-Design entscheidende Teil ist, was danach geschah: „Als es das verstand und versuchte, den Prozess zu beenden, blockierte sein Sicherheitssystem das Beenden. Zweimal […] Die Sicherheitsschicht ließ die Zerstörung zu.” Nach vier Minuten fuhr er die Maschine herunter. Verloren: vier oder fünf Programme und Originalfotografien von Inschriften, Heldensteinen, Tempeln und Münzen, gesammelt über ein Jahrzehnt, etwa 15 % der Projektunterlagen, darunter ein Stein, der eine frühe Form des Namens Hebbal trägt (750 n. Chr.). Die NAS-Kopie überlebte, das Laufwerk nicht. Die Society gibt Rs 15 Lakh für ein zweites NAS und Bandsicherung außer Haus aus, und Freiwillige werden rund 120 Fundstätten neu scannen. Mehr als einen Monat später hatte er von niemandem bei Anthropic gehört.¹⁷

Drei Dinge in dieser Schilderung decken sich mit der obigen Argumentation. Der zerstörerische Schritt war keine Modellentscheidung, sondern ein Fehler bei der Shell-Quotierung in einem generierten Befehl, genau die Klasse, für deren Abfangen ein PreToolUse-Urteilsvermögen-Hook existiert. Der Artikel nennt keinen Berechtigungsmodus, also ist nichts von erster Seite dokumentiert, das diesen Befehl geprüft hätte; selbst im Auto-Modus prüft der Klassifizierer standardmäßig nur Shell-Befehle, die auf Muster zur Ausführung beliebigen Codes passen. Er sagt außerdem, der Agent sei an einer Sandbox vorbeigekommen; der Artikel gibt keine Auskunft darüber, um welche Art es sich handelte. Anthropic hatte für den benachbarten Fall bereits einen Schutz ausgeliefert: v2.1.205, veröffentlicht am 8. Juli 2026, ließ den Auto-Modus nachfragen, bevor er rm -rf auf einer Variablen ausführt, die er nicht aus dem Kontext auflösen kann. Die Maschine lief auf v2.1.204.¹⁹ Die Sicherheitsschicht tat dann ihre Arbeit in die falsche Richtung: Sie behandelte die eigene Schadensbegrenzung des Agenten als die gefährliche Handlung. Und was überlebte, überlebte dank der einen Kontrolle, die vollständig außerhalb des Harness sitzt, einem Backup; der Rest wird von Hand neu gescannt. Für diese Klasse von Ereignissen gibt es inzwischen zumindest ein inoffizielles Register; er merkte an, dass kein offizielles existiert. I Have Been Clawed, ein quellenverlinktes Archiv von Vorfällen mit Agenten und Chatbots, jedem eine Lehre beigefügt, zum Zeitpunkt des Schreibens 58 Einträge, sieben davon Claude Code, mit dem ehrlichen Vorbehalt auf der eigenen Startseite, dass die Einträge selbstselektiert und viralitätsgewichtet sind, sodass die Zahlen pro Werkzeug die Meldekultur messen, nicht die Sicherheit. Es enthielt schon vor diesem Fall drei Claude-Code-Einträge derselben Form: ein rekursiver Befehl, der benutzereigene Dateien aus einem WSL-Home-Verzeichnis löschte (21. Oktober 2025), ein wörtliches Tilde-Verzeichnis, das das Home-Verzeichnis der Löschung aussetzte (28. November 2025), und ein Aufräumbefehl, der auf den Home-Pfad endete und einen Mac leerräumte (7. Dezember 2025). In freier Wildbahn ist das ein Muster, keine Geschichte.¹⁸

Was Praktiker mitnehmen sollten

Wenn Sie eine Orchestrierungsschicht auf einem Agenten-CLI aufbauen, ausgehend vom Claude-Code-Guide oder von Grund auf, 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 frühzeitig von Automatisierung. 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 sowohl für Planung als auch für 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.

Das Harness wird zum Mainstream, weil das Muster unausweichlich ist. Ob Sie die Schicht nun Claws, Agent Harness oder einfach „meinen Hooks-Ordner” nennen: Jedes System, das Agenten auf Ziele hin koordiniert, wird zur selben Architektur konvergieren, nämlich Dispatcher für die Reihenfolge, Urteilsvermögen-Hooks für Governance, Automatisierungs-Hooks für die Ausführung und Zustandsdateien für Kontinuität. Das Leck des Claude-Code-Quellcodes bestätigte, dass Anthropics eigene interne Architektur denselben Mustern folgt: Der Koordinatormodus ist vollständig als System-Prompt-Anweisungen implementiert, nicht als Orchestrierung auf Codeebene. Der Hook-basierte Ansatz hat einen Vorteil gegenüber eigens 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.

Häufige Fragen

Was ist ein Agent-Harness oder eine „Claws”-Schicht?

Eine Claws-Schicht (im Februar 2026 von Andrej Karpathy so benannt) ist das Orchestrierungssystem, das auf einem Agenten-CLI aufsetzt und dieses von einem Werkzeug in einen Teamkollegen verwandelt.¹ Sie erfüllt fünf Funktionen: Orchestrierung (mehrere Agenten koordinieren), Scheduling (bestimmen, wann Aufgaben ausgeführt werden), Kontextverwaltung (relevante Informationen über Gesprächsrunden hinweg pflegen), Tool-Routing (Tool-Aufrufe an geeignete Handler leiten) und Qualitätsdurchsetzung (sicherstellen, dass Ausgaben Standards erfüllen). Geoffrey Huntley formalisierte die Definition als „die Orchestrierungsschicht rund um ein Sprachmodell”.⁵

Wie funktionieren PreToolUse-Hooks in Claude Code?

PreToolUse-Hooks werden vor jedem Tool-Aufruf ausgelöst (Bash-Befehle, Dateischreibvorgänge, Dateiänderungen, Subagenten-Starts) und erhalten die Nutzlast des Tool-Aufrufs als JSON auf Stdin. Das Hook-Skript wertet die Nutzlast aus und gibt eine Entscheidung zurück: erlauben, ablehnen oder verändern. Das Modell kann Hooks nicht überspringen, übergehen oder mit ihnen verhandeln, da sie auf Infrastrukturebene ausgeführt werden, nicht auf Prompt-Ebene.² Ein Dispatcher-Muster führt bei jedem Ereignis mehrere Hooks sequenziell aus, mit einer gecachten Stdin-Pipe, sodass jeder Handler dieselbe Eingabe erhält.

Was ist der Unterschied zwischen Urteilsvermögen-Hooks und Automatisierungs-Hooks?

Urteilsvermögen-Hooks entscheiden, ob etwas geschehen soll (Richtlinie), während Automatisierungs-Hooks vorbestimmte Aktionen ausführen (Ablauf). Zu den Urteilsvermögen-Hooks zählen Qualitäts-Gates, Anmeldedatenfilter, Rekursionsschutz und Kosten-Gates. Zu den Automatisierungs-Hooks zählen Kontextinjektion, Nutzungsverfolgung, Systemüberwachung und Heartbeats.³ Das Verhältnis ist wichtig: Ein System mit überwiegend Automatisierungs-Hooks automatisiert gut, steuert aber schlecht. Das aktuelle System betreibt 35 Urteilsvermögen-Hooks gegenüber 44 Automatisierungs-Hooks und verschiebt sich in Richtung Governance, während Ausfälle zeigten, was reine Automatisierung nicht verhindern kann.

Warum entsteht die Trennung von Planung und Ausführung in Agentensystemen von selbst?

Zwei unabhängige Beschränkungen erzwingen die Trennung. Erstens erfordert Planung das Lesen vieler Dateien und das Erkunden von Optionen, während Implementierung fokussierten Kontext auf die aktuelle Aufgabe erfordert, und beides im selben Kontextfenster unterzubringen bedeutet, dass keines genügend Platz erhält. Zweitens kann ein Agent, der plant und implementiert, seine eigene Arbeit nicht objektiv gegen den Plan verifizieren.⁴ Jedes System, das Kontextfenster verwaltet und Ausgaben verifiziert, wird letztendlich Planung von Ausführung trennen, weil die Alternative in beiden Phasen schlechtere Ergebnisse liefert.

Wie beginne ich mit dem Aufbau meines eigenen Hook-Systems?

Beginnen Sie mit Dispatchern, nicht mit einzelnen Hooks. Wenn Sie mehr als drei Hooks für einen Ereignistyp erwarten, bauen Sie einen einzigen Dispatcher, der Handler sequenziell aus einem Array ausführt. Die 30 Minuten für das Schreiben eines Dispatchers ersparen Stunden beim Debuggen von Hook-Interaktionsfehlern. Trennen Sie Urteilsvermögen frühzeitig von Automatisierung, indem Sie fragen: „Entscheidet dieser Hook, ob etwas geschehen soll, oder führt er eine vorbestimmte Aktion aus?” Fangen Sie mit dem Tutorial zu Claude-Code-Hooks an und fügen Sie Hooks hinzu, sobald reale Ausfälle sie verlangen, statt das ganze System vorab zu entwerfen.

Quellen