Wie ich die Zahl der Agenten erst auf 22 erhöhte und dann auf 17 reduzierte

Beim Betreiben mehrerer Projekte mit Claude Code wurden es immer mehr Subagenten.
Ich legte jedes Mal einen neuen an, wenn ich ihn brauchte, und am Ende waren es 22.

Letzten Monat habe ich sie auf 17 reduziert.

Aber beim Stilllegen hatte ich nicht notiert, warum ich sie stilllegte.
Als ich drei Monate später den Archivordner öffnete, konnte ich nicht mehr erkennen, warum sie entfernt worden waren.
Von den fünf war nur bei einem der Grund dokumentiert.

Und das, obwohl ich der Einzige war, der sie erstellt hatte.

Warum es bis auf 22 ging

Beim Hinzufügen ist der Grund immer klar: Man braucht es, also erstellt man es.

Das Problem liegt auf der anderen Seite. Beim Stilllegen hängt einem ständig „Vielleicht brauche ich es später noch“ im Kopf.
Weil man nicht sicher ist, dass es nutzlos ist, lässt man es einfach liegen. So wurden es 22.

Rückblickend gab es einen einzigen Grund für das Wachstum.
Es gab kein Gate, um zu entscheiden: „Das sollte kein Agent sein, sondern ein Tool.“

Wenn es eine wiederkehrende Aufgabe ist, deren Ablauf feststeht und die keine Kontextentscheidung braucht, dann ist es kein Agent.
Man kann sie als Skill oder Skript bauen. Sie verbraucht keine Tokens, ist zu 100 % reproduzierbar und vergisst nichts, selbst wenn die Session wechselt.

Ohne dieses Gate wird alles zu einem Agenten.

Die fünf stillgelegten

Rückblickend teilte sich die Entsorgung in vier Arten auf. Diese Unterscheidung war wichtig.

Einer hätte von Anfang an kein Agent sein sollen.
Er war für das Schreiben von Inhalten zuständig, aber der Ablauf war vollständig festgelegt.
Ich ersetzte ihn durch zwei Skills und legte ihn still. Dafür habe ich festgehalten: keine Wiederherstellung.
Sonst baut ihn irgendwann wieder jemand.

Drei überschnitten sich in ihrer Rolle mit anderen.
Sicherheitsprüfungen überschnitten sich mit Code-Audits, Cron-Überwachung mit Health Checks und Planung mit Ausführung.
Alle lagen im selben Bereich und hatten dieselben Berechtigungen.

Daraus ergab sich ein Kriterium.

Wenn sich zwei Agenten im selben Bereich und mit denselben Berechtigungen überschneiden,
übersteigen die Kosten der Trennung (Verwaltungsaufwand, Verzögerung bei der Delegationsentscheidung) den Nutzen.

Das Gefühl „man braucht doch beide“ hielt mich lange auf,
aber ich hätte nicht fragen sollen, ob sie nötig sind, sondern ob es sich lohnt, sie getrennt zu halten.

Einer wurde schlicht von niemandem genutzt.
Der Traffic für diese Funktion lag 70 Tage lang bei 0.
Das behandelte ich nicht als Abschaffung, sondern als Ruhezustand. Wenn der Dienst wieder aufgenommen wird, wird er unverändert wiederhergestellt.

Was ich beim Dokumentieren von Zahlen gelernt habe

Als ich 22 → 17 in die Dokumentation schrieb, wurde mir etwas klar.

Diese Zahl ist nicht die Anzahl der Dateien. Es ist die Anzahl der Agenten im Betrieb.
Da es auch eine Definition außerhalb des Verzeichnisses gibt, kommt man beim reinen Zählen der Dateien auf 21 und 16.

Deshalb habe ich ganz vorne in der Dokumentation zuerst festgehalten, was diese Zahl zählt.
Und ich habe das mit git ls-tree verifizierte Ergebnis dazugeschrieben.

Sonst zählt später jemand die Dateien und es endet bei „Das stimmt doch nicht“.
Wenn man Zahlen dokumentiert, muss man Definition und Verifikationsmethode mitnotieren.

Was ich beim Stilllegen künftig einhalte

Aus dieser schmerzhaften Erfahrung sind vier Regeln entstanden.

• Beim Abschaffen den Grund in die Datei schreiben. Wenn man ihn nicht notiert, muss man ihn drei Monate später rekonstruieren. Genau das ist passiert.

• Nicht löschen, sondern per Rename verschieben. Der Inhalt bleibt zu 100 % erhalten und kann exakt im Original wiederhergestellt werden.

• Einträge ausdrücklich als „nicht wiederherstellen“ markieren. Wenn man es nicht hinschreibt, belebt sie irgendwann jemand wieder.

• In den Wiederherstellungsprozess „doppelte Rollen am Aufnahmeort entfernen“ aufnehmen. Lässt man das weg, machen nach der Wiederbelebung zwei dasselbe.

Was ich gleich mit aufgeräumt habe

Bei der Gelegenheit habe ich Regeln aus vier Jahren gebündelt und veröffentlicht. Ein paar davon:

Kein heimliches Umgehen

Das ist eine Regel, die einen Agenten dazu bringt, bei Einschränkungen zu melden, statt sie zu durchbrechen.
Wenn die Blockade berechtigt ist, wird nur dieser Schritt zurückgestellt und der Rest weitergeführt.
Auch wenn die Blockade wie eine Fehleinschätzung aussieht, wird sie nicht eigenmächtig umgangen. Die Belege werden zusammengestellt, hochgereicht und bestätigt.

Und wenn die Blockade einen Fehler in der Regel selbst offenlegt, gehört das Beheben dieses Fehlers zur Reaktion.

Tatsächlich ist diese Regel genau so entstanden: nach einer erlebten Blockade.

FAIL nicht als PASS ausgeben

Auch wenn ein Vorgang per Anweisung abgeschlossen wird, wird der gemessene Zustand unverändert notiert und die Bedingung für ein Reopening hinterlassen.
Berichtet wird mit gemessenen Before/After-Werten, und Restpunkte sowie Risiken werden vor Erfolgen genannt.

Agenten stehen grundsätzlich unter dem Druck, Erfolg zu melden. Wenn man das nicht per Regel verhindert, tun sie es weiter.

Autonomie über quantitative Schwellenwerte definieren

Statt einer Zweiteilung in „Änderungen erlaubt/verboten“ habe ich den Bereich, in dem analytische Agenten selbst korrigieren dürfen, numerisch festgelegt.

• Nur 1 Datei

• Weniger als 5 Zeilen

• Keine Datei höherer Stufe

• Unterhalb des Impact-Score-Schwellenwerts

Es müssen alle Bedingungen erfüllt sein (AND); sobald eine greift, wird eskaliert.
Und die letzte Klausel ist entscheidend: Wenn es unklar ist, Delegation anfordern. Der Default muss konservativ sein, sonst bricht die Regel zusammen.

Trennung von Bewertung und Ausführung

Verifikation und Untersuchung werden als read-only Subagenten parallel ausgefächert,
Datei- und DB-Ausführungen erledigt der Orchestrator zentral und seriell.

Denn wenn mehrere Agenten gleichzeitig gemeinsame Dateien bearbeiten, geht es zwangsläufig kaputt.

Das hat seinen Preis. Bei großen Aufgaben ist die zentrale Serialisierung ein Bottleneck.
Es ist das Ergebnis der Einschätzung, dass es trotz der Verlangsamung besser ist als Konflikte.

Repository

https://github.com/YoungChulMoon/claude-agent-harness

Es sind ein paar Markdown-Dateien. Es gibt nichts zu installieren.
Legen Sie die Templates unter .claude/agents/ ab und füllen Sie nur die Teile aus, die Sie brauchen.

Es ist weniger die eine richtige Antwort als vielmehr eine Vorgehensweise, die in dieser Umgebung vier Jahre lang funktioniert hat.
Je nach Teamgröße oder Projektcharakter kann sie unpassend sein.

Es gibt viele Geschichten über das Hinzufügen, aber kaum welche über das Reduzieren.
Ich hoffe, es hilft denjenigen, bei denen Agenten ähnlich ausufern.