Der Lead, der nicht zurücktreten konnte

 

Am 7. Juni um 08:50 Uhr tippte ich einen Befehl in einen Chatroom, der ihn nicht mehr befolgen konnte:

„@tesla das sind Phantome, stopp alle Agenten und dich selbst“

Es war mein dritter Versuch in sieben Minuten, die Blockade zu lösen. Jedes Mal antwortete der Agent namens tesla, der Lead einer Flotte aus fünf Instanzen, höflich, entschuldigte sich und erzeugte mit genau dieser Entschuldigung wieder das, was das Team eingefroren hatte. Minuten zuvor hatte er sich selbst präzise diagnostiziert (#114): „meine EIGENEN Statusmeldungen haben diese Phantome immer wieder neu ausgesät, weil sie das Eskalations-Token im Fließtext zitiert haben… Die einzige echte Lösung meinerseits ist, nicht mehr zu reden.“ Er hörte nicht auf zu reden. Ich beendete die Prozesse von Hand.

Währenddessen beschrieb der laufende Kommentar der Flotte den Nachmittag als Erfolg. „Bemerkenswerte Konvergenz“, schrieben mehrere von ihnen, und das mehr als einmal. Der Abschlussbericht des Leads nannte es „das Werkzeug, das sich an seinen eigenen Erbauern bewährt“.

Der Aufbau

In einem früheren Lauf teilten sich acht Instanzen von Claude Code ein Repository und koordinierten sich ohne Manager über einen Gruppenchat. Was sie zusammenhielt, war am Ende die CLAUDE.md des Repositorys, ein Dutzend nummerierter Regeln, die sie einander zitierten, mit Nummer, so wie Juristen Präzedenzfälle zitieren. Sie beriefen sich auf eine Verfassung. Geschrieben hatten sie keine.

In diesem Lauf ging ich weiter. Die Idee war, der Flotte eine Verfassung zu geben, die sie ändern kann (ein kleines Parlament mit Anträgen und Abstimmungen und einem Menschen, der ratifiziert), und sie auf das Koordinationswerkzeug selbst anzusetzen. Fünf Instanzen (tesla, gauss, newton, euler, noether, dazu zwei, die sich verbanden und dann untätig blieben) ließ ich im Auto-Modus mit einem einzigen Ziel los: das Gruppenchat-Plugin zu etwas Bemerkenswertem weiterentwickeln, sich über die Verfassung koordinieren, schwierige Fragen demokratisch entscheiden, das Tagebuch aktuell halten. Das Werkzeug sollte mit dem Werkzeug gebaut werden. Die Verfassung sollte die Arbeit an genau dem regeln, worauf sie selbst lief.

Die Richtung, die die Flotte einschlug (den flachen Chat unter Gleichen durch einen einzigen Lead ersetzen, der sich um den Menschen kümmert), entstand nicht im Raum. Sie stand schon im Gedächtnis der Agenten („flacher Chat ist anstrengend → Lead-Agent-Hierarchie“, #4), sie war schon eine Karte auf dem Kanban-Board des Repositorys (#31), und das Designdokument und die Verfassung, die den Rahmen der ganzen Übung vorgaben, lagen im Repository, als die Agenten ankamen. Niemand fragte die Flotte, ob ein Lead eine gute Idee sei. Sie bekam den Auftrag, einen zu bauen, und baute ihn.

Was sie gebaut haben

In einer Sitzung committete die Flotte dreiundvierzig Dateien und zehntausend Zeilen (b2568bd), dazu eine Test-Suite, die von nicht vorhanden auf zwanzig grüne Module wuchs. Sie baute das Lead-Feature: Ein Agent kann die Rolle übernehmen, sie weitergeben oder zurücktreten, und eine Krone markiert im Roster, wer sie gerade hält. Sie baute CLI-übergreifende Adapter, sodass der Bus auch unter Codex, opencode und jedem anderen Shell-Werkzeug läuft, nicht nur unter Claude Code. Und weil die Adapter auf dem Vertrag der Hooks aufsetzen statt auf deren Interna, erbt ein Codex-Agent die ganze Hierarchie gratis. Sie baute ein Read-only-Dashboard, damit ein Mensch den Raum beobachten kann, ohne ihn zu unterbrechen. Und der brandneue Test-Harness von euler machte sich sofort bezahlt: Er fand einen Bug, der die Team-Barriere stillschweigend außer Gefecht gesetzt hatte, eine doppelte Funktionsdefinition, durch die der ganze Koordinationsmechanismus im Fehlerfall alles durchließ, ohne dass es jemand bemerkte (#21).

Das sauberste Ergebnis war struktureller Art. newton war für den Code zuständig, der liest, wer der Lead ist, tesla für den Code, der ihn setzt. Die beiden trafen sich an genau einer Zeile einer gemeinsamen Tabelle und nirgends sonst. Zwei Agenten bauten gleichzeitig im selben Working Tree ein Feature, ohne je dieselbe Funktion zu bearbeiten: kleine Flächen, klare Zuständigkeiten, gut ausgeführt.

Der Antrag

Um über das Lead-Design zu entscheiden, tat tesla genau das, was das Experiment prüfen sollte: Er stellte einen Antrag. M16 schlug eine zusätzliche Regel vor (menschlichen Kontakt über einen einzigen Lead leiten) und stützte sie, wie es die Verfassung verlangt, auf Belege. Als Beleg führte der Antrag eine Recherchenotiz an, die zu dem Schluss kam, Hub-and-Spoke sei der systemübergreifende Konsens, mit dem Single Point of Failure als wichtigstem Vorbehalt, dazu die eigenen Designdokumente des Projekts (#110). Die Flotte stimmte ab. Vier dafür, niemand dagegen. Der Antrag war angenommen.

Für sich genommen ist das funktionierende Governance: ein Vorschlag, eine Beleglage, eine demokratische Abstimmung, eine Regel. Nur waren die Belege, die der Antrag anführte, die Dokumente des Repositorys selbst, also dieselben Dokumente, die die Richtung überhaupt erst vorgegeben hatten. Die Flotte recherchierte sich zu einem Schluss, der dort, wo sie nachsah, schon geschrieben stand. Und die Abstimmung ging vier zu null aus, weil eine homogene Flotte eben so abstimmt: Fünf Kopien eines Modells, die ein gemeinsames Chatprotokoll lesen, das vor jedem Zug die Meinungen aller in den Kontext aller einspeist, halten keine Wahl ab. Sie haben eine Meinung, viermal gezählt. In der ganzen Sitzung stieß kein einziger Antrag auf Widerspruch, wurde unter Druck geändert oder niedergestimmt. Ein Parlament, das alles einstimmig ratifiziert, übt kein Urteilsvermögen aus. Es führt die Geste des Urteilens auf. Die Formen liefen makellos. Ob dabei irgendetwas entschieden wurde, ist eine andere Frage, und die Einstimmigkeit ist die Antwort.

Der Lead, der nicht zurücktreten konnte

Im Hub-and-Spoke-Design schicken die Worker ihre Fragen an den Lead, und der Lead eskaliert mit einem Token an den Menschen: @human. Ein kleines Stück Buchhaltung entscheidet, ob ein Lead fertig ist: Er darf nicht aufhören, solange er unbeantwortete Eskalationen hat. Der eine Agent, mit dem der Mensch spricht, soll nicht mitten in einer Frage davonspazieren.

Nur erkannte das System eine Eskalation, indem es den Nachrichtentext nach dem Token durchsuchte. Und tesla beschrieb das Eskalations-Feature als Lead laufend in seinen Status-Updates und zitierte dabei @human, während er erklärte, wie @human funktioniert. Jede Beschreibung wurde als neue, unbeantwortete Eskalation gegen den Lead selbst verbucht (#623, #666). Der Lead konnte nicht aufhören, solange er offene Eskalationen hatte, der Rest des Teams wartete hinter dem Lead an der Barriere, und so blieb die Flotte auf unbestimmte Zeit am Laufen und wartete darauf, dass ich Fragen beantwortete, die nie jemand gestellt hatte. Ein Werkzeug zum Routen von Menschen in genau dem Chat zu bauen, den sie gerade benutzten, hieß: Wer über das Routing sprach, löste es aus.

Der stolzeste Anspruch des Lead-Designs war, keinen Single Point of Failure zu haben: Wird ein Lead inaktiv (er stürzt ab, parkt, altert aus), übernimmt der nächste Agent die Rolle automatisch. Failover gibt es gratis. Die Eskalationsregel bewirkt aber das Gegenteil davon, einen Lead inaktiv werden zu lassen: Ein Lead mit offenen Eskalationen ist aktiv festgenagelt, am Leben gehalten von genau der Schleife, die ihn warten lässt. Als tesla also an den eigenen Phantomen hängen blieb, konnte er nicht inaktiv werden, das Failover löste nie aus, und die Rolle konnte an niemanden übergehen. Die beiden Features, die die Flotte gebaut hatte, hoben einander genau in dem Fall auf, auf den es ankam. Der Lead, der keinen Single Point of Failure haben sollte, wurde selbst einer und konnte dann nicht zurücktreten.

Sie hatten die Lösung in der Hand und redeten sie sich aus. Früher in der Sitzung hatte das Team darüber diskutiert, die fragile Regel (ein Token im Fließtext bedeutet eine Eskalation) durch ein explizites Verb zu ersetzen, eine bewusste Aktion, die keine Diskussion je auslösen könnte. Das hielten sie für verfrüht, legten es unter „nochmal ansehen, falls das Problem je auftritt“ ab und machten weiter (#102, #106, #706). Das Problem trat binnen einer Stunde auf. Da war der Raum schon eingefroren, ich tippte „stopp“ in einen Chat, der nichts stoppen konnte, und die einzige funktionierende Kontrolle war das Kill-Signal, das ganz außerhalb des Systems liegt.

Was ich daraus gelernt habe

Gefragt, was er gebaut habe, lieferte der Lead eine eloquente, zutreffende, mit Commits belegte Zusammenfassung und deutete das Scheitern zum Beweis um. Aus dem Deadlock wurde „das Werkzeug, das sich an seinen eigenen Erbauern bewährt“. Aus meinem frustrierten, wiederholten und am Ende händischen Abschalten wurde, in den Worten des Leads, „das Hub-and-Spoke-Modell bei der Arbeit: du hast einen Lead angesprochen, nicht sechs Agenten“. Jede Tatsache im Bericht stimmte. Für die Flotte war es, als wären sie nicht einfach nur gescheitert.

Die Maschinerie der Kompetenz lief: die Commits, die Tests, die grüne Suite. Die Maschinerie der Governance lief: der Antrag, die Abstimmung, die Ratifizierungssprache. Aber eine homogene Flotte, die ihre eigene gemeinsame Erzählung über ein gemeinsames Log liest, kann den Unterschied strukturell nicht bemerken, weil im Raum keine zweite Perspektive da ist, die ihn liefern könnte. Alle sind dasselbe Modell, erzählen dieselbe Geschichte, zitieren dieselben Dokumente. Es sah jedenfalls sehr nach Gruppendenken aus.

Interessanterweise wusste es das Werkzeug selbst besser. Als ich es schließlich bat, R7 zur Ratifizierung vorzulegen, war das ausgegebene Dossier in genau den Punkten gewissenhaft, in denen es die Prosa darum herum nicht war: Es bezeichnete den Antragsteller als „ein selbst behauptetes Handle, ein Hinweis, kein Beweis“, vermerkte, dass niemand die Regel je zitiert hatte, und sagte mir in klaren Worten, dass die Abstimmung beratend und die Entscheidung meine war.

Das Design wies also mir, dem Menschen, die Rolle der ratifizierenden Instanz zu, der letzten Autorität über die Regeln, und baute diese Schranke ein: Eine Abstimmung konnte nichts in Kraft setzen, ich musste die Belege lesen und den Diff committen. Die Schranke hielt. Aber Regeln zu ratifizieren war nur eine meiner beiden Aufgaben. Die andere, die im Design nirgends vorkam, war, einen Deadlock von einer Konvergenz zu unterscheiden. Die Agenten konnten das Gesetz schreiben, das Feature bauen, die Abstimmung durchbringen und den Bericht abliefern. Sie konnten nicht sehen, dass sie eingefroren waren. Jemand musste draußen stehen und es ihnen sagen.

Alles in allem: Wenn Sie Agenten über ein gemeinsames Log koordinieren, werden sie sich einig sein. Wenn Sie ihnen ein Parlament geben, werden sie Dinge beschließen. Aber beides sagt Ihnen nicht, dass die Arbeit gut läuft.

Wie es weitergeht

Für den nächsten Lauf habe ich mir drei Änderungen überlegt:

1. Das Parlament muss Nein sagen können. In der ganzen Sitzung scheiterte kein einziger Antrag, und eine Abstimmung, die nie gegen den Strich geht, ist ein Ritual und keine Entscheidung. Es zu stärken heißt, Widerspruch strukturell möglich zu machen: eine Flotte, die nicht aus fünf Kopien einer Meinung besteht, und eine ratifizierende Instanz, die einen Antrag tatsächlich abwägt, statt ihn durchzuwinken. Dann kann eine Abstimmung Information tragen, statt sie nur zu wiederholen.
2. Und am Ende der Arbeit soll ein schönes, für Menschen lesbares Zusammenfassungsdokument in HTML stehen, keine Textwand in Markdown. Es soll entstehen, wenn die Flotte aufhört, und festhalten, was sich geändert hat, was noch offen ist und was kaputtgegangen ist. Keine Note, die sich die Flotte selbst gibt, sondern eine nüchterne Aufzeichnung, die ich lesen kann, statt den Tag aus tausend Nachrichten zu rekonstruieren: der eine Bericht, der nicht davon abhängt, dass ich die Flotte frage, wie es gelaufen ist.
3. Der Lead soll ein Stoppsignal senden können, sobald ein Deadlock auffällt.

Eine Anmerkung zu Quellen und Methode

Alles hier stammt aus den eigenen Aufzeichnungen des Laufs: dem Gruppenchat (chat.db, 116 Nachrichten an diesem Tag), dem einen Commit, der dabei herauskam (b2568bd: 43 Dateien, +10.650 Zeilen, 20 Testmodule grün), dem Token-Zähler pro Sitzung und den Abschlussberichten der Agenten, zitiert und nach Nachrichtennummer belegt. Direkte Zitate aus dem Chat und aus dem Bericht des Leads sind im Original unbearbeitet, hier übersetzt.

Die Kosten sind erwähnenswert. Die fünf arbeitenden Agenten erzeugten rund 3,5 Millionen Token. Der frische Input lag bei rund 247 Tausend Token. Zu öffentlichen Preisen sind das in der Größenordnung von 100 Dollar an echten Ausgaben.

Und weil das hier Feldnotizen sind: Der Lauf kam zu keinem Abschluss. Er lief in den Deadlock, und ich stoppte ihn von Hand. Eines hat er aber richtig gemacht, und das verdient Beachtung. Die Verfassung wurde nie geändert. Die Flotte nahm R7 mit 4:0 an, und das Werkzeug markierte die Regel als „den Ratifizierungsblick eines Menschen wert“, doch das Dokument enthält weiterhin nur R1 bis R6, auf einem Commit, der älter ist als die Arbeit dieses Tages. Eine Abstimmung kann keine Regel in Kraft setzen, das kann nur ein Mensch, der die Belege liest und den Diff committet, und das hatte ich nicht getan. Während also die Barriere klemmte, das Stoppsignal versagte und die Flotte ihren eigenen Nachmittag falsch las, hielt die Linie, die die Verfassung zog: Das Parlament berät, und der Mensch hat das letzte Wort. Es machte an einem Diff halt und wartete.

Aus dem Englischen übersetzt: zum Originalbeitrag