27. Juli 2026
Multi-Agent-Orchestration: Der Engpass ist nie die Zahl der Agenten, sondern die Review-Kapazität
Wir haben unsere eigene Multi-Subagent-Konvention nach echten Merge-Konflikten verschärft. Was drei aktuelle Quellen und unsere Praxis über Grenzen paralleler KI-Agenten zeigen.
Mehr parallele KI-Agenten bedeuten nicht mehr Durchsatz. Sie verschieben den Engpass nur von der Code-Generierung zur Review — und die Review-Kapazität eines Menschen skaliert nicht mit. Das ist keine Binsenweisheit aus einem Marketing-Whitepaper, sondern eine Erkenntnis, die wir uns diesen Mai selbst eingehandelt haben: Zwei parallel arbeitende Subagents haben in einem unserer Repos denselben File-Bereich bearbeitet, unabhängig voneinander committet — und beim Merge einen semantischen Konflikt erzeugt, den keiner der beiden Agenten sehen konnte, weil er den anderen gar nicht kannte.
Die Konsequenz: eine verbindliche Worktree-Isolation-Konvention.
Seit dem 21. Mai 2026 gilt in unseren Repos: Sobald zwei oder mehr Subagents parallel arbeiten, bekommt jeder einen eigenen `git worktree`, eine explizite Base-Branch und eine disjunkte File-Ownership. Das Pflicht-Pattern ist denkbar simpel — `git fetch origin`, dann `git worktree add ../repo-{stream-slug} -b claude/session/feat/{stream-slug} origin/master` (oder `origin/main`, je nach Repo-Konvention) für jeden Stream. Der Punkt in Klammern ist kein Detail: In unserer eigenen Multi-Repo-Landschaft verwendet ein Teil der Projekte `master`, ein anderer `main` als Standard-Branch. Ein Agent, der die falsche Base zieht, baut auf einem veralteten Stand — und niemand merkt es, bis der Merge fehlschlägt. Vor jedem PR-Push läuft zusätzlich ein Smoke-Test-Gate (`npm run typecheck && npm run build`), das grün sein muss. Kein Agent pusht an einer roten Pipeline vorbei.
Das deckt sich mit dem, was aktuelle Praxisberichte unabhängig davon beschreiben.
Ein im April 2026 veröffentlichter Guide von Augment Code zu Git-Worktrees für parallele KI-Agenten beschreibt exakt denselben Mechanismus: Worktrees geben jedem Agenten ein vollständig isoliertes Filesystem, ohne das Repository zu duplizieren — sie verhindern Datei-Konflikte, Kontext-Kontamination und Lock-Contention, wenn mehrere Agenten gleichzeitig im selben Repository arbeiten. Der Guide nennt eine konkrete Grössenordnung: Mitte 2026 laufen Teams verlässlich mit vier bis acht parallelen Worktrees pro Entwickler — darüber hinaus wird man nicht mehr durch die Agenten gebremst, sondern durch die Review (Augment Code, «How to Use Git Worktrees for Parallel AI Agent Execution», augmentcode.com, 7. April 2026). Worktree-Isolation löst also ein technisches Problem — Datei- und Merge-Konflikte —, aber sie löst nicht das eigentliche Engpassproblem: Aufgabenzerlegung, Abhängigkeits-Tracking und wer am Ende entscheidet, welcher von mehreren parallelen Lösungsvorschlägen gemerged wird.
Warum Orchestrierung eine menschliche Grenze hat, nicht nur eine technische.
Addy Osmani beschreibt in «The Code Agent Orchestra» vom 26. März 2026, was produktive Entwickler von überforderten unterscheidet: Wer mehrere Agenten erfolgreich koordiniert, tut das asynchron — jeder Agent bekommt einen eigenen, klar abgegrenzten Verantwortungsbereich und meldet sich, wenn er fertig ist, statt dass der Mensch synchron mitläuft. Genau zwei Wochen später, am 7. April 2026, doppelt Osmani in «Your parallel Agent limit» nach — mit einer unbequemen Beobachtung: Die kognitive Bandbreite eines Menschen parallelisiert nicht. Der Agent generiert parallel, aber Bewerten, Entscheiden, Vertrauen und Integrieren bleiben einsträngig auf der menschlichen Seite. Osmani zitiert die Erfahrung, vier Agenten gleichzeitig laufen zu lassen und um 11 Uhr morgens bereits erschöpft zu sein — nicht weil die Agenten langsam waren, sondern weil jeder zusätzliche parallele Strang eine weitere Entscheidung erzeugt, die geroutet, gemerged und verifiziert werden muss. Osmani nennt das die «Orchestration Tax»: Man kann mehr Agenten beaufsichtigen, als man tief verstehen kann — aber Beaufsichtigung ohne Verständnis ist genau der Ort, an dem sich Comprehension Debt aufbaut.
Was das für KMU bedeutet, die Multi-Agent-Workflows einführen wollen.
Die verbreitete Planungslogik ist Kapazität in Agenten zu denken: „Wenn wir zehn Agenten parallel laufen lassen, erledigen wir zehnmal so viel Arbeit." Das ist der falsche Massstab. Die richtige Frage ist: Wie viel Review-Kapazität steht zur Verfügung, und wie verteilt sie sich über die parallelen Stränge? Drei Empfehlungen aus unserer eigenen Konvention und den zitierten Quellen lassen sich direkt übertragen:
- Disjunkte File-Ownership vor dem Start festlegen. Nicht hoffen, dass sich Agenten schon nicht in die Quere kommen — die Aufteilung explizit vorgeben, bevor der erste Agent startet.
- Eine explizite, dokumentierte Base-Branch pro Stream. Gerade in Multi-Repo-Umgebungen mit uneinheitlicher Branch-Konvention (`master` vs. `main`) ist das kein Nice-to-have, sondern die häufigste Fehlerquelle.
- Ein hartes Gate vor dem Merge. Typecheck und Build müssen grün sein, bevor ein Agent-Ergebnis überhaupt zur Review vorgelegt wird. Das filtert die Fälle heraus, in denen die menschliche Review-Zeit am wenigsten Wert hätte.
Was sich nicht direkt lösen lässt, ist die menschliche Grenze selbst. Wer plant, die Zahl paralleler Agenten von zwei auf acht zu erhöhen, sollte vorher planen, wer die zusätzliche Review-Last trägt — nicht nachher merken, dass es niemand tut.
Sind Multi-Agent-Systeme immer die bessere Wahl?
Nein. Die zitierten Quellen sind sich einig, dass Multi-Agent-Orchestration dort ansetzt, wo Aufgaben sich wirklich in unabhängige, parallelisierbare Teilstränge zerlegen lassen — getrennte Features, getrennte Dateibereiche, getrennte Test-Suiten. Wo Aufgaben stark voneinander abhängen oder denselben Codebereich berühren, produziert Parallelität mehr Koordinationsaufwand, als sie einspart. Der Trigger für Worktree-Isolation in unserer eigenen Konvention ist deshalb explizit an die Bedingung „2+ parallel arbeitende Subagents" geknüpft — für einen einzelnen Agenten braucht es diesen Overhead nicht.
Wie viele Agenten sollte ein Team parallel laufen lassen?
Nach den hier zitierten Quellen: so viele, wie disjunkte, unabhängig überprüfbare Arbeitsstränge existieren — und nicht mehr, als eine Person an einem Tag ehrlich review-mässig verkraften kann. Vier bis acht parallele Worktrees pro Entwickler sind die Grössenordnung, die Mitte 2026 in der Praxis genannt wird; der limitierende Faktor ist praktisch immer die Review, nicht die Infrastruktur.
Ersetzt Orchestration-Tooling die Code-Review?
Nein — und keine der drei zitierten Quellen behauptet das. Worktree-Isolation und Base-Branch-Disziplin verhindern technische Konflikte. Sie verhindern nicht, dass jemand inhaltlich prüfen muss, ob das, was ein Agent gebaut hat, tatsächlich richtig ist. Wer diesen Schritt überspringt, verlagert das Risiko nur von „Merge-Konflikt, sofort sichtbar" zu „falsches Verhalten in Production, spät sichtbar" — was strukturell schlimmer ist.
Wer eine Multi-Agent-Konvention für die eigene Entwicklungsumgebung aufsetzen will — inklusive Review-Kapazitätsplanung statt reiner Agenten-Zahl — begleiten wir das als Teil unserer Entwicklungs-Mandate: digital-opua.ch/kontakt.
Quellen
Addy Osmani: «The Code Agent Orchestra — what makes multi-agent coding work», addyosmani.com, 26. März 2026 — https://addyosmani.com/blog/code-agent-orchestra/ · Addy Osmani: «Your parallel Agent limit», addyosmani.com, 7. April 2026 — https://addyosmani.com/blog/cognitive-parallel-agents/ · Augment Code: «How to Use Git Worktrees for Parallel AI Agent Execution», augmentcode.com, 7. April 2026 — https://www.augmentcode.com/guides/git-worktrees-parallel-ai-agent-execution