Solo schlägt Team -- Wann Multi-Agent-Systeme den Compute-Aufwand nicht rechtfertigen
Forschende der Stanford University haben systematisch untersucht, unter welchen Bedingungen Multi-Agent-Architekturen gegenüber einem einzelnen Agenten Vorteile bringen -- und wann sie es nicht tun. Das Ergebnis ist ernüchternd für den Multi-Agent-Hype: Bei gleichem Compute-Budget schneidet ein Solo-Agent mindestens genauso gut ab wie ein Team aus mehreren Agenten. Die Studie testet vier Modelle unterschiedlicher Größe und Architektur auf zwei Multi-Step-Reasoning-Benchmarks gegen fünf verschiedene Team-Konfigurationen.
Kernaussagen
Gleicher Compute, gleiche oder bessere Leistung für Solo-Agenten. Das zentrale Ergebnis der Studie: Wenn ein einzelner Agent und ein Team dasselbe Compute-Budget erhalten, performt der Solo-Agent mindestens auf dem Niveau des Teams. Die gängige Annahme, dass mehr Agenten automatisch bessere Ergebnisse liefern, hält der empirischen Prüfung nicht stand.
Informationsverlust bei Handoffs als Hauptursache. Jede Übergabe zwischen Agenten birgt das Risiko, relevante Informationen zu verlieren. Ein einzelner Agent hält alles in einem kontinuierlichen Reasoning-Prozess. Bei einem Team muss jeder Agent den Kontext der vorherigen Agenten rekonstruieren -- ein verlustbehafteter Prozess, der sich über mehrere Handoffs akkumuliert.
Drei Ausnahmen, in denen Multi-Agent besser abschneidet:
-
Long Context mit korruptem Input. Wenn der Eingabetext lang ist und irrelevante oder fehlerhafte Passagen enthält, können verteilte Agenten den Input besser filtern. Jeder Agent bearbeitet einen Ausschnitt und ist weniger anfällig für die Gesamtkorruption.
-
Schwächere Basismodelle. Teams kompensieren die Schwächen weniger leistungsfähiger Modelle. Die kollektive Verarbeitung gleicht individuelle Defizite aus -- ein Effekt, der bei stärkeren Modellen verschwindet.
-
Debate-Architekturen. Wenn Agenten in einem Debate-Format interagieren, spannen sie ein breiteres Lösungsnetz auf. Gelegentlich finden sie dadurch Lösungen, die ein Solo-Agent übersieht. Dieser Vorteil ist jedoch nicht konsistent genug, um den Compute-Mehraufwand systematisch zu rechtfertigen.
Methodik
Die Studie evaluiert vier Modelle mit unterschiedlichen Leistungsprofilen: Qwen3-30B-A3B (kompaktes MoE-Modell), DeepSeek-R1-Distill-Llama-70B (destilliertes Reasoning-Modell), Gemini 2.5 Flash (schnelles Inferenzmodell) und Gemini 2.5 Pro (großes Reasoning-Modell). Diese Auswahl deckt das Spektrum von kleinen effizienten bis hin zu großen leistungsstarken Modellen ab.
Als Benchmarks dienen zwei Multi-Step-Reasoning-Aufgaben, die mehrstufiges Schlussfolgern erfordern. Der Solo-Agent wird gegen fünf Team-Architekturen verglichen: sequentielle Ketten (Agent A übergibt an Agent B übergibt an Agent C), Debate-Formate (Agenten argumentieren gegeneinander) und Ensemble-Ansätze (mehrere Agenten lösen unabhängig, das beste Ergebnis wird gewählt).
Der entscheidende Punkt des Versuchsdesigns: Das Compute-Budget wird konstant gehalten. Ein Solo-Agent erhält die gleiche Menge an Tokens und Rechenzeit wie das gesamte Team zusammen. Das eliminiert den trivialen Einwand, dass ein Team schlicht mehr Ressourcen verbraucht.
Einschränkung: Die Studie beschränkt sich auf textbasierte Reasoning-Tasks. Tool Use, Bildverarbeitung und andere Modalitäten wurden nicht getestet. Ob die Ergebnisse auf agentic Workflows mit Werkzeugaufrufen, Datenbankabfragen oder API-Interaktionen übertragbar sind, bleibt offen.
Relevanz fuer die Praxis
Die Studie stellt eine unbequeme Frage an jeden, der Multi-Agent-Systeme baut: Ist die Komplexität gerechtfertigt?
Multi-Agent ist kein Selbstzweck. Wer ein Multi-Agent-System entwirft, muss belegen können, dass es nicht mit einem einzelnen Agenten und dem gleichen Compute-Budget lösbar wäre. Die Studie zeigt, dass der Standardfall -- textbasiertes Reasoning -- keinen Multi-Agent-Ansatz erfordert. Ein einzelner Agent mit mehr Kontext und längerer Reasoning-Kette ist die einfachere und mindestens gleichwertige Lösung.
Wann Multi-Agent sich lohnt. Die drei identifizierten Ausnahmen bieten konkrete Entscheidungskriterien:
- Der Input ist so lang oder verrauscht, dass ein einzelner Agent überfordert wäre (Long-Context-Filterung)
- Das verfügbare Modell ist schwach und ein stärkeres Modell steht nicht zur Verfügung (Kompensation durch Teamwork)
- Die Aufgabe profitiert von divergentem Denken, etwa in explorativen Szenarien (Debate)
Handoff-Kosten einpreisen. Jede Architekturentscheidung für Multi-Agent bedeutet Handoff-Kosten: Kontextverlust, Koordinations-Overhead, erhöhte Komplexität in Fehlerbehandlung und Debugging. Diese Kosten müssen die Vorteile überwiegen. Die Studie quantifiziert erstmals, dass der Informationsverlust bei Handoffs der dominierende Nachteil ist -- nicht der Compute-Overhead allein.
Offene Frage: Tool Use. Die größte Einschränkung der Studie ist gleichzeitig die relevanteste für die Praxis. Viele reale Multi-Agent-Systeme sind gerade deshalb multi-agent, weil verschiedene Agenten verschiedene Tools bedienen. Ob der Handoff-Nachteil auch in tool-augmented Settings dominiert, ist ungeklärt. Bis belastbare Daten vorliegen, bleibt die konservative Empfehlung: Im Zweifel mit einem einzelnen Agenten starten und Multi-Agent nur einführen, wenn der Solo-Agent nachweislich scheitert.