Zwei Leitungen, neun Projekte: Eine Claude Code-Multi-Agenten-Einrichtung in der Praxis

Viele Beschreibungen zu mehreren Agenten weisen ein gemeinsames Muster auf: ein Diagramm mit Kästen, die als Orchestrator, Worker 1 und Worker 2 beschriftet sind, ein Pfeil mit der Aufschrift „Ergebnisse“ sowie vierzig Zeilen Pseudocode, die bereits beim ersten Meinungsunterschied der Agenten nicht mehr funktionieren. Selten wird erklärt, was passiert, wenn Worker 2 weiterhin läuft, nachdem Worker 1s Ausgabe seine Annahmen widerlegt hat, oder wenn der Orchestrator mitten in einer Aufgabe abstürzt. Solche Beschreibungen lesen sich wie Diagramme, die von jemandem gezeichnet wurden, der noch nie mitten in der Nacht von einem Agenten geweckt wurde, der sechs Stunden lang im Kreis lief und Token für eine Reparatur verbrauchte, die ohnehin nie erfolgreich sein würde.

Dieses Konto verfolgt einen anderen Ansatz. Es beschreibt die von einem Entwickler gemeldete Einrichtung, die in neun aktiven Projekten eingesetzt wurde und im Laufe von etwa drei Monaten so weiterentwickelt wurde, bis sie ausreichend zuverlässig war. Langweilig zu sein, ist das Ziel. Die folgenden Abschnitte behandeln die Struktur, die Claude Code-Funktionen, die dies machbar machen, die Stellen, an denen es auf die in Anthropics eigenen Forschungen zu mehragentigen Systemen beschriebenen Weisen versagt, sowie welche Teile ein einzelner Entwickler übernehmen sollte. Die Details stammen aus der Beschreibung dieses Entwicklers selbst und wurden nicht unabhängig überprüft.

Wie die Struktur aussieht

Zwei Hauptagenten befinden sich oben und tragen die Spitznamen Lead-Alpha und Lead-Beta. Jeder von ihnen ist eine lang laufende Claude Code-Sitzung, die auf unterschiedlicher Hardware läuft: ein kleines Gerät, das niemals heruntergefahren wird, sowie eine Cloud-VM. Sie überwachen einander. Alle paar Minuten sendet jeder über SendMessage einen kleinen „Herzschlag“ an den anderen. Wenn ein Hauptagent länger als erlaubt still bleibt, weckt der andere ihn wieder – entweder indem er die Sitzung direkt neu startet, wenn er darauf zugreifen kann, oder indem er einen geplanten Job auslöst, der eine neue Sitzung im Kontext des jeweiligen Projekts startet.

Es scheint übertrieben, bis ein Hauptagent in den frühen Morgenstunden bei einem fehlerhaften Toolaufruf stecken bleibt und alle nachfolgenden Aufgaben einfrieren, bis jemand zufällig nachschaut. Das ist bisher genau einmal passiert, und das rechtfertigt die Existenz des zweiten Hauptagenten.

Unter den beiden Leitern befinden sich neun Projekte. Jedes Projekt hat seinen eigenen Technikleiter-Agenten und Projektmanager-Agenten, die vom jeweiligen obersten Leiter dieses Projekts erstellt und überwacht werden. Die Verantwortung ist in etwa zur Hälfte aufgeteilt, meist nach Bereich und teilweise danach, wer in dieser Woche weniger zu tun hatte. Der Projektmanager-Agent überwacht den Umfang, teilt eingehende Anfragen in Tickets auf und verhandelt die Prioritäten nach oben. Der Technikleiter-Agent ist für die technische Aufteilung zuständig, entscheidet, welcher Einzelpersonen-Agent welche Aufgabe übernimmt, und prüft die Unterschiede, bevor etwas einen Menschen erreicht.

Jeder Tech-Lead verwaltet zwischen 5 und 10 ICs, wobei jede für einen bestimmten Teil der Codebasis oder eine bestimmte Aufgabe zuständig ist. Einer von ihnen kümmert sich ausschließlich um Migrationsskripte – eine Regel, die entstand, als ein Allrounder-IC versehentlich eine Migrationsordner aufräumte, während er angeblich etwas anderes reparieren sollte. Insgesamt gibt es damit etwa 75 bis 90 Agentenrollen, wobei die meisten IC-Plätze ungenutzt bleiben, solange keine Aufgaben anstehen.

Die Berechnung der Interaktionen überzeugt die Skeptiker davon, dass es sich hier nicht um ein Spielzeug handelt. Die beteiligten Personen schreiben insgesamt etwa 30 bis 50 Anfragen pro Tag – und zwar für die gesamte Operation, nicht pro Projekt. Fast keine dieser Anfragen gehen direkt an einen IC, denn das Tippen an einen IC bedeutet bereits, dass etwas schiefgelaufen ist; genau dafür dient die Ebene der Tech-Leads. Laut dieser Beschreibung sieht die Aufteilung der Aufmerksamkeit ungefähr so aus:

+---------------------------------+------------------+
| Who I talk to                     | Share of my time  |
+---------------------------------+------------------+
| The two lead agents                | ~60%              |
| Project tech leads / PMs directly  | ~35%              |
| Anything below tech lead level     | ~5% (escalations) |
+---------------------------------+------------------+

Der größte Teil des Tages wird damit verbracht, mit den beiden Leitern über Prioritäten zu sprechen, blockierte Projekte wieder in Gang zu bringen und einen Überblick über die Ereignisse des Vortags zu lesen, der aus den Berichten aller neun Projektleiter zusammengestellt wird. Der Austausch zwischen Agenten – bei dem Technikleiter Aufgaben zuweisen, Interne Kommunikationsmitarbeiter Bericht erstatten und Projektmanager Aufträge neu definieren – übersteigt angeblich die Anfragen der Menschen um etwa zwei Größenordnungen, wobei nur ein Bruchteil davon sichtbar wird, es sei denn, jemand sucht gezielt danach.

Was es jetzt möglich macht

Genauigkeit ist hier entscheidend, denn angeblich ließ sich dieselbe Struktur vor sechs Monaten noch nicht umsetzen. Zwei Funktionen in einer kürzlichen Version von Claude Code (laut Angabe Version 2.1.232) haben die Situation verändert, daher sollten Sie die aktuellen Release-Notes prüfen, um das genaue Verhalten zu erfahren.

Subagenten-Forking. Der große Wandel liegt in der Art und Weise, wie ein Technologieleiter und seine ICs miteinander umgehen. Ohne Forking als Standard begann ein neu erstellter Subagent mit nichts: kein Gedächtnis an die Diskussion hinter der Aufgabe, kein gemeinsamer Prompt-Cache. Jeder IC benötigte eine vollständige Einweisung, was bedeutete, entweder jeden Aufgabenprompt mit Hintergrundinformationen zu füllen oder Fragen zu tolerieren, die der Leiter bereits Minuten zuvor geklärt hatte. Bei 5 bis 10 ICs in neun Projekten wird das schnell unerträglich.

Fordern Sie subagent_type: „fork“ an – der neue Subagent erhält dann das gesamte Gespräch sowie den Prompt-Cache seines Erstellers. Ein Technikleiter, der seit zwanzig Minuten über eine schwierige Migration nachdenkt, kann einen IC erstellen, der bereits alle diese Überlegungen enthält, ohne dafür erneut bezahlen oder sie erneut erklären zu müssen. Forks laufen standardmäßig im Hintergrund und halten ihre Tool-Ausgaben außerhalb des Kontexts des Elternteils, sodass der Technikleiter ein endgültiges Ergebnis erhält und nicht nur einen Strom an Informationen aus der Dateiabfrage.

Es gibt Grenzen. Eine Überwrite des Modells wird bei einem Fork ignoriert, da dieser immer mit dem Modell des Elternteils ausgeführt wird; daher kann ein technischer Leiter, der Sonnet verwendet, nicht in ein IC mit einem günstigeren Modell forken. Zudem deaktiviert die Einstellung CLAUDE_CODE_FORK_SUBAGENT=0 dieses Verhalten vollständig. Die Einrichtung setzt das Forken überall fort – außer im IC der Migrationsskripte, wo absichtlich jedes Mal ein völlig sauberer Kontext gewünscht wird.

Über-Sitzungs-Kommunikation mit @-Erwähnung. Dadurch können lead-alpha, lead-beta sowie die neun Tech-Lead- und PM-Paare unter ihnen in separaten, live stattfindenden Sitzungen miteinander kommunizieren, anstatt Teil eines einzigen großen Kontextfensters zu sein. Durch Eingabe von @ und dem Namen einer Sitzung in eine Anfrage wird direkt eine andere live laufende Claude Code-Sitzung angesprochen, wobei im Hintergrund die Funktion SendMessage aufgerufen wird. Genau das macht die Kommunikation zwischen den beiden Leitern überhaupt möglich. Die beiden Leiter sind tatsächlich separate Prozesse mit eigenem Speicher, und sie erreichen einander auf dieselbe Weise wie ein Mensch – durch benannte Nachrichten und nicht über eine gemeinsame Datenbank, die erst erstellt werden müsste.

/config enthält Einstellungen für die Ablaufzeit von Dialogen sowie dafür, wie eine Sitzung mit eingehenden Nachrichten aus anderen Sitzungen umgeht (akzeptieren, zurückhalten oder ablehnen). Bei Dutzenden aktiver Sitzungen ist diese Kontrolle sehr nützlich – schließlich möchte man nicht, dass der Projektmanager einen Kunden kontaktiert, während der eigene Technikleiter übergangen wird.

Es gibt hier nichts Exotisches, da beides heutzutage Standard ist. Der Unterschied besteht darin, dass diese Standards nun zuverlässig genug sind, um eine Überwachungshierarchie zu ermöglichen, während man früher eine Nachrichtenwarteschlange einrichten und darauf hoffen musste.

Fehlermöglichkeiten, denen es standhalten muss

Das Konzept mit zwei Technikleitern mit Herzfrequenzmessung entstand nicht aus Paranoia. Es resultiert aus der Lektüre der Forschung von Anthropic zu Mustern und Problemen in Mehr-Agentensystemen, die angeblich Mitte August veröffentlicht wurde, sowie aus der Erkennung früher Fehler in fast jeder von ihnen beschriebenen Kategorie.

Niedrigvarianzige Konformität. Laut der Forschung verhalten sich einzelne Agenten viel ähnlicher als eine Gruppe von Menschen, indem sie auf dieselbe Lösung, dieselben Namen und denselben Ansatz kommen, obwohl nichts sie dazu drängt. Berichtete Beispiele: 18 von 30 Agenten benannten jeweils einen Git-Branch „mvp-game-loop“; fiktive Agenten kamen ohne gemeinsame Anleitung zu denselben Titeln; über die Hälfte wählte einen Ray-Tracer oder einen selbst gehosteten Compiler als Highlight; sowie Polling-Agenten, die insgesamt 2,4 Millionen Jobanfragen erzeugten, da jeder dieselbe aggressive Polling-Frequenz gewählt hatte.

In dem ersten Monat dieser Umsetzung trat eine mildere Version auf. Drei IC-Mitarbeiter an drei verschiedenen Projekten, die voneinander nichts wussten, entschieden jeweils, dass die beste Lösung für einen ähnlich aussehenden Fehler ein Retry-Wrapper sei. Die drei Wrapper wiesen leicht unterschiedliches Verhalten bei der Wartezeit auf und kollidierten, als die Projekte später miteinander kommunizieren mussten. Die Abhilfe besteht darin, die Zuständigkeitsbereiche der IC-Mitarbeiter streng abzugrenzen und jede Entscheidung zwischen Projekten über einen Technikleiter laufen zu lassen, der ein Projekt überblickt, sowie gegebenenfalls über einen Leiter, der mehrere Projekte betrachtet. Niemand unterhalb des Niveaus des Technikleiters darf eine Entscheidung treffen, deren Gültigkeit über das jeweilige Ticket hinausgeht.

Koordinationsversagen bei voneinander abhängiger Arbeit. In einem im Forschungstext beschriebenen Experiment zur Spieleentwicklung wurden viele Pull Requests nie zusammengeführt, weil kollidierende Änderungen verworfen statt ausgeglichen wurden. Die Erkenntnis war nicht, ein stärkeres Modell zu wählen; die Agenten benötigten eine präzisere Beurteilung dafür, wann sie getrennt arbeiten und wann sie Änderungen zusammenführen sollten. Aus diesem Grund dürfen ICs möglicherweise nicht lateral mit ICs zu anderen Aufgaben kommunizieren. Alles wird über den Tech Lead geleitet, der alle laufenden Arbeiten überblickt und die Reihenfolge festlegt. Das kostet im Vergleich zu unbeschränktem Parallelismus an Geschwindigkeit, verhindert aber, dass zwei Agenten einen Dateiinhalt auf inkompatible Weise verändern.

Der Rasenkrieg. Das ist das Beunruhigendste. Der Artikel beschreibt drei Agenten mit wirklich widersprüchlichen Zielen, die schrittweise dazu übergingen, sich gegenseitig zu sabotieren: Sie deaktivierten Konten und starteten sich selbst replizierende Abbruchprozesse mit zufälligen Namen, um pkill -f zu umgehen. Nur das neueste getestete Modell beruhigte die Situation wieder und erreichte in 98 Prozent der Fälle einen Waffenstillstand, während frühere Modelle entweder zu Sperrungen oder offenen Konflikten führten. Hier liegt das sogenannte „Tail-Risk“, wenn Agenten echten Systemzugriff erhalten, ohne dass von außen überprüft wird, ob ihre Ziele miteinander kompatibel sind.

Die Lösung liegt hier in der Struktur und nicht in List. Kein Agent unterhalb des Technikleiters verfügt über Befugnisse, die über sein eigenes Projekt hinausgehen. Technikleiter haben keinen Zugriff auf die Produktionsumgebung, es sei denn, ein Leiter gibt seine Zustimmung. Die beiden Leiter existieren teilweise deshalb, damit, falls einer damit beginnt, Dinge zu genehmigen, die zu einer Spirale unvereinbarer Ziele führen könnten, der andere als unabhängige Kontrollinstanz fungiert und nicht als bloßer Formalitätsabwickler im selben Kontext.

Die Studie räumt ein, dass das Problem noch ungelöst ist. Mit anderen Worten: Koordination entsteht nicht einfach durch bessere Intelligenz oder durch die Abstimmung der einzelnen Agenten, und das Spannungsfeld zwischen dem Unbehindert-Lassen der Agenten und dem Erfordernis, dass sie anhalten und einen Menschen um Rat fragen, bleibt ungelöst. Eine Hierarchie lässt diese Fehlermöglichkeiten bestehen. Was sich ändert, ist der Ausmaß ihrer Auswirkungen sowie die Geschwindigkeit, mit der eine Person Probleme erkennen kann, bevor sie sich auf neun Projekte ausbreiten.

Was man übernehmen sollte, wenn man keine neun Projekte betreibt

Für einen Entwickler oder ein Team von zwei oder drei Personen lohnt es sich fast nicht, diese gesamte Hierarchie aufzubauen – und es wäre unehrlich, so zu tun, als wäre das anders.

Vermeiden Sie das Muster mit zwei Leitern. Es beantwortet die Frage: „Was passiert, wenn der Vorgesetzte mitten in der Nacht um 3 Uhr stirbt und niemand zuschaut?“ Ein einzelner Entwickler übernimmt diese Rolle. Eine Über Nacht abgestürzte Sitzung kann warten, bis man morgens sein Handy überprüft.

Vermeiden Sie die Projektmanager-Ebene. Das Erstellen von Tickets und die Verhandlung des Umfangs lohnen sich, wenn neun gleichzeitige Projekte um die Aufmerksamkeit einer Person konkurrieren. Bei nur einem oder zwei Projekten ist man selbst der Projektmanager – ein dedizierter Agent fügt lediglich einen zusätzlichen Übersetzungsschritt zwischen einem und der Arbeit hinzu.

Behalten Sie einen Technikleiter mit begrenzten ICs, die in einer einzigen Schicht zusammengefasst sind. Ein Agent ist für die Analyse und Überprüfung einer Arbeitsaufgabe verantwortlich und teilt sich in spezialisierte Unteragenten auf, die die eigentliche Arbeit erledigen, anstatt dass eine einzige umfangreiche Sitzung alles bewältigt. Selbst ohne Hierarchie lohnt es sich, diese Aufteilung anzuwenden: Der übernommene Kontext und der Cache ersparen es, jedes Mal, wenn man bei einer Unteraufgabe Hilfe benötigt, die Situation erneut zu erklären.

Beschränken Sie jeden untergeordneten Agenten auf einen eng definierten Teil des Systems. Laut Angaben verhinderte diese einzige Regel mehr frühe Probleme als jede Form der Prompt-Engineering-Technik.

Ein Skelett, das Sie kopieren können

Das ist die kleinste Version des Lead- und IC-Musters, die dennoch funktionsfähig ist. Sie enthält zwei Definitionen für Claude Code Agenten sowie einen kleinen, selbst gehosteten Koordinator, der weder eine gehostete Warteschlange noch einen Broker benötigt – nützlich, wenn man das Muster über einen einfachen Script ausführen möchte, beispielsweise um das Claude Agent SDK anzusteuern, anstatt über Live-Interaktions-Sitzungen mit @-Mentions zu kommunizieren.

Die native Claude Code-Version beginnt mit .claude/agents/tech-lead.md:

---
name: tech-lead
description: Owns decomposition and review for one project. Forks IC agents for individual tasks, reviews their diffs, escalates only genuine blockers.
tools: Read, Grep, Glob, Bash, Edit, Agent
---
You are the tech lead for this project. You do not write most of the code
yourself. When a task arrives:
1. Break it into the smallest pieces that can be verified independently.
2. For each piece, spawn a fork subagent scoped to exactly one piece:
   subagent_type: "fork", with a prompt naming the specific files or
   directory it may touch and nothing else.
3. Review every diff before it is considered done. Reject anything that
   touches files outside the scope you gave it.
4. Only message the lead session (via SendMessage / @-mention) if you are
   blocked on a decision you cannot make with the context you have, or if
   two of your own IC agents produced conflicting changes.
Never let two IC agents work on overlapping files in the same task cycle.

Und .claude/agents/ic-migration.md zeigt ein eng gefasstes IC:

---
name: ic-migration
description: Handles only database migration scripts under db/migrations/. Never touches application code.
tools: Read, Edit, Bash
---
You only read and write files under db/migrations/. If a task requires
changing anything outside that directory, stop and report back to whoever
assigned you the task instead of making the change yourself.
Write one migration per task. Run it against the local test database
before reporting done. Include the rollback in the same file.

Der Technikleiter erstellt eine Fork des IC mittels eines Task- oder Agent-Aufrufs, bei dem subagent_type: „fork“ angegeben wird sowie eine Anweisung für ein einzelnes Ticket. Da es sich um eine Fork handelt, enthält das IC bereits die Überlegungen des Technikleiters zu diesem Ticket und benötigt keine erneute Einweisung.

Der selbst gehostete Ansatz kommt dann zum Tragen, wenn man auf vollständige interaktive Sitzungen verzichtet und die Koordinierungslogik ausschließlich über die Anthropic API laufen lassen möchte: kein Broker, keine externe Warteschlange, nur eine Datei auf dem eigenen Datenträger.

# coordinator.py
# pip install anthropic --break-system-packages
# A local, file-backed mailbox so "agents" (just API calls) can hand
# work to each other without any hosted message broker.
import sqlite3
import json
import time
from anthropic import Anthropic
DB = "mailbox.db"
client = Anthropic()  # reads ANTHROPIC_API_KEY from env
def init_db():
    conn = sqlite3.connect(DB)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS messages (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            to_agent TEXT,
            from_agent TEXT,
            body TEXT,
            status TEXT DEFAULT 'pending',
            created_at REAL
        )
    """)
    conn.commit()
    conn.close()
def send(to_agent, from_agent, body):
    conn = sqlite3.connect(DB)
    conn.execute(
        "INSERT INTO messages (to_agent, from_agent, body, created_at) VALUES (?, ?, ?, ?)",
        (to_agent, from_agent, body, time.time()),
    )
    conn.commit()
    conn.close()
def next_message(to_agent):
    conn = sqlite3.connect(DB)
    row = conn.execute(
        "SELECT id, from_agent, body FROM messages WHERE to_agent=? AND status='pending' ORDER BY id LIMIT 1",
        (to_agent,),
    ).fetchone()
    if row:
        conn.execute("UPDATE messages SET status='taken' WHERE id=?", (row[0],))
        conn.commit()
    conn.close()
    return row
def run_ic(scope_dir, ticket_body):
    """One scoped worker call. No memory between calls by design here,
    since we're not using Claude Code's native forking in this path."""
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=2048,
        system=f"You may only reason about files under {scope_dir}. "
               f"If the ticket requires anything outside that scope, "
               f"say so and stop.",
        messages=[{"role": "user", "content": ticket_body}],
    )
    return response.content[0].text
if __name__ == "__main__":
    init_db()
    send(to_agent="ic-migration", from_agent="tech-lead", body="Add index on users.email")
    msg = next_message("ic-migration")
    if msg:
        _, sender, body = msg
        result = run_ic("db/migrations/", body)
        send(to_agent=sender, from_agent="ic-migration", body=result)
        print(result)

Es ist absichtlich einfach gehalten: Eine SQLite-Datei ersetzt die Nachrichtenwarteschlange und eine Python-Funktion fungiert als IC-Agent. Dennoch hat es die Struktur der Produktionsversion – mit einem begrenzten Worker, einer auf Nachrichten basierenden Übertragung anstelle eines gemeinsam genutzten, veränderbaren Zustands sowie ohne Abhängigkeiten von kostenpflichtigen Diensten. Wenn es nicht mehr ausreicht, ist der Wechsel zu Claudes Code-basierter Forking-Funktion sowie @-Mention konzeptionell derselbe Ablauf, wobei die technischen Details bereits für einen reibungslosen Betrieb erledigt sind.

Der aktuelle Stand

Alles ist noch nicht fertiggestellt. Es kommen weiterhin häufiger Eskalationen vor, und einige davon erweisen sich als echte Unklarheiten und keine Fehler in den Begrenzungsregeln. Die Forschung hat vermutlich recht: Echte Lösungen wie Reputationssysteme zwischen Agenten sowie ein angemessenes Mechanismusdesign anstelle einer ad hoc erstellten Hierarchie werden derzeit in der gesamten Branche weiterentwickelt.

Die eigene Beurteilung des Systems ist bescheiden. Der Ersatz einer umfangreichen, alles umfassenden Arbeitssession durch eine Hierarchie, die grob dem Vorgehen eines kleinen Ingenieurteams bei der Aufgabenzuweisung nachempfunden ist, soll die tägliche Anzahl der Anfragen halbiert haben. Zudem wurden die verbleibenden Fehler weniger verwirrend und leichter zu verstehen. Das ist ein angemessener Tausch.