Stell dir vor, du steckst mitten in einer großen Refactoring-Session. Vier KI-Agenten sind parallel am Werk, die Ergebnisse trudeln in unterschiedlicher Reihenfolge ein, und plötzlich fühlt sich der gesamte Workflow schwerer an als der Code, den du eigentlich ändern wolltest. Das ist einem Entwickler kürzlich bei der Arbeit mit einem Multi-Agent-System passiert. Er stoppte die Arbeit und bat den Orchestrator – die zentrale Instanz, die die Subagenten koordiniert – um eine ehrliche Analyse seiner eigenen Delegationsentscheidung. Die Antwort überraschte ihn. Das größte Problem war nicht die Anzahl der Agenten, sondern etwas, das er vorher nicht auf dem Radar hatte.
Der Entwickler arbeitete an einer .NET-Codebasis mit Claude Code. Vier Subagenten waren gestartet, um verschiedene Teile der Response-Pipeline umzubauen. Drei Agenten hatten klare Laufzeiten: etwa zwölf Minuten, fünfeinhalb Minuten und sieben Minuten. Ein vierter lief noch. Aus Sicht der reinen Parallelität war das ein Gewinn: Statt geschätzt 25 Minuten bei serieller Ausführung waren nur etwa 12 Minuten vergangen. Aber Geschwindigkeit war nicht der interessante Teil. Der Entwickler suchte nach den versteckten Kosten.
Seine erste Vermutung war die übliche: Jeder Subagent muss die gleiche Codebasis neu verstehen, Kontext aufbauen, Dateien lesen – die Duplizierung der Einarbeitung. Doch die größte Überraschung kam woanders. An einem Punkt während der Session schlug der Orchestrator vor, den Status der laufenden Agenten zu prüfen. Der Prompt war harmlos: „check on the agents.“ Der Entwickler folgte ihm. Statt einer kurzen Zusammenfassung zog das verwendete Tool das vollständige Rohprotokoll eines Hintergrundagenten in den Hauptthread – Zehntausende von Tokens voller JSONL, Zwischenschritten und Tool-Output. Und das passierte ein zweites Mal. Er hatte eine Kostenart entdeckt, die er nicht gesucht hatte: das teure Abfragen von Statusinformationen, die weit über das Nötige hinausgingen.
Wichtig ist hier eine Einschränkung: Die Behauptung, dass dieses Polling teurer war als die Duplizierungskosten durch vier Agenten, stammt vom Orchestrator selbst – als Selbsteinschätzung. Der Entwickler hatte keine exakte Token-Abrechnung pro Aufruf. Der verlässliche Teil ist enger: Die Transkript-Dumps waren real, die Zeitmessungen real, und der Pfad der Statusabfrage führte eindeutig zu großen, vermeidbaren Kosten. Ob es der größte Einzelposten war, bleibt eine Hypothese, bis die Tooling das genau messen kann. Wichtiger war, dass er einen Kostentreiber gefunden hatte, den er gar nicht gesucht hatte.
Als der Entwickler die Session nicht mehr als einen undifferenzierten „Subagenten-Kostenblock“ betrachtete, zerfiel das Bild in Teile, die nicht zusammengehörten. Zwei der vier Agenten arbeiteten im selben Bereich der Response-Pipeline. Unterschiedliche Aufgaben, unterschiedliche Dateien – aber beide mussten dieselbe Architektur, dieselben Testkonventionen und weite Teile des umgebenden Codes verstehen, bevor sie beginnen konnten. Jeder zahlte diese Orientierungskosten unabhängig. Das ist kein Argument gegen Delegation, sondern dafür, dass die Arbeit zu fein aufgeteilt wurde. Ein anderer Agent führte git stash und git stash pop aus, während Schwesteragenten im selben Baum schrieben. Nichts brach, aber das Risiko war strukturell, weil repository-weite Operationen in einer Single-Thread-Session völlig in Ordnung sind, aber bei mehreren Schreibern kaum zu rechtfertigen sind.
Der Entwickler stand nun vor einer Liste von Übeltätern: Status-Polling, doppelte Orientierung, unsichere Git-Operationen. Er versuchte, sie nach Kosten zu ordnen. Je länger er das tat, desto weniger überzeugte ihn die Frage, welcher Posten am teuersten war. Das eigentliche Problem lag tiefer.
Das Transkript-Polling beschäftigte ihn aus einem Grund, der nichts mit Token-Kosten zu tun hatte. Eine Token-Rechnung ist einmalig – bezahlt und erledigt. Was hier passierte, war anders. Das rohe Transkript blieb nach dem Tool-Aufruf im Kontext des Orchestrators und wurde bei jeder weiteren Runde mitgeschleppt, unabhängig davon, ob es noch nützlich war. In diesem Moment wurde ihm klar, dass er zwei sehr unterschiedliche Kostenarten gleich behandelt hatte. Tokens werden einmal ausgegeben. Kontext hingegen formt jede folgende Entscheidung. Es ging nicht mehr nur um Token-Verbrauch, sondern um die Qualität des Arbeitsgedächtnisses des Orchestrators.
Diese Erkenntnis trug zwei separate Ideen in sich, die es wert sind, auseinandergehalten zu werden. Die erste ist die gerade beschriebene: Verschmutzung im Kontext belastet jede spätere Runde. Die zweite handelt nicht von Platzmangel. Je mehr im Kontext liegt und um Aufmerksamkeit konkurriert, desto schwerer fällt es einem Modell, das Wesentliche herauszufiltern – selbst wenn noch viel Platz frei ist. Ein größeres Kontextfenster behebt das nicht. Es gibt dem Rauschen nur mehr Raum, sich anzuhäufen, bevor es auffällt. Kontextfenster werden nur noch größer werden. Was zählt, ist nicht, wie viel Platz vorhanden ist, sondern wie viel von dem, was dort liegt, die Aufmerksamkeit des Modells verdient. Das ist das eigentliche Problem, das Subagenten lösen müssen – wenn sie richtig eingesetzt werden.
Aus dieser Perspektive ist der Orchestrator der einzige Teil des Systems, der über eine lange Session hinweg Verständnis aufbaut. Er erinnert sich, warum eine Designentscheidung getroffen wurde, trägt architektonische Randbedingungen mit sich und weiß, welche Trade-offs bereits diskutiert wurden. Die Subagenten tun das nicht – und das ist Absicht. Sie sollen wegwerfbar sein. Erkundung, wiederholtes Dateilesen, gescheiterte Ansätze und lautes Zwischenreasoning sollen in den Worker-Kontexten bleiben und niemals den Weg zurück in den Hauptthread finden.
Diese Erkenntnis verändert, wofür Parallelität eigentlich gut ist. Das Problem der doppelten Orientierung war nicht wirklich, dass zwei Agenten dieselben Dateien lasen. Es war, dass zwei Agenten unabhängig voneinander dasselbe mentale Modell der Codebasis rekonstruierten, weil die Arbeit nach Aufgaben aufgeteilt war und nicht nach dem Wissen, das jede Aufgabe benötigte. Der Entwickler nennt diese Unterscheidung kognitive Lokalität: Aufgaben, die dasselbe mentale Modell benötigen, sollten normalerweise zusammenbleiben. Sie aufzuteilen zwingt mehrere Agenten, dasselbe Verständnis von Grund auf neu aufzubauen. Parallelität ist weiterhin nützlich, aber nicht der Hauptpunkt. Vier Agenten gleichzeitig laufen zu lassen ist gewöhnlich. Der wahre Vorteil ist, dass sie lautes Zwischenreasoning aus dem Hauptthread fernhalten und nur das zurückgeben, was er noch braucht. Das ist die Isolation, die Subagenten bieten sollen – und sie gilt nur, wenn der Hauptthread sie respektiert.
Der Entwickler ist heute überzeugt: Das ist die eigentliche Aufgabe von Subagenten. Nicht Zeit zu sparen, sondern Reasoning auszulagern, das der Orchestrator nicht behalten muss. So trägt er weniger und hat weniger Konkurrenz um seine Aufmerksamkeit. Wenn die Isolation stimmt und die Aufgaben nach kognitiver Lokalität gruppiert sind, werden Subagenten zum Werkzeug, das das Arbeitsgedächtnis des Orchestrators schützt – nicht nur ein Kostenfaktor, den man für Parallelität in Kauf nimmt. Das ist eine Überzeugung, keine Messung. Was er tatsächlich gemessen hat, ist die andere Seite: die Kosten, wenn die Isolation falsch läuft.
Sein nächster Schritt war naheliegend: Die Lektion in CLAUDE.md codieren, der festen Anweisungsdatei, die jede Session lädt. Es wäre einfach gewesen, eine große Korrekturpolitik zu schreiben, aber jede zusätzliche Zeile in einer solchen Datei ist ein Kostenfaktor, der bei jeder zukünftigen Session erneut anfällt. Also komprimierte er die Lösung auf den kleinsten Satz von Regeln, die die beobachteten Fehler adressierten. Jede Regel beantwortet dieselbe Frage: Verdient diese Information oder diese Art der Aufgabenaufteilung einen Platz im Kontext des Orchestrators?
- Bevorzuge zwei bis vier Agenten in einer Welle. Wenn der Orchestrator fünf oder mehr möchte, soll er zuerst fragen, ob Aufgaben, die Dateien oder Konventionen teilen, zusammengelegt werden können.
- Poll nicht den Status von Hintergrundagenten, wenn die Antwort bereits aus dem Bekannten gegeben werden kann. Hole kein vollständiges Transkript für eine leichte Frage.
- Erlaube keine repository-weiten Git-Operationen innerhalb gleichzeitiger Agenten-Prompts.
- Behandle überlappende Dateibesitzer als Konsolidierungssignal, nicht als Aufforderung, mehr Agenten zu spawnen.
Keiner dieser Punkte sagt dem Orchestrator genau, was er in jedem Fall tun soll. Jeder gibt ihm etwas zum Prüfen oder zum Selbstbefragen, kein Skript. Keiner ist für sich genommen tief. Ihr einziger Wert ist, dass sie alle auf dasselbe Ziel ausgerichtet sind: wegwerfbares Reasoning wegwerfbar zu halten und Platz im Kontext des Orchestrators für das zu bewahren, was später in der Session noch gebraucht wird.
Eine spätere Session förderte eine andere Lücke zutage. Der Entwickler hatte den Orchestrator mit expliziten Skills für die gewünschte Arbeit gestartet – Codierungsanleitung in einem Fall, Designanleitung in einem anderen. Er nahm an, dass einmal im Hauptthread aktive Skills automatisch von gespawneten Subagenten übernommen würden. Tun sie nicht. Ein Subagent erbt keine Skills aus der Eltern-Session, es sei denn, der Orchestrator übergibt sie explizit. Sein erster Impuls war, ein Bestätigungs-Gate vor dem Spawnen einzubauen. Der Orchestrator sollte anhalten, auflisten, welche Agenten er starten will und welche Skills jeder laden soll, und auf Zustimmung warten. Er ist froh, diese Version nicht behalten zu haben. Sie löste das falsche Problem. Es gab keine Hinweise, dass schlechte Spawn-Pläne aus Mangel an Bestätigung durchrutschten. Er hatte eine fehlende Tatsache über Skill-Weitergabe entdeckt – eine andere Art von Lücke. Ein universelles Bestätigungs-Gate hätte jeder ähnlichen Session eine Runde hinzugefügt, und bald hätte er diese Prompts wahrscheinlich nur noch auf Autopilot bestätigt. An dem Punkt erkannte er, dass er nicht wirklich die Governance verbesserte – er fügte nur ein Ritual hinzu. Und es hätte das eigentliche Problem von vorher nicht abgefangen: der Orchestrator, der seinen eigenen Kontext verschmutzt.
Die schmalere Lösung hielt besser. Vor dem Spawnen legt der Orchestrator dar, welche aktiven Skills für die Aufgabe jedes Agenten relevant sind, und verweist den Subagenten auf die Skill-Datei, statt den gesamten Skill inline zu kopieren. Bestätigung ist nur oberhalb der Batch-Größenschwelle erforderlich, die bereits existiert, oder wenn Dateibesitzer unklar sind. Daraus ergab sich eine Heuristik, die der Entwickler heute öfter verwendet als die Regel selbst: Bevor du eine Zeile zu einer festen Anweisungsdatei hinzufügst, frage dich, ob ein vernünftig kompetenter Orchestrator die richtige Entscheidung treffen würde, sobald er die eine fehlende Tatsache kennt. Wenn ja, sollte die Regel nur die Tatsache nennen. Wenn die Lösung beginnt, einen Entscheidungsprozess zu spezifizieren – Genehmigungen, Checkpoints, Pflichtschritte – ist das meist ein Zeichen, dass man Prozess codiert, wo eine kleine Klarstellung gereicht hätte. Ob diese Heuristik härteren Fällen standhält, weiß er noch nicht. Aber sie hindert ihn bisher daran, jeden interessanten Vorfall in eine Miniatur-Bürokratie zu verwandeln.
Am Ende dieser Analyse hat der Entwickler keine endgültige Antwort darauf, wie viel Governance genug ist. Stattdessen hat er ein kleines Schwungrad, mit einem Menschen noch fest in der Mitte. Eine Session legt eine Lücke offen. Jemand muss sie bemerken. Dann kommt die Entscheidung: Lässt sich die Lücke durch eine kleine Tatsache schließen, oder verlangt sie nach einem umfassenderen Prozess? Das ist die Steuer des Orchestrators – kein festes Gesetz, sondern ein ständiges Abwägen zwischen klarem Denken und bürokratischer Last. Und genau diese Abwägung macht den Unterschied zwischen einem System, das dich unterstützt, und einem, das dich ausbremst.
Quelle: martinfowler.com
