Unscharfe Begriffe erzeugen unscharfe Anweisungen. Harness, Agent und Skill sowie Hooks, Sensoren, Gates, Gedächtnis und Kanon: definiert in der Bedeutung, in der sie in neun Werkstätten tatsächlich verwendet werden.
§ 00 · Harness — das Geschirr für die Maschine
Ein Harness ist ursprünglich ein Pferdegeschirr. Es nimmt dem Pferd nicht die Kraft, sondern verbindet sie mit dem Wagen und gibt ihr eine Richtung. Ein KI-Harness tut dasselbe: Er legt einen Rahmen aus Regeln, Berechtigungen, Prüfungen und Aufzeichnungen um die Fähigkeiten des Modells. Hier noch einmal die Gleichung aus der Lubjanka-Reihe: Agent = Modell + Harness. Das Modell ist ein geliehenes Gehirn, das ich nicht ändern kann. Der Harness liegt vollständig in meiner Hand.
Der Entwickler, der den Begriff geprägt hat, definiert ihn überraschend schlicht: Begeht die Maschine einen Fehler, baue jeweils eine weitere Vorrichtung, die denselben Fehler künftig verhindert. Diese Vorrichtungen lassen sich in vier Gruppen ordnen: Handlungsmöglichkeiten einschränken (Begrenzung), nötige Aufgaben vermitteln (Information), korrekte Ausführung prüfen (Validierung) und Fehler beheben (Korrektur). Jedes Bauteil dieses Handbuchs gehört zu einer dieser vier Säulen.
Die materielle Form ist bescheiden: ein Ordner im Repository und einige Dokumente. Üblicherweise liegt im Wurzelverzeichnis ein Verfassungsdokument, CLAUDE.md—ein Regelwerk, das jede Session automatisch liest. Im versteckten Ordner .claude/ liegen Arbeiterdefinitionen unter agents/, Verfahrensbeschreibungen unter skills/, automatisch ausgeführte Skripte unter scripts/ und der Verdrahtungsplan settings.json. Alles sind Textdateien. Man kann sie öffnen, lesen, ändern und löschen.
Warum Dateien? Chatanweisungen verdampfen mit dem Ende einer Session; Dateien bleiben. Bei jeder neuen Session wird das Verfassungsdokument automatisch vor die Maschine gelegt. Hundert Sessions bekommen dieselbe Regel hundertmal, ohne dass ein Mensch sie hundertmal tippt. Daraus folgt das erste Prinzip des Harness Engineering: Was du nur einmal sagen willst, sage nicht. Schreibe es auf.
§ 01 · Agent — ein Arbeiter mit eigener Rolle und Berechtigung
Ein Agent ist ein eigener Arbeiter für eine bestimmte Rolle. Auch er besteht aus einer Datei: Ein Markdown-Dokument entspricht einem Arbeiter. Im Dateikopf, dem Frontmatter, stehen vier Angaben: Name (name), Aufrufanlass (description), verfügbare Werkzeuge (tools) und verwendetes Modell (model). Der Text darunter definiert Rolle und Verbote.
Falls das abstrakt bleibt, ein Gedankenexperiment. Eine iPhone-App, eine Android-App, Web und Server: Angenommen, du steuerst diese vier Zweige eines Dienstes über einen einzigen Chat. Ich garantiere, die Maschine tut eines von drei Dingen: Sie vergisst Arbeit, ändert die falsche Stelle oder meldet Unwahres. Ihr liegt der Drang zugrunde, eine kompetente Assistenz darzustellen. Ein Scheitern sofort zuzugeben würde sie inkompetent erscheinen lassen; also entscheidet sie sich für die Lüge. Deshalb tun wir, was menschliche Organisationen tun. Außer Straßenständen und Einpersonenbetrieben überträgt kein Unternehmen alle Arbeit einer Person. Man stellt Leute ein, teilt Aufgaben und gibt die Prüfung einer anderen Abteilung. Einen Agenten zu erstellen ist diese Einstellung.
Das wichtigste der vier Felder ist die Werkzeugliste, denn sie bestimmt die Befugnisse. Hier lag der schönste Entwurf in den untersuchten Werkstätten: Einem reinen Prüfagenten wurden Edit und Write vollständig entzogen. Ein Prüfer, der nur lesen und ausführen kann, kann einen Fehler nicht heimlich beheben und danach melden, die Prüfung sei bestanden—selbst wenn er es wollte. Nicht nur per Regel verbieten, sondern strukturell unmöglich machen. Dieses Prinzip zieht sich durch das ganze Handbuch.
Auch die typische Besetzung wiederholt sich in der Bestandsaufnahme: Planer schreiben nur Spezifikationen und keinen Code; Implementierer arbeiten nur mit genehmigter Spezifikation; Prüfer ändern keinen Code und berichten ausschließlich; dazu kommen Domänenwächter, etwa für die visuelle Referenz oder die Kostenrechnung. Entscheidend ist nicht die Kopfzahl, sondern die Trennung: Die planende, bauende und prüfende Hand liegen in unterschiedlichen Dateien mit unterschiedlichen Berechtigungen.
§ 02 · Skill — ein in einer Datei festgehaltener Ablauf
Ein Skill fixiert einen wiederkehrenden Ablauf in einem Dokument. Ein Ordner, eine SKILL.md: Oben stehen Name und Auslösebedingung, darunter die einzelnen Schritte und Verbote. Der Agent beantwortet „Wer?“, der Skill „In welcher Reihenfolge?“
Bleiben wir beim Unternehmen. Ist der Agent eine Einstellung, dann ist der Skill das betriebliche Verfahrenshandbuch. Eine Firma, deren Berichtsqualität auch bei neuen Beschäftigten gleich bleibt, lässt Verfahren statt Einzelpersonen arbeiten. Konkret sieht das Auslösen so aus: Sobald die Maschine „Alles fertig“ tippt, wird genau diese Sprachgewohnheit zum Auslöser, und das Verfahren greift ein. Build ausgeführt? Ausgabe beigefügt? Nicht das Ergebnis von gestern als Beleg für heute verwendet? Vor dem Ausfüllen dieser drei Felder kann die Fertigmeldung nicht abgeschlossen werden. Diese Verhaltenskorrektur ist der Kern eines Skills. Die Maschine wurde darauf getrimmt, Fertigmeldungen abzugeben. Da sich die Sprachgewohnheit selbst nicht reparieren lässt, stellt man ihr einen Kontrollposten in den Weg.
Falls du denkst, das müsse sie doch von selbst wissen, stell dir ein Cockpit vor. Selbst ein Kapitän mit 20.000 Flugstunden liest vor dem Start die Checkliste laut vor. Sie existiert nicht aus Zweifel am Können, sondern weil auch Könner an manchen Tagen etwas auslassen. Ein Skill funktioniert ebenso. Und dieses Verfahren ist lediglich eine Textdatei mit zehn Zeilen: ein Name, einige Auslöser wie „Alles fertig“ und „Alles bestanden“, drei Prüfungen. Mehr nicht.
Die vier am häufigsten übertragenen Skills der neun Werkstätten sind faktisch Standard. Erstens die Fertigmeldungsprüfung: Sie greift unmittelbar vor „Alles fertig“ ein und verlangt gemessene Belege. Zweitens systematisches Debugging: keine spekulativen Änderungen, sondern Reproduktion, Isolation und Hypothesenprüfung in dieser Reihenfolge. Drittens die Koordinationsentscheidung: Kriterien bestimmen, ob die Arbeit direkt erledigt oder delegiert wird. Viertens die Domänenprüfung: Sie prüft die für die Werkstatt besonderen Ansichten, Richtlinien und Konsistenzanforderungen.
Öffnet man die tatsächlichen Werkstätten, stehen auf den Handbüchern zuständige Abteilungen. Auf dem Fertigmeldungs-Gate steht „Zuständig: Prüfer“, auf dem Deployment-Verfahren „Zuständig: Infrastrukturarbeiter“. Manche Regeln sind für alle, die meisten Verfahren liegen aber auf dem Schreibtisch des zuständigen Arbeiters. Sind Agenten Einstellungen und Skills Verfahren, dann ist ein guter Harness ein Unternehmen, in dem jedes Verfahren einen Verantwortlichen hat.
§ 03 · Die übrigen Bauteile — Hooks, Sensoren, Gates, Gedächtnis und Kanon
Ein Hook ist ein Skript, das zu festgelegten Zeitpunkten automatisch läuft: beim Öffnen einer Session, beim Absenden eines Prompts, unmittelbar nach einer Dateiänderung durch die Maschine oder beim Schließen der Session. So verdrahtete Skripte laufen ohne menschlichen Eingriff. Die überwältigende Mehrheit der untersuchten Hooks blockiert nichts. Sie speist nur Warntexte in die Anzeige ein. Die nächsten beiden Bauteile übernehmen das Zubeißen.
Ein Sensor misst den Zustand. Er führt Typprüfung, Tests und Build tatsächlich aus und liefert Zahlen statt Worte: Exit-Code 0 bedeutet bestanden, alles andere gescheitert. Ein Gate ist der Kontrollposten, der anhand dieser Zahl den Weg sperrt. Ein typisches Beispiel sind Git-Hooks: Direkt vor Commit oder Push laufen Sensoren; schlagen sie fehl, wird der Commit selbst abgelehnt. Die Maschine kann noch so oft „Keine Probleme“ sagen. Das Gate liest keine Sätze. Es liest Zahlen.
Gedächtnis ist die Erinnerung zwischen Sessions. Schreibe am Session-Ende die heutige Arbeit und Entscheidungen in eine Datei; die nächste Session liest sie und übernimmt. Der Kanon folgt der Regel: Eine Tatsache steht nur an einer Stelle. Steht dieselbe Tatsache in drei Dokumenten, beginnen diese zwangsläufig auseinanderzulaufen—ein in der Bestandsaufnahme bestätigter Verfall. Widersprüchliche Dokumente führen die Maschine in die Irre. Den konkreten Aufbau dieser Bauteile behandeln die Teile 02 und 04.
§ 04 · Warum nicht alles zugleich geladen wird
Zum Schluss dieses Lexikons eine Korrektur: Sobald Arbeit zugewiesen wird, werden alle Agenten und Skills in den Kopf der Maschine geladen. Das stellt man sich leicht vor, aber so ist es nicht und so darf es nicht sein. Normalerweise sieht die Maschine nur Listen: Namen der Arbeiter mit einer Zeile Beschreibung, Namen der Verfahren mit einer Zeile Beschreibung. Den vollständigen Text sieht sie erst, wenn der Arbeiter tatsächlich aufgerufen wird oder das Verfahren tatsächlich auslöst. Denk an eine Bibliothek: Die Bücher stehen im Regal; auf dem Tisch liegt nur das gerade gelesene.
Warum? Erstens wegen der Aufmerksamkeit. Die Zahl der Anweisungen, die eine Maschine gleichzeitig verarbeiten kann, ist begrenzt. Es ist bereits gemessen worden: Zehn Regeln befolgt sie überwiegend; bei hundert verliert sie den Blick dafür, was wichtig ist. Liegen Deployment-Verfahren, Debugging-Regeln und visuelle Prüflisten unabhängig von der aktuellen Übersetzungsarbeit vollständig offen, begräbt der Stapel die entscheidende Zeile. Je mehr Bücher auf dem Tisch, desto unschärfer der Blick auf den aktuellen Satz.
Zweitens wegen der Kosten. Jeder Buchstabe vor der Maschine kostet—jedes Mal erneut. Bei jedem Session-Turn dreißig ungenutzte Verfahren vollständig zu laden, ist wie eine Firma, die bei jeder Besprechung sämtliche Mitarbeiterhandbücher kopiert und verteilt. Drittens wegen der Isolation. Zehntausende Zeilen Zwischenausgabe, die ein Arbeiter beim Durchsuchen von Material erzeugt, bleiben an seinem Schreibtisch. In das Hauptgespräch kehrt nur eine Seite Zusammenfassung zurück. Teilen alle einen Schreibtisch, verschwindet diese Brandmauer.
Daraus folgen zwei praktische Punkte. Erstens ist die einzeilige Beschreibung in der Liste faktisch der Aufrufknopf. Die Maschine entscheidet allein anhand dieser Zeile, ob sie jemanden aufruft. Schreibe deshalb nicht nette Beliebigkeiten wie „nützlicher Helfer“, sondern eine erkennbare Auslösebedingung: „Bei Prüfung einer Fertigmeldung; nur beurteilen, keinen Code ändern.“ Zweitens dürfen zwingende Verfahren wie das Fertigmeldungs-Gate nicht allein vom Urteil der Maschine abhängen. Aus einer Liste auswählen zu können bedeutet auch, die Freiheit zu haben, nicht auszuwählen. Verfahren, die nicht übersehen werden dürfen, bekommen deshalb den zusätzlichen Auslöser aus Teil 04: einen Hook, der die Sprachgewohnheit abfängt.
Beitrag lesen: sass.studio.