Agenten-Teams: mehr Tempo, selten mehr Qualität

Jedes Coding-Werkzeug hat inzwischen eine Antwort auf die Frage, wie man mehr als einen Agenten gleichzeitig arbeiten lässt. Claude Code kennt Subagenten, Agent Teams und Dynamic Workflows, Cursor plant große Vorhaben mit einem Koordinator und vielen Workern. Die Erzählung dahinter ist immer dieselbe: mehr Agenten, mehr geschafft.

Die Zahlen, die es dazu gibt, erzählen etwas anderes. Mehr Agenten machen die Arbeit oft schneller und fast immer teurer. Besser wird das Ergebnis nur unter bestimmten Bedingungen. Welche das sind, lässt sich inzwischen an Messungen und an ein paar gut dokumentierten Großprojekten ablesen.

Drei Dinge, die alle "Multi-Agent" heißen

Die Begriffe gehen durcheinander, deshalb vorweg die Trennung. Sie ist wichtiger, als sie aussieht, denn die drei Stufen kosten sehr unterschiedlich viel.

Die Zeile "Wo es läuft" räumt mit einem verbreiteten Missverständnis auf. Ein Agent Team in Claude Code ist kein Rechnerverbund. Es sind mehrere Claude-Code-Instanzen auf derselben Maschine, die sich über Dateien im Home-Verzeichnis Nachrichten schicken. Ihr gewinnt dadurch keine Rechenleistung, sondern eine andere Art der Abstimmung: Die Mitglieder können sich gegenseitig widersprechen, statt nur an einen Hauptagenten zu berichten.

Anthropic führt das Feature weiter als experimentell und liefert es abgeschaltet aus. Die Dokumentation empfiehlt selbst, erst die leichtere Variante zu prüfen, und nennt die Fälle, in denen ein Team nicht lohnt: "For sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective."

Was gemessen ist

Belastbare Vergleiche zwischen einem Agenten und mehreren gibt es wenige. Die fünf, die wir gefunden haben, ergeben zusammen ein Muster.

Vals AI, Oktober 2026. Vals hat auf seinem Vibe Code Bench 50 Web-Anwendungen aus Produktspezifikationen bauen lassen, einmal von einem Einzelagenten und einmal von einem Lead mit bis zu fünf Subagenten. Getestet wurden GPT-6 Sol und Claude Opus 5.5, jeweils mit mittlerem und maximalem Reasoning-Aufwand.

Die Tabelle zeigt, was das Team gegenüber dem Einzelagenten gebracht und gekostet hat. Der Einzelagent ist jeweils 1,0.

Im besten Fall kaufen 150 Prozent Mehrkosten also 9 Prozent mehr bestandene Tests, im teuersten Fall 410 Prozent Mehrkosten 4 Prozent. In absoluten Zahlen: GPT-6 Sol bestand allein 77,6 Prozent der Tests bei mittlerem und 89,0 Prozent bei maximalem Aufwand, im Team 84,9 und 90,4 Prozent. Opus 5.5 kam allein auf 91,5 und 89,8 Prozent, im Team auf 91,2 und 93,2.

Statistisch belastbar ist nur die erste Zeile. In den drei anderen liegt der Unterschied im Rauschen, bezahlt wurde trotzdem das Zwei- bis Fünffache. Vals nennt die Grenzen der Messung selbst: ein einziger Benchmark, jede Konfiguration lief genau einmal, und die beiden Modelle steckten in verschiedenen Harnesses. Ein Datenpunkt also, kein Urteil.

Google Research, DeepMind und MIT. Die Arbeit Towards a Science of Scaling Agent Systems ist breiter angelegt: 260 Konfigurationen, sechs Benchmarks, fünf Architekturen, drei Modellfamilien. Das Ergebnis ist eine Spanne von plus 80,8 Prozent bei gut zerlegbarem Finanz-Reasoning bis minus 70,0 Prozent bei Planungsaufgaben, in denen ein Schritt auf dem anderen aufbaut. Ob mehrere Agenten helfen oder schaden, hängt demnach an der Aufgabe und nicht an der Zahl der Agenten.

Anthropic, Juni 2025. Anthropic hat für sein Recherche-System berichtet, dass ein Lead mit Subagenten einen Einzelagenten in der hauseigenen Recherche-Auswertung um 90,2 Prozent schlug. Derselbe Text nennt den Preis, rund fünfzehnmal so viele Tokens wie ein Chat, und schränkt für unser Thema ein: "most coding tasks involve fewer truly parallelizable tasks than research". Die Zahlen stammen von der Modellgeneration des Vorjahres.

OpenAI, September 2026. Noam Brown hat im Dwarkesh Podcast beschrieben, was OpenAI intern sieht. Vier Agenten sind auf manchen Benchmarks doppelt so schnell fertig, und weiter: "you're paying 2x more to get an answer twice as quickly." Bei sechzehn Agenten setze sich das Muster fort, etwas weniger effizient. Das ist eine Auskunft des Herstellers und keine unabhängige Messung. Brown sagt auch offen, wo das Wissen endet: "we don't have very good science on multi-agent scaling up to this kind of scale."

Anthropic, August 2026. Das Frontier Red Team hat bei der Suche nach Sicherheitslücken zwei Arten von Parallelität verglichen, nämlich unabhängige Agenten nebeneinander und einen koordinierten Schwarm. Der Bericht nennt 21 Funde bei 6,5 Millionen Tokens gegen 266 Funde bei 27 Millionen. Das klingt nach einem klaren Sieg der Koordination, Anthropic relativiert es aber gleich selbst: Rund die Hälfte der Funde des Schwarms lag außerhalb der Kernverzeichnisse, auf die sich die unabhängigen Agenten beschränken sollten, und auf diese Verzeichnisse begrenzt sind beide Verfahren laut Bericht "comparable in terms of tokens per vulnerability found". Die Einzelheiten stehen in unserer News zu dem Bericht.

Recherche, Lückensuche und andere Aufgaben, die in unabhängige Stücke zerfallen, profitieren also deutlich. Beim Programmieren hängt mehr an gemeinsamem Kontext, es lässt sich weniger parallelisieren. Dort kauft ihr meist Zeit und nur manchmal Qualität: Bei GPT-6 Sol mit mittlerem Aufwand war der Gewinn belastbar, in den anderen drei Vergleichen nicht.

Warum der Zugewinn beim Coding so klein ausfällt

Ein Agent, der eine Aufgabe von einem anderen übernimmt, kennt dessen Überlegungen nicht. Er bekommt einen Auftragstext und vielleicht eine Zusammenfassung. Alles, was im Kopf des ersten Agenten war und nicht aufgeschrieben wurde, ist weg. Bei einer Recherche ist das harmlos, zwei Suchstränge müssen nichts voneinander wissen. Bei einer Codeänderung, die Frontend, API und Datenmodell berührt, ist genau dieses Wissen die halbe Arbeit.

Das Problem kennt jedes menschliche Team. Mehr Leute machen ein Projekt nur schneller, wenn die Arbeit in sauber geschnittene Pakete zerfällt, die jemand ohne ständige Rückfragen erledigen kann. Fehlt dieser Zuschnitt, frisst die Abstimmung den Zugewinn auf, und zwei Leute arbeiten am selben Problem aneinander vorbei. Für Agenten gilt dasselbe, nur schärfer: Ein Kollege fragt nach, wenn ihm Kontext fehlt, ein Agent rät. Wer ein Agenten-Team einsetzt, muss also zuerst die Arbeit leisten, die auch ein gutes Sprint-Planning leistet, nämlich klare Schnittstellen, abgegrenzte Zuständigkeiten und ein Ergebnis je Paket, das sich prüfen lässt.

Dazu kommt die Abstimmung selbst. Cursor hat in seinem Bericht über lang laufende Agenten beschrieben, wie ein erster Ansatz mit Sperren scheiterte: "Twenty agents would slow down to the effective throughput of two or three, with most time spent waiting." Erst die Trennung in Planer und Worker hat das behoben.

Und schließlich sind die Modelle selbst stärker geworden. Ein Einzelagent, der in der Vals-Messung schon bei rund 90 Prozent landet, lässt wenig Luft nach oben. Die Google-Arbeit findet auf ihren eigenen Benchmarks einen ähnlichen Effekt: Je stärker der Einzelagent schon ist, desto weniger bringen zusätzliche Agenten.

Wo viele Agenten wirklich etwas gebracht haben

Es gibt Gegenbeispiele mit großem Budget, und sie haben auffällig viel gemeinsam.

• Ein C-Compiler von Anthropic: 16 parallele Agenten, knapp 2.000 Sitzungen in rund zwei Wochen, knapp 20.000 Dollar. Das Ergebnis übersetzt den Linux-Kernel.
• Ein Großumbau bei Nous Research: 1.393 Subagenten, bis zu 218 gleichzeitig, rund 19 Stunden, etwa 19.300 Dollar für den Hauptlauf. Der Python-Code schrumpfte um ein Drittel.
• Die Dekompilierung eines Spiels: zuletzt 16 Agenten, rund drei Monate, nach Schätzung des Autors 600 bis 700 Milliarden Tokens (der Titel des Beitrags nennt noch 500), 83 Prozent der Funktionen bytegenau rekonstruiert.

In allen drei Fällen ließ sich die Arbeit in Stücke schneiden, die sich nicht in die Quere kommen: eine Datei, ein fehlschlagender Test oder ein Modul je Agent. Dazu kam jedes Mal ein Abnahmekriterium, das eine Maschine prüfen kann. Beim Compiler waren es die Test-Suites, bei der Dekompilierung der Byte-Vergleich mit dem Original.

Wie sehr es daran hängt, zeigen die Stellen, an denen es schiefging. Beim Compiler brach die Parallelisierung zusammen, sobald mit dem Kernel-Build nur noch eine einzige große Aufgabe übrig war: "Every agent would hit the same bug, fix that bug, and then overwrite each other's changes." Die ersten vier Wochen der Dekompilierung sahen nach Fortschritt aus, weil das Spiel startete. Der Code war aber an vielen Stellen falsch, und ihn zu retten kostete mehr als ein Neuanfang. Später versuchten die Agenten, das Prüfskript zu verändern, bis die CI dessen Hash kontrollierte. Nous Research wiederum rutschten trotz Tests Regressionen durch, die erst zwei Review-Runden mit Menschen fanden. Mehr dazu, wie Agenten Prüfungen austricksen, steht in unserem Artikel zu Reward Hacking.

Braucht ihr dafür mehrere Rechner?

Selten. Ein lokaler Agent kann heute selbst Subagenten starten, in Claude Code bis zu 20 gleichzeitig und über mehrere Ebenen. Dynamic Workflows lassen laut Dokumentation bis zu 16 Agenten parallel im Hintergrund laufen, auf eurer Maschine. Die Rechenarbeit findet ohnehin beim Modellanbieter statt. Lokal läuft nur, was die Agenten anstoßen.

Genau dort liegt die Grenze. Wenn jeder Agent einen eigenen Build, eine eigene Testdatenbank oder einen eigenen Browser braucht, geht dem Laptop die Luft aus, und die Agenten stehen sich bei Ports und Arbeitsverzeichnissen im Weg. Für solche Vorhaben, große Migrationen mit schwerem Build oder Läufe über Tage, sind Cloud-Angebote mit einer eigenen Umgebung je Agent gebaut. Das ist der technisch aufwendige Sonderfall, nicht der Alltag eines Feature-Teams. Was der Dauerbetrieb von Agenten kostet, steht in Was Agenten kosten, wenn niemand mitzählt.

Wer vor einem Agent Team steht, weil sich die Aufgabe groß anfühlt, sollte deshalb zuerst prüfen, ob der eine Agent mit ein paar Subagenten für die lauten Nebenarbeiten nicht reicht. Tests laufen lassen, Logs durchsuchen, Dokumentation lesen: Das sind die Aufgaben, bei denen ein Subagent den Kontext des Hauptagenten sauber hält und nur das Ergebnis zurückgibt.

So entscheidet ihr

flowchart TB
  A{"Zerfällt die Aufgabe<br/>in unabhängige Teile?"}
  A -->|Nein| B["Ein Agent,<br/>Subagenten für<br/>Nebenarbeiten"]
  A -->|Ja| C{"Kann eine Maschine<br/>das Ergebnis prüfen?"}
  C -->|Nein| D["Kleines Team,<br/>ein Mensch prüft"]
  C -->|Ja| E{"Ist das Tempo<br/>das Geld wert?"}
  E -->|Nein| F["Ein Agent,<br/>Teile nacheinander"]
  E -->|Ja| G["Paralleler Lauf,<br/>erst ein kleiner<br/>Ausschnitt"]
  class A,C,E decision
  class G success
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Ein paar Faustregeln, die sich aus den Quellen ergeben:

• Rechnet mit dem Zwei- bis Fünffachen. Das ist die Spanne aus der Vals-Messung für ein kleines Team. Anthropic nennt für Agent Teams im Plan-Modus ungefähr das Siebenfache einer normalen Sitzung. Bei einem Abo heißt das: Das Wochenlimit ist entsprechend früher erreicht.
• Probiert auch den Reasoning-Aufwand. In der Vals-Messung brachte bei GPT-6 Sol der Schritt von mittlerem auf maximalen Aufwand mehr als das Team, gut elf Punkte statt gut sieben. Bei Opus 5.5 half beides kaum, der Einzelagent war mit maximalem Aufwand sogar etwas schwächer. Was der höhere Aufwand kostet, steht nicht in dem Vergleich, das müsst ihr selbst gegenrechnen.
• Fangt mit lesenden Aufgaben an. Review, Recherche und Fehlersuche mit konkurrierenden Hypothesen sind die Fälle, die auch die Hersteller als die stärksten nennen. Paralleles Schreiben in derselben Codebasis ist der schwierigste.
• Probiert an einem Ausschnitt. Ein Verzeichnis statt des ganzen Repos zeigt, was der Lauf kostet, bevor er es tut. Die Workflows-Dokumentation empfiehlt das selbst, und Claude Code warnt, sobald ein Lauf mehr als 25 Agenten einplant oder auf über 1,5 Millionen Tokens zusteuert.
• Baut den Prüfer zuerst. Ohne Test, der hart Ja oder Nein sagt, skaliert ihr mit den Agenten vor allem die Menge an Code, die ein Mensch nachlesen muss. Wie so eine Schleife aus Schreiben und Prüfen aussieht, beschreibt die KI-Controlling-Schleife.

Was offen bleibt

Die Datenlage ist dünn. Für das Programmieren mit aktuellen Modellen haben wir nur einen kontrollierten Vergleich gefunden, und der lief einmal. Die großen Erfolgsgeschichten stammen von den Herstellern oder von Projekten mit fünfstelligen Budgets und sagen wenig über ein Ticket aus dem Sprint. Was 100 oder 1.000 Agenten an Qualität bringen, weiß laut Brown auch bei OpenAI niemand genau, weil die Experimente zu teuer sind.

Bis es bessere Messungen gibt, ist die vorsichtige Lesart die vernünftige: Mehrere Agenten sind zuerst ein Mittel, um Wartezeit gegen Geld zu tauschen. Ob sich der Tausch lohnt und ob dabei auch Qualität herausspringt, entscheidet die Aufgabe.