Multi-Agent-Pipelines mit Claude Code: Ein Jahr Praxiserfahrung zeigt echte Kompromisse
Anthropic hatte Multi-Agent-Workflows beim Coding als Fehler bezeichnet. Eine langjährige Praxis mit solchen Pipelines zeigt: Der Aufwand fuer Uebergaben zwischen Agenten ist real, doch die klaren Zuständigkeitsgrenzen sind gerade der eigentliche Nutzen.
Signup Write New Story The Joining Tax: A Year of Governing Claude Code von Dmitriy Fedoryshchev von Dmitriy Fedoryshchev | @ fedoryshchev Lead Software Engineer bei Evercommerce Tech Lead bei einer am Nasdaq gelisteten SaaS-Gruppe. Teilt praktische Engineering-Erfahrungen und Entdeckungen.
Tech Lead bei einer am Nasdaq gelisteten SaaS-Gruppe. Teilt praktische Engineering-Erfahrungen und Entdeckungen.
Im Januar 2026 veröffentliche Anthropic eine Retrospektive über Multi-Agenten-Systeme, die das beschrieb, was ich seit einem Jahr betrieb, und es als Fehler bezeichnete. Ihr Wortlaut war ungefähr: Teams bauen ausgeklügelte Multi-Agenten-Systeme mit separaten Agenten für Planung, Ausführung, Review und Iteration, nur um festzustellen, dass sie bei jeder Übergabe Kontext verloren und mehr Tokens für Koordination als für Ausführung verbrauchten. Es ist dasselbe Unternehmen, dessen früherer Beitrag von einem Multi-Agenten-Setup berichtete, das einen einzelnen Agenten um 90 Prozent schlug, daher liest sich die Retrospektive wie ein Rückzieher.
Und ein Preprint vom April 2026 geht noch weiter: Hält man das Reasoning-Token-Budget konstant, erreicht ein einzelner Agent die Multi-Agenten-Setups oder schlägt sie, und er argumentiert, dass die berichteten Multi-Agenten-Erfolge größtenteils zusätzliche Berechnung waren, die niemand mitzählte.
Ich habe einen Lead, einen Business Analysten, einen Architekten, einen Entwickler, QA, zwei Reviewer, die gegensätzliche Positionen vertreten, und einen Doc-Updater. Sie laufen seit Mai 2025 gegen mein eigenes Produktionsprodukt, also habe ich die Steuer bezahlt, die diese Retrospektive beschreibt, jeden Monat. Und ich habe das Ganze trotzdem behalten. Die Kritik hat bei den Kosten recht, aber ich denke, sie liegt falsch darin, wofür diese Struktur da ist.
Eine Aufgabe geht an den Lead. Der Lead spricht mit dem Business Analysten, und die beiden erarbeiten aus geschäftlicher Sicht Fragen und Diskussionspunkte, bis der Plan stimmig ist. Dann geht es an den Architekten, wo dieselbe Schleife auf technischer Seite durchlaufen wird. Jeder Schritt hat einen Review-Begleiter, dessen einzige Aufgabe es ist, eine zweite Meinung zu vertreten, und die ständige Anweisung für alles, was in einer Review-Position sitzt, lautet: immer zweifeln, nie glauben, immer Fakten prüfen.
Dann folgt eine TDD-Phase. QA oder der Lead schreibt die Definition of Done als Testverhalten, ausgehend von den mit dem BA abgestimmten Use Cases, und der Entwickler arbeitet an diesen Unit-, Integrations- und End-to-End-Tests, bis sie grün sind. Wenn der Entwickler einen Test anfassen muss, um ihn grün zu bekommen, ist das ein Warnsignal, also greift der Lead ein, klärt, um welche Art von Problem es sich tatsächlich handelt, und zieht je nach Antwort den BA oder den Architekten hinzu.
Sobald der Entwickler Grün abzeichnet, geht es ins Review, mit etwas Hin und Her, bis auch das grün ist. Ich habe dort eine Zeit lang zwei Reviewer laufen lassen, einen, der alles refactorieren wollte, und einen, der keine einzige zusätzliche Zeile anfassen wollte, wobei der Architekt zwischen ihnen entschied. Dann kommt es zu mir, und nach meinem Review folgt das Testen. Wenn ich Feedback habe, protokolliert der Lead es, und es geht zurück an den Entwickler, oder der Lead kümmert sich darum, wenn es klein ist, oder ich mache es, wenn keiner von beiden klarkommt. Die Hauptaufgabe des Leads ist dann, die Issue-Liste zu verwalten, wobei ein Issue ein Code-Review-Fund, ein Bug oder alles ist, was die Definition of Done nicht klar erreicht.
Am Ende liest ein Doc-Updater die vom Lead geführte Dokumentenspur und härtert Docs und Skripte an, sodass die nächste Session von einem besseren Punkt startet. Ich hatte im Grunde spec-driven Development laufen, bevor es Mainstream wurde, und es ist ein schwerer Prozess, das zu behaupten wäre gelogen. Der Runner, der das macht, liegt auf GitHub als agentweft: Ein Flow ist eine Spec, eine Rolle ist eine Markdown-Datei, und die Ausgabe jedes Schritts wird festgehalten, sodass ein abgebrochener Lauf dort wieder aufgenommen werden kann, wo er hängen geblieben ist.
Zunächst einmal ist es teuer. Zwei Stunden davon verbrauchen ein volles Max-5x-Kontingent, an einem intensiven Tag schon in 90 Minuten, und Koordination ist darin ein echter Posten. Es ist auch an den Stellen langsam, an denen man keine Langsamkeit will.
Ein Feature kostete mich früher 3 oder 4 Tage Planung, dann 4 oder 5 Tage Review, die hauptsächlich darin bestanden, Müll zu retten, dann Testing. Das Tuning der Regeln und Beispiele über das Jahr hat das Review halbiert: Es sind jetzt 1 oder 2 Tage Deep Dive und Verifikation, weil es weniger zu retten gibt. Die Planung dauert weiterhin etwa 2 Tage, schneller vor allem, weil die Beispiele, die häufigen Fragen und die üblichen Ansätze schriftlich festgehalten sind und ich sie nicht wiederholen muss.
Und Testing plus Bugfixing sind weitere 1 oder 2 Tage, die immer da waren und auch bleiben, weil ich die letzte Freigabe bin und dieser Teil nicht delegiert wird.
Es gab Phasen, in denen die Dokumentenspur selbst das Problem war. Ich hatte Decision-Track-Dateien mit 2k, 3k, 5k Zeilen laufen, einige mit 10k, und musste sie aufteilen und durchiterieren. Manche schlechten Features hinterließen ein Dutzend Dateien mit jeweils 2k oder 3k Zeilen, alles Notizen darüber, was zu fixen sei. Ich wusste, während ich es tat, dass das falsch war; das Tool hat sich falsch verhalten, und ich reagiert darauf, indem ich mehr schrieb. Diese Phase brachte mir schließlich bei, das Werkzeug als Werkzeug zu behandeln und nicht als Menschen.
Und der ehrliche Punkt: Dieser Workflow ist ziemlich Meinungsstark. Ich setze viel auf Planung und viel auf Review, und er funktioniert so, wie ich schon vor KI gearbeitet habe, also ist er in erster Linie mein Begleiter, und was auf dein Setup übertragbar ist, ist wahrscheinlich nicht die exakte Konfiguration.
Ich habe ihn behalten, weil die Rollen zwei mechanische Aufgaben erledigen, und ein einzelner langlebiger Agent kann keine von beiden für sich selbst erledigen.
Die erste ist ein begrenzter Kontext pro Arbeitseinheit. Die Befolgung von Anweisungen verfällt innerhalb einer Session, während der Agent Code generiert, in der Größenordnung von wenigen Prozent Wahrscheinlichkeit pro Funktion in der einen kontrollierten Studie, die ich gefunden habe und die das misst. Eine kleine Arbeitseinheit mit frischem Kontext hat also weniger Spielraum zum Abdriften.
Das ist ungefähr das, was eine Rollengrenze einbringt. Der Architekt denkt wie alles andere auch, aber er startet sauber und ist fertig, bevor er abdriftet. Es gibt auch ein peer-reviewed Paper von der ACL 2025, das mich darin etwas sicherer machte als meine eigene Erfahrung.
Der interessante Teil ist ein Test, den die Autoren an ihrem eigenen System durchführten, indem sie jeweils einen Teil abschalteten: Der Gewinn kam daher, dem Agenten die früheren Schritte zu verbergen, nicht aus der Aufteilung der Arbeit.
Die zweite ist der Write-Scope. Reads bleiben völlig offen, und ich setze mich dafür ein, ich will, dass Agenten alles durchsuchen und untersuchen. Aber Writes sind nach Rollen partitioniert, was in agentweft ein Tool-Scope ist, der am Schritt deklariert wird, und QA ist der Grund: Die Architekturdocs und die Definition of Done sind für seine Writes gesperrt, da es derselbe Fehlertyp ist wie ein Entwickler, der einen Test bearbeitet, bis er grün ist. Sie versuchten, kürzeste Wege zu finden, und versuchten, die Anforderung zu betrügen.
Ein einzelner Agent kann dir das nicht geben, weil es keine Grenze gibt, die er gegen sich selbst durchsetzen könnte. Funktionstrennung ist hundert Jahre älter als all das, und sie existiert aus demselben Grund. Wenn ich also lese, dass Multi-Agenten-Systeme bei jeder Übergabe Kontext verlieren und mehr für Koordination als für Ausführung ausgeben, widerspreche ich nicht; die Übergabe ist kein Bug im Design, sie ist der Preis der Grenze, und die Grenze ist der gesamte Grund, warum diese Rollen existieren.
Arbeit auf Spezialisten aufzuteilen ist kein neues Problem. Wenn Frontend und Backend in einem Team getrennt leben, bekommt man auf jeder Seite klarere Verantwortlichkeit und zahlt dafür an der Nahtstelle. Diese Joining Tax ist real genug, dass ich jahrelang versucht habe, sie in Teams zu vermeiden. Teilt man seine Agenten nach Rollen auf, ist es dieselbe Steuer aus demselben Grund: Das ursprüngliche Problem der Kontextverengung wird gelöst, aber die Kosten verschieben sich woandershin, und das Endziel ist nicht viel näher. Die Arbeit besteht also darin, die Nahtstelle billig zu machen, und fünf Dinge haben den Großteil davon für mich erledigt.
Das erste war die Deckelung der Debatte. Jeder Reviewer bekommt 2 Runden Feedback, das ursprüngliche Review plus Klärung, und der Architekt kann auf 3 Zyklen erweitern, wenn er wirklich mehr Diskussion will; der Entwickler bekommt 2 oder 3 Iterationen, bevor etwas an mich eskaliert, mit einem harten Limit von 5. Ohne diese Limits diskutieren die Reviewer so lange, wie die Tokens reichen, weshalb agentweft sie in der Flow-Spec mitführt: Der Reviewer schickt Arbeit höchstens zweimal zurück, und dann muss er sich ansehen, was zurückkam.
Das zweite war, jeder Rolle eine Prioritätenordnung zu geben, nicht nur, was sie tut, sondern was sie priorisieren soll, wo sie eigenständig entscheiden darf, und in welcher Reihenfolge. Ein Großteil der Schiedsentscheidungen, die ich früher von Hand machte, war ich, der eine Prioritätenliste im Kopf hielt, von der niemand sonst eine Kopie hatte, und sie pro Rolle aufzuschreiben ließ einen Großteil der Pipeline ohne mich laufen.
Das dritte war, die Übergabe strukturiert zu gestalten, sodass ein Ergebnis und ein Urteil die Grenze überqueren statt einer Wand eingefügter Texte, die die nächste Rolle erneut lesen und interpretieren muss. Und das vierte war, einen einzigen Owner für die Issue-Liste zu behalten: 10 Review-Iterationen und leicht 100 Funde pro Feature sind bei mir ziemlich normal. Ohne eine einzige Rolle, der diese Liste gehört, bekommt man den 10k-Zeilen-Decision-Track, denn genau dort landet eine herrenlose Issue-Liste.
Das Fünfte war das Schließen der Schleife am Ende. Der Doc-Updater existiert dafür, dass die Erkenntnisse eines Durchlaufs in Dokumentation und Skripte übergehen, bevor der nächste beginnt, und das ist der einzige Grund, weshalb der Regeln-Korpus im Laufe des Jahres geschrumpft statt gewachsen ist; er liegt heute bei etwa einem Fünftel seiner früheren Größe. Die Probleme wiederholten sich mit der Zeit, und ein sich wiederholendes Problem ist eines, das ein Skript übernehmen kann; in agentweft sind das Gates, ein Regex oder ein Befehl, der entweder bestanden wurde oder nicht, und der Ablauf übergibt dieselben Zusicherungen an die Rolle, die die Arbeit ausführt, und an das Gate, das sie prüft.
Wenn ich bereits weiß, welche Dateien sich ändern und wie, dann hat der gesamte Apparat einen negativen Wert. Ein einzelner Agent mit einer einzelnen Aufgabe erledigt das besser, ohne das ganze Hin und Her. Der Schnittpunkt liegt ungefähr dort, wo eine Aufgabe nicht mehr in einen Kopf passt: Wenn ein einzelner Agent zwanzig- oder fünfzigmal komprimieren, seinen eigenen Kontext zusammenfassen und weitermachen müsste, um etwas abzuschließen, kommt er am Ende an und hat den Anfang stillschweigend vergessen. Ab diesem Punkt wird es billiger, die Beitrittssteuer zu zahlen, als für das zu zahlen, was der Agent vergisst. Und je größer der Umfang, desto besser wird der Deal, was irgendwie das Gegenteil dessen ist, was man aufgrund des Koordinationsaufwands erwarten würde.
Wenn ich es heute neu aufbauen würde, würde ich die Schreibpartitionierung, die Tests als Definition of Done, die Limits und die Doc-Updater-Schleife beibehalten. Aber ich würde genauer darüber nachdenken, wie viele Rollen existieren müssen, denn einige meiner sind nur aus Symmetrie mit der Organisation menschlicher Teams da, und Symmetrie mit einem menschlichen Team ist kein technisches Argument. Diesen Teil der Kritik muss ich mir gefallen lassen.
Ich lese weiterhin jede Zeile, die dabei herauskommt, und ich erwarte, dass ich das auch weiter tun werde. Aber der Grund, warum ich die Struktur verteidigen werde, nach einem Jahr und gegenüber Menschen mit besseren Daten als meinen, ist, dass die Alternative kein billigeres System ist. Es kostet dasselbe, und es findet an einem Ort statt, den ich nicht sehen kann.
Die Demotion Ladder: Ein Jahr lang Claude Code regieren
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Signup Write New Story The Joining Tax: A Year of Governing Claude Code by Dmitriy Fedoryshchev by Dmitriy Fedoryshchev | @ fedoryshchev Lead Software Engineer at Evercommerce Tech Lead at a Nasdaq-listed SaaS group. Sharing practical engineering lessons and discoveries.
Tech Lead at a Nasdaq-listed SaaS group. Sharing practical engineering lessons and discoveries.
In January 2026 Anthropic published a retrospective on multi-agent systems that described what I'd been running for a year, and described it as the mistake. Their wording, near enough: teams build elaborate multi-agent systems with separate agents for planning, execution, review and iteration, only to discover that they suffered from lost context at each handoff and spent more tokens coordinating than executing. This is the same company whose earlier post reported a multi-agent setup beating a single agent by 90%, so the retrospective reads as a walk-back.
And an April 2026 preprint goes further still: hold the reasoning-token budget constant and a single agent matches or beats the multi-agent setups, and it argues the reported multi-agent wins were mostly extra computation nobody was counting.
I have a lead, a business analyst, an architect, a developer, QA, two reviewers who argue opposite positions, and a doc updater. They've been running against my own production product since May 2025, so I've paid the tax that retrospective describes, every month. And I kept the thing anyway. The criticism is right about the cost, but I think it's wrong about what the structure is for.
A task goes to the lead. The lead talks to the business analyst, and the two of them work up questions and discussion items from the business side until the plan is sound. Then it goes to the architect, where the same loop runs again on the technical side. Each step has a review companion whose only job is holding a second opinion, and the standing instruction for anything in a review seat is: always doubt, never believe, always fact-check.
Then a TDD phase. QA or the lead writes the definition of done as test behaviour, from the use cases agreed with the BA, and the developer works against those unit, integration and end-to-end tests until they're green. If the developer needs to touch a test to make it green that's a red flag, so the lead steps in, sorts out what kind of problem it actually is, and consults the BA or the architect depending on the answer.
Once the developer signs off on green it goes to review, with a bit of back and forth until that's green too. I ran two reviewers there for a while, one arguing refactor everything and one arguing don't touch a single extra line, with the architect judging between them. Then it comes to me, and after my review, testing. If I have feedback the lead logs it and it goes back to the developer, or the lead handles it if it's small, or I do it if neither of them can cope. The lead's main job by then is owning the issue list, where an issue means a code review finding or a bug or anything that isn't clearly reaching the definition of done.
At the end a doc updater reads the paper trail the lead kept and hardens the docs and the scripts, so the next session starts from a better place. I basically had spec-driven development running before it was mainstream, and it's a heavy process, not worth pretending otherwise. The runner that does it is on GitHub as agentweft: a flow is a spec, a role is a markdown file, and every step's output is written down so a run that dies can be picked up where it fell over.
It's expensive, first of all. Two hours of this drains a full Max 5x quota, on a heavy day just in 90 minutes, and coordination is a real line item inside that. It's also slow in the places you don't want slow.
A feature used to cost me 3 or 4 days of planning, then 4 or 5 days of review that was mostly rescuing slop, then testing. Tuning the rules and the examples over the year is what halved the review: it's 1 or 2 days of deep dive and verification now, because there's less to rescue. Planning is still about 2 days, faster mostly because the examples, the common questions and the common approaches are written down and I don't spell them out again.
And testing plus bug-fixing is another 1 or 2 days that was always there and stays there, because I'm the final sign-off and that part doesn't get delegated.
There were stretches where the paper trail itself was the problem. I had decision-track files running 2k, 3k, 5k lines, a few that hit 10k, and I'd have to split them and iterate over them. Some bad features left behind a dozen files of 2k or 3k lines each, all notes about what to fix. I knew that was wrong while I was doing it; the tool was misbehaving and I was responding by writing more. That stretch eventually taught me to treat the tool as a tool and not a human being.
And the honest one: this workflow is pretty opinionated. I'm heavy on planning and heavy on review, and it works the way I already worked without AI, so it's my companion first of all, and whatever transfers to your setup is probably not the exact configuration.
I kept it because the roles do two mechanical jobs, and a single long-running agent can't do either of them for itself.
The first is a bounded context per unit of work. Instruction compliance decays inside a session as the agent generates code, on the order of a few percent of odds per function in the one controlled study I've found that measures it. So a small unit of work with a fresh context has less room to drift. That's roughly what a role boundary buys. The architect thinks like anything else would, but it starts clean and it's done before it drifts. There's also a peer-reviewed paper from ACL in 2025 that made me a bit more confident about this than my own experience did. The interesting bit is a test the authors ran on their own system, switching off one part of it at a time: the gain came from hiding the earlier steps from the agent, not from splitting the work up.
The second is write scope. Reads stay wide open and I push for that, I want agents grepping and investigating anything. But writes are partitioned by role, which in agentweft is a tool scope declared on the step, and QA is the reason: the architecture docs and the definition of done are closed to its writes, since that's the same failure as a developer editing a test until it goes green. They were trying to find shortest paths and they were trying to cheat the request.
A single agent can't give you that, because there's no boundary for it to enforce against itself. Separation of duties is a hundred years older than any of this, and it exists for the same reason. So when I read that multi-agent systems lose context at every handoff and spend more on coordination than execution, I don't disagree; the handoff isn't a bug in the design, it's the price of the boundary, and the boundary is the whole reason those roles exist.
Splitting work across specialists is not a new problem. When frontend and backend live separately on a team you get cleaner ownership on each side and you pay for it at the join. That joining tax is real enough that I spent years trying to avoid it in teams. Split your agents by role and it's the same tax for the same reason: the original context-narrowing problem gets solved, but the cost moves elsewhere and the final goal isn't much closer. So the work is in making the seam cheap, and five things did most of that for me.
The first was capping the debate. Each reviewer gets 2 rounds of feedback, the original review plus clarification, and the architect can extend to 3 cycles if it genuinely wants more argument; the developer gets 2 or 3 iterations before anything escalates to me, with a hard cap of 5. Without the caps the reviewers will argue for as long as the tokens last, which is why agentweft carries them in the flow spec: the reviewer sends work back twice at most, and then it has to look at what came back.
The second was giving every role a priority order, not only what it does, but what it should prioritise, where it's allowed to decide on its own, and in what order. Most of the arbitration I used to do by hand was me holding a priority list in my head that nobody else had a copy of, and writing it down per role let a lot of the pipeline run without me.
The third was making the handoff structured, so a result and a verdict cross the boundary instead of a wall of pasted text the next role has to re-read and reinterpret. And the fourth was keeping one owner for the issue list: 10 review iterations and easily 100 findings across a feature is fairly normal for me. Without a single role owning that list you get the 10k-line decision track, because that's where an unowned issue list ends up.
The fifth was closing the loop at the end. The doc updater exists so the lessons from this run turn into docs and scripts before the next one starts, and that's the only reason the rules corpus shrank over the year instead of growing; it sits at about a fifth of its old size now. The issues got repetitive over time, and a repetitive issue is one a script can take over; in agentweft those are gates, a regex or a command that either passed or didn't, and the flow hands the same promises to the role doing the work and the gate checking it.
If I already know which files change and how, the whole apparatus is negative value. A single agent with a single task does it better without all the back and forth. The crossover sits roughly where a task stops fitting in one head: if a single agent would have to compact, summarise its own context and carry on, 20 or 50 times to finish something, it arrives at the end having quietly forgotten the beginning. At that point paying the joining tax gets cheaper than paying for what the agent forgets. And the bigger the scope, the better the trade gets, which is kind of the opposite of what you'd guess from the coordination overhead.
If I rebuilt it today I'd keep the write partitioning, the tests as definition of done, the caps and the doc-updater loop. But I'd think harder about how many roles need to exist, because some of mine are there for symmetry with how human teams are organised, and symmetry with a human team is not a technical argument. That part of the criticism lands on me.
I still read every line that comes out of it, and I expect to keep doing that. But the reason I'll defend the shape, after a year and against people with better data than mine, is that the alternative isn't a cheaper system. It's the same cost, and it sits somewhere I can't see it.
The Demotion Ladder: A Year of Governing Claude Code