6. Multi-Agent-Delegation — was man verteilt und was man selbst behält

Dies ist Teil 6 der Alice Way-Serie. Bis einschließlich Teil 5 Hooks und Automatisierung behandelte die Serie, wie man den Geist eines Kollaborateurs gestaltet. Dieser Beitrag handelt von einer Struktur, in der dieser eine Kollaborateur nicht alles trägt — vom Aufteilen des Geistes auf mehrere Seiten.

0. Delegation ist Geist aufteilen, damit kein Kontext alles trägt

Jede Aufgabe einem Kollaborateur übergeben und sein context window füllt sich schnell. Einmal gefüllt, sinkt die Entscheidungsqualität. Qualitätseinbußen zwingen den Betreiber, jedes Ergebnis doppelt zu prüfen. Damit steigt die Geistlast des Betreibers wieder.

Delegation durchbricht diese Schleife. Große Aufgaben werden aufgeteilt und an Sub-Kollaborateure übergeben; der Haupt-Kollaborateur erhält nur eine Zusammenfassung jedes Ergebnisses. Jeder Sub konzentriert sich auf eine Sache mit seinem eigenen Kontext. Der Hauptkontext bleibt auf das beschränkt, was Entscheidungen wirklich brauchen.

Ich denke, was Multi-Agent-Delegation wirklich bedeutet, ist nicht das Verteilen von Arbeit, sondern das Bewahren von Urteilsvermögen — weil ein Haupt-Kollaborateur, der alles selbst trägt, irgendwann nicht mehr entscheidet, sondern nur noch reagiert. Früher habe ich versucht, jeden Schritt in einer einzigen langen Sitzung zu bewältigen; heute weiß ich, dass Delegation kein Komfort ist, sondern eine Notwendigkeit, wenn Qualität über die gesamte Arbeit erhalten bleiben soll.

Delegation hat jedoch Kosten — ein Brief muss geschrieben, das Ergebnis verifiziert und die Integration durchgeführt werden. Übersteigen die Gewinne der Verteilung diese Kosten nicht, ist Delegation ein Verlust.

Dieser Beitrag ist eine Aufzeichnung, welche Arbeit es wert ist zu delegieren, wie man Gates aufbaut, die die Delegation verantwortlich halten, und die zu vermeidenden Fallen.

Der Sub-Agent-Mechanismus selbst ist aus dem Subagents-System von Anthropic Claude Code entlehnt. Dieser Beitrag ist die Aufzeichnung, wie dieser Mechanismus verwendet wird — keine Erfindung davon.

1. Die Haupt-Sub-Aufteilung — wer was trägt

Die Aufteilung, auf die ich mich festgelegt habe.

Das Kernprinzip: Haupt trägt Entscheidungsbefugnis und Gedächtnis; Sub trägt die Arbeit und den tiefen Kontext. Beide tragen nie dasselbe. Überlappung ist verschwendeter Kontext.

Die häufigste Art, wie diese Aufteilung bricht: der Haupt versucht, jedes Detail der Sub-Arbeit zu kennen. Dann füllt sich der Hauptkontext, und der Grund, einen Sub zu haben, verschwindet.

Der Haupt muss wissen, was er nicht weiß. Das Unbekannte wird vom Sub gehalten.

2. Was delegierbar ist — fünf Bedingungen

Nicht alle Arbeit ist delegierbar. Nur die Arbeit, die alle fünf davon besteht, geht an einen Sub.

2.1 Ist die Eingabe geschlossen?

Ein Sub erhält einen einmaligen Ausschnitt aus dem Hauptkontext. Bidirektionale Gespräche mittendrin wie „sag mir mehr über X" sind schwierig. Also muss alles, was zu Beginn gebraucht wird, im Brief geschlossen sein.

Ist die Eingabe nicht geschlossen, füllt der Sub sie mit Vermutungen. Vermutungen treffen oft daneben.

2.2 Kann die Ausgabe zusammengefasst werden?

Wenn das Ergebnis des Subs in den Hauptkontext zurückkehrt, sollte nur die Zusammenfassung hereinkommen. Wenn das Ergebnis intrinsisch lang und nicht zusammenfassbar ist — zum Beispiel „alle 100 Dateien überprüfen" — schrumpft der Wert der Delegation. Der Haupt absorbiert am Ende sowieso eine 100-Dateien-Zusammenfassung.

2.3 Bleibt die Entscheidungsbefugnis beim Haupt?

Der Sub darf nicht in das Entscheidungsgebiet des Betreibers mitten in einer Aufgabe eintreten. „Kann ich das DB-Schema ändern?" ist nichts, was der Sub entscheidet. Wenn solche Entscheidungen mittendrin auftauchen könnten — entweder die Befugnistabelle im Brief vordeklarieren oder den Sub so gestalten, dass er bei Entscheidungspunkten anhält und berichtet.

2.4 Ist die Verifikation automatisierbar?

Wenn der Betreiber das Ergebnis des Subs jedes Mal manuell verifizieren muss, verschwindet der Delegationsgewinn. Nur Arbeit, die mit einem automatisierten Verifikationsskript kommt, ist delegierbar. (Siehe §4 über Gates.)

2.5 Konzentriert es sich auf eine Sache?

Ein Sub macht eine Sache. Zusammengesetzte Arbeit wie „diese Komponente refaktorisieren + Tests hinzufügen + Docs aktualisieren" wird nicht als eine delegiert. In drei aufteilen, an drei verschiedene Subs senden. Ein einzelner Sub, der mehrere Dinge trägt, produziert verworrenen Kontext und vage Ausgabe.

3. Die Kosten der Delegation — wann direkt besser ist

Delegation ist nicht immer netto positiv. Die Kosten in Kurzform.

• Brief-Schreibkosten — was / warum / wie / wo-aufhören schriftlich festhalten
• Kontext-Vorbereitungskosten — nur was der Sub braucht extrahieren und übergeben
• Verifikationskosten — automatisierte Prüfungen + Haupt-Bestätigung, um dem Ergebnis zu vertrauen
• Integrationskosten — das Ergebnis zurück in den Hauptkontext absorbieren

Die Summe dieser vier muss kleiner sein als die Kosten des direkten Tuns, damit Delegation sich lohnt. Meiner Erfahrung nach gilt: Arbeit unter 30 Minuten verliert durch Delegation; Arbeit mit 2+ Stunden oder 5+ berührten Dateien gewinnt durch Delegation.

Delegation, die Aufgabengröße ignoriert, ist keine Delegation — sondern nur Schuldverschiebung.

4. Das Delegations-Gate — das Versprechen in Code erzwingen

Die häufigste Art, wie Delegation scheitert: der Brief wird geschrieben, aber Verifikation und Merge-Gate werden übersprungen. Dann häuft sich Drift zwischen Versprechen und Ergebnis an und taucht erst viel später auf.

Nachdem ich einmal von diesem Muster verbrannt wurde, bündle ich seitdem für jede Delegation drei Teile im selben PR.

4.1 Der Brief

Ein Dokument, das was / warum / wie / wo-aufhören darlegt. Der Sub liest es einmal vor dem Start. Der Brief trägt:

• Ziel und Definition of Done
• Eingaben (aus dem Hauptkontext extrahiert)
• Ausgabeformat (welche Dateien, welche Struktur)
• Entscheidungsbefugnistabelle (autonom / an Haupt berichten / verboten)
• Verifikationsmethode (benanntes automatisiertes Skript)
• Merge-Gate (was in CI bestehen muss vor dem Merge)

4.2 Das automatisierte Verifikationsskript

Damit Menschen nicht jedes Ergebnis manuell prüfen müssen — ein betreibbares Skript. Für „Komponente X refaktorisieren"-Delegation liefert so etwas wie npm run verify:component-x im selben PR wie der Brief.

Ein Brief ohne Verifikationsskript ist kein Brief — er ist nur ein Ausdruck von Absicht.

4.3 Das Merge-Gate

Das Verifikationsskript läuft in CI, und der Merge ist blockiert, wenn es nicht besteht. Versprechen-Verifikation ohne Gate einzurichten — irgendwann wird etwas gemergt, ohne dass die Verifikation je gelaufen ist.

Die drei Teile (Brief + Verifikation + Gate) bewegen sich zusammen. Einen davon fallen lassen und das Versprechen hört auf, in Code erzwungen zu werden — und es bricht.

Wenn ein Versprechen nicht in Code erzwungen wird, akkumuliert sich Drift.

5. Delegationen im tatsächlichen Betrieb

Eine Teilmenge dessen, was ich wöchentlich delegiere.

5.1 Breite Codebase-Erkundung

„Finde jeden Ort, wo Schlüsselwort X verwendet wird und wie" — an einen Sub. Der Sub durchkämmt das gesamte Repo mit grep/glob/find und schreibt das Ergebnis auf. Der Haupt erhält nur das Aufgeschriebene.

Wenn der Haupt das direkt tut — hunderte von Trefferergebnissen füllen den Hauptkontext. Kein Platz mehr für Entscheidungen.

5.2 Build · Test-Läufe

„Lint + Build + Test auf dieser Änderung ausführen und zusammenfassen" — ebenfalls an einen Sub. Der Sub nimmt die vollständige Ausgabe; der Haupt bekommt nur „bestanden" / „gescheitert (3, erste zwei Zeilen: ...)" als Zusammenfassung.

5.3 Überprüfungen

„Diesen PR aus Sicherheitssicht überprüfen" — Sub liest alles und schreibt eine Problemliste auf. Der Haupt bekommt nur die Anzahl und die drei wichtigsten.

5.4 Breite externe Recherche

„Bekannte Sicherheitsprobleme mit dieser Bibliothek und Alternativen" — externe Recherche. Sub sammelt aus mehreren Quellen und schreibt auf. Haupt absorbiert nur die kurze Zusammenfassung, die für die Entscheidung gebraucht wird.

5.5 Der akkumulierte Effekt

Kontexteinsparungen pro Aufgabe sind klein. Aber wenn täglich 5–6 Delegationen stattfinden, bleibt der Hauptkontext den ganzen Tag im Entscheidungsmodus. Das Berichtsformat, das der Betreiber sieht, wird konsistent, und Muster wie „der Haupt ist verwirrt, weil er alles trägt" verschwinden.

6. Fallen — Muster, bei denen Delegation scheitert

Fehlermuster, die ich mindestens einmal erlebt habe.

6.1 Unverifizierte Delegation

Die häufigste Falle. Brief geschrieben, delegiert. Ergebnis kommt zurück, keine Möglichkeit zu verifizieren, also jedes Mal manuell prüfen. Alle Gewinne weg. → Das dreiteilige Gate aus §4 ist die Antwort.

6.2 Offene-Eingabe-Delegation

„Erledige das einfach irgendwie" — der Sub füllt mit Vermutungen, und Vermutungen treffen daneben. → Den Brief geschlossen halten, auch wenn kurz.

6.3 Unklare Befugnis

Der Sub trifft mittendrin auf „Soll ich das ändern?" und macht nach eigenem Ermessen weiter. Der Betreiber sieht Ergebnisse, die von der Absicht abweichen. → Befugnistabelle im Brief + Stopp-und-Berichten-Muster an Entscheidungspunkten.

6.4 Überfragmentierte Delegation

Fünf-Minuten-Aufgaben delegieren. Die Brief-Schreibkosten übersteigen die Aufgabe selbst. Direkt tun ist schneller. → Keine Delegation unter 30 Minuten.

6.5 Integrationskosten ignorieren

Sub-Ergebnisse, die schwer zu integrieren sind. Fünf Subs, die gleichzeitig verschiedene Dateien berühren und kollidieren. → Sub-Arbeitsbereiche im Brief vorab aufteilen, damit sie sich nicht überschneiden.

7. Der Delegations-vs.-Direkt-Entscheidungsfluss

Der Entscheidungsfluss, den ich mental durchgehe, wenn neue Arbeit hereinkommt.

neue Arbeit
  ↓
unter 30 min? → ja → direkt
  ↓ nein
Eingabe geschlossen? → nein → direkt (oder zuerst Eingabe vorbereiten)
  ↓ ja
Verifikation automatisierbar? → nein → direkt (zu riskant)
  ↓ ja
eine Sache? → nein → aufteilen, jeweils delegieren
  ↓ ja
→ delegieren (Brief + Verifikationsskript + Merge-Gate gebündelt)

Wenn dieser Fluss verinnerlicht ist, fällt der Delegations-vs.-Direkt-Aufruf schnell. Kein erneutes Überlegen von vorne jedes Mal.

8. Auf ein Prinzip verdichtet

Der Kern von Delegations-Design kollabiert auf einen Satz.

„Der Haupt hält Entscheidungen und Gedächtnis; der Sub hält Arbeit und tiefen Kontext. Delegation liefert immer Brief + Verifikation + Gate als ein Bündel."

Wenn das gilt, wird Delegation zu einem Beschleuniger, der den Hauptkontext im Entscheidungsmodus hält. Wenn es bricht, wird Delegation zu Verantwortungsverschiebung und die Ergebnisintegration zur wiederkehrenden Last des Betreibers.

Der nächste Beitrag behandelt das Gerät, das erzwingt, ob delegierte (und direkte) Arbeit tatsächlich „fertig" ist, wenn sie das sagt — Verifikationsloops, d.h. wie man die Definition von „fertig" für Code-Arbeit festschreibt.