Wann Multi-Agent-Systeme gegenüber Single-Agent einsetzen: Das Entscheidungsframework

Gartner: 40 % der agentic-AI-Projekte werden bis Ende 2027 abgebrochen. Eine Hauptursache – Architektur-Mismatch. Teams haben Multi-Agent-Systeme gewählt, obwohl ein gut abgestimmter Single Agent die Aufgabe hätte erledigen können. Sechs Monate und 800.000 $ investiert, um Infrastruktur für ein Problem aufzubauen, das das nicht erfordert hätte.

Das Gegenteil ist gleichermaßen teuer. Teams haben sich für Single-Agent entschieden, obwohl die Aufgabe eine genuin komplexe, multisource-basierte Synthese erforderte, die verteiltes Reasoning brauchte. Ein Jahr damit verbracht, Prompts und Retrieval zu optimieren, ohne die Qualitätsschwelle je zu erreichen – weil die Architektur nicht unterstützen konnte, was man von ihr verlangte.

Das ist der Entscheidungsrahmen, der dir hilft, richtig zu wählen, bevor du dich festlegst.

Die architektonische Unterscheidung in einem Satz

Single Agent: eine Reasoning-Kette vom Input zum Output, mit angehängten Tools.

Multi-Agent: ein Orchestrator-Agent, der eine Aufgabe in Teilaufgaben zerlegt und an spezialisierte Agenten verteilt, deren Outputs dann zu einer finalen Antwort synthetisiert werden.

Dieser Unterschied – eine Reasoning-Kette versus ein Decomposition-Synthesis-Loop – ist die Achse, auf der fast jede Entscheidung basiert.

Die echten Kosten von Multi-Agent

Bevor wir zum Entscheidungsrahmen kommen, muss die Kostenseite klar sein. Multi-Agent ist kein kostenloses Upgrade von Single Agent. Es kommt mit:

Token-Overhead pro Agent: Jeder Agent in einem Multi-Agent-System braucht seinen eigenen Kontext – Anweisungen, System Prompt, relevante Daten. Drei Agenten dazu, und du bezahlst für drei Kontext-Ladungen pro Query. Forschung aus agentic-AI-Produktions-Deployments: Multi-Agent-Systeme können bis zu 15x mehr Tokens verbrauchen als Single-Agent für äquivalente Aufgaben.

Koordinationslatenz: Wenn ein Agent von der Ausgabe eines anderen Agenten abhängt, addiert sich die Zeit für diesen Übergabemoment. Bei einem Zwei-Agenten-System ist das noch überschaubar. Bei einem Fünf-Agenten-Orchestrierung mit parallelen und seriellen Abhängigkeiten potenziert sich die Latenz.

Debugging-Komplexität: Ein Single-Agent-Trace ist linear. Die Reasoning-Kette von Input zu Output lässt sich durchlesen wie ein Buch. Ein Multi-Agent-Trace ist ein Graph – Agent A ruft Agent B auf, der parallel Agent C und Agent D aufruft, deren Ausgaben in Agent E zusammenlaufen. Wenn etwas schiefgeht, ist die Frage nicht „Was ist passiert?" Sondern: Welcher Agent hatte den Fehler? Und lag es am Reasoning dieses Agenten oder an den Anweisungen, die er vom Orchestrator bekommen hat?

API-Kosten-Multiplikation: Kontrollierte Experimente über produktive agentic-Systeme hinweg zeigen einen 3,7-fachen API-Kosten-Anstieg für Multi-Agent versus Single-Agent bei vergleichbaren Aufgabentypen. Nicht 3,7 % – 3,7x. Diese Zahl wird relevant, wenn du ein Produkt kalkulierst.

Wann Single-Agent die richtige Wahl ist

Single-Agent-Architektur ist korrekt – und wird oft unterschätzt – wenn:

Der Workflow linear ist: Die Aufgabe geht von Input über eine einzelne Reasoning-Kette zum Output. Kein bedeutsames Branching, keine parallelen Subtasks, keine spezialisierten Wissensdomänen nötig. Ein Customer-Support-Agent, der aus einer Knowledge Base abruft und eine Antwort generiert, ist ein Single-Agent-Problem. Das Reasoning ist sequenziell: Verstehen, Abrufen, Synthetisieren, Antworten.

Starke Identifier verfügbar sind: Der Agent muss Entitäten und Intents zuverlässig aus dem Input identifizieren können. Wenn starke Identifier existieren – spezifische Produktnamen, klare Intent-Kategorien, gut strukturierte Daten – dann bewältigt ein einzelner Agent mit gutem Prompting diese konsistent.

Der Chaos-Faktor gering ist: Die Input-Vielfalt ist begrenzt. Der Agent begegnet keine unvorhersehbaren Kombinationen von Anforderungen, die unterschiedliche Reasoning-Ansätze erfordern. Ein einzelner Agent, der auf eine Domäne feingetunt ist, schlägt ein Multi-Agent-System, das mehrere Domänen abdecken muss.

Die AI-Engineering-Kapazität begrenzt ist: Multi-Agent-Systeme brauchen laufende Orchestrierungswartung. Wenn dein Team aus zwei Engineers besteht und davon nur einer den agentic Framework versteht, ist Single-Agent der richtige Anruf. Das beste Multi-Agent-System, das von einem Team gebaut wurde, das es nicht maintainen kann, wird in Produktion scheitern.

Der Kontext ins Kontextfenster passt: Single-Agent glänzt, wenn der gesamte relevante Kontext – Input, abgerufenes Wissen, Konversationshistorie, Output-Format-Anweisungen – ins Kontextfenster des Modells passt. Wenn er das nicht tut, ist das oft ein Retrieval-Problem, kein Multi-Agent-Problem.

Das Anti-Pattern: Teams fügen Agenten hinzu, weil es sich fortschrittlicher anfühlt. Die eigentliche Aufgabe – eine Antwort aus einer Knowledge Base generieren, eine E-Mail klassifizieren, strukturierte Daten aus einem Dokument extrahieren – war ein Single-Agent-Problem, das über-engineered wurde.

Wann Multi-Agent gerechtfertigt ist

Multi-Agent-Architektur rechtfertigt ihre Kosten, wenn:

Die Aufgabe genuin domänenübergreifende Expertise erfordert: Der Input braucht Reasoning aus fundamental unterschiedlichen Wissensdomänen, die einen einzelnen Kontext überladen würden. Eine Legal-Financial-Research-Aufgabe braucht einen Legal-Reasoning-Agenten und einen Financial-Analysis-Agenten – nicht einen Agenten, der beides sein will.

Parallele Verarbeitung genuine hilft: Mehrere unabhängige Subtasks können gleichzeitig laufen und ihre Outputs müssen synthetisiert werden. Die Latenzreduktion durch parallele Ausführung überwiegt den Koordinationsaufwand. Beispiel: drei Agenten durchsuchen gleichzeitig verschiedene Datenbanken für einen umfassenden Due-Diligence-Report.

Fehlertoleranz eine harte Anforderung ist: Wenn ein Agent ausfällt, muss das System gracefully degradieren, anstatt komplett zu scheitern. Ein Multi-Agent-System, in dem jeder Agent unabhängig retryen kann oder ein Supervisor-Agent Tasks re-routen kann, handhabt Ausfälle besser als ein Single Point of Failure.

Die Qualitätslücke nachgewiesen ist: Nachdem ein Single-Agent-Baseline gebaut und optimiert wurde, liegt die Output-Qualität bei komplexen Tasks messbar unter der Qualitätsschwelle. Die Lücke ist kein Prompt-Engineering-Problem – sie ist ein Reasoning-Kapazitäts-Problem, das ein spezialisierter Agent löst.

Die Koordinationslogik das Produkt ist: Wenn die Art und Weise, wie Aufgaben zerlegt und synthetisiert werden, selbst ein Wettbewerbsvorteil ist – Routing, Priorisierung, Agent-Selektion – dann ist Multi-Agent-Architektur das richtige Fundament, weil genau diese Logik das ist, was du baust.

Das Anti-Pattern: Teams wählen Multi-Agent, weil es sich fortschrittlicher anhört. Die eigentliche Aufgabe war mit einem gut gepingten Single Agent erreichbar, und die Multi-Agent-Infrastruktur ist Overhead, der die Iterationsgeschwindigkeit bremst, ohne Qualitätsvorteil zu liefern.

Der Entscheidungs-Diagnostik – 5 Fragen

Wende das an, bevor du dich für Multi-Agent entscheidest:

Frage 1: Ist die Input-Komplexität begrenzt oder unbegrenzt?

Wenn begrenzt – der Input kommt in bekannten Kategorien mit vorhersagbarer Struktur – ist Single-Agent wahrscheinlich ausreichend. Wenn die Input-Vielfalt offen ist und unterschiedliche Reasoning-Ansätze erfordert, je nachdem, was der Input enthält, kann Multi-Agent gerechtfertigt sein.

Frage 2: Kann ein einzelner Prompt die Qualitätsschwelle erreichen?

Schreib den Prompt. Teste ihn mit 50 echten Beispielen. Wenn die Outputs konsistent unter der Qualitätsschwelle liegen und die Fehlermodi Reasoning-Fehler sind, die ein besserer Prompt nicht beheben kann – dann hast du ein Kapazitätsproblem, das Multi-Agent adressieren kann. Wenn die Fehler Retrieval-Fehler oder Format-Fehler sind, sind die innerhalb der Single-Agent-Architektur lösbar.

Frage 3: Wie groß ist das Token-Budget für diese Aufgabe?

Wenn die Aufgabe mehr Kontext erfordert, als dein Modell zuverlässig verarbeiten kann, hast du ein Kompressions- oder Retrieval-Problem, kein Architektur-Problem. Repariere zuerst das Retrieval. Wenn der Kontext legitim zu groß ist, weil er mehrere Domänen umspannt, ist das ein Signal für Multi-Agent.

Frage 4: Spielt Latenz eine Rolle für diese Aufgabe?

Wenn das eine synchrone, user-facing Aufgabe ist, bei der 3–5 Sekunden Latenz akzeptabel sind, ist Single-AgentProbably fine. Wenn du Sub-Sekunden-Antworten brauchst oder wenn die Aufgabe async laufen kann, verschiebt sich die Latenz-Gleichung.

Frage 5: Was passiert, wenn etwas schiefgeht?

In einem Single-Agent-System: Trace lesen, Fehler finden, Prompt oder Retrieval reparieren. In einem Multi-Agent-System: Orchestrierungsgraph lesen, identifizieren welcher Agent ausgefallen ist, bestimmen ob der Fehler im Reasoning dieses Agenten lag oder in den Anweisungen, die er vom Orchestrator bekommen hat, dann entweder den Agenten oder die Routing-Logik reparieren. Die Debugging-Oberfläche ist größer.

Wenn du nicht die Observability-Tools hast, um ein Multi-Agent-System zu debuggen – und die meisten Teams bauen das nicht, bevor sie es brauchen – ist Single-Agent der richtige Anruf.

Der Microsoft-AI-Agent-Entscheidungsbaum

Das Azure CAT Team von Microsoft hat einen Entscheidungsbaum für AI-Agent-Architektur veröffentlicht. Das Rückgrat:

Kann ein einzelner Model Call das bewältigen? → Ja → Single Agent
Erfordert die Aufgabe mehrere spezialisierte Wissensdomänen? → Ja → Multi-Agent
Erfordert die Aufgabe parallele Ausführung aus Latenz- oder Throughput-Gründen? → Ja → Multi-Agent
Erfordert die Aufgabe Fehlertoleranz jenseits von Retry-Logik? → Ja → Multi-Agent
Ansonsten → Single Agent mit besserem Prompting und Retrieval

Der letzte Branch ist der, den Teams am häufigsten skippen. Sie greifen zu Multi-Agent, bevor sie den Single-Agent-Optimierungspfad ausgeschöpft haben. Das Microsoft-Framework identifiziert korrekt, dass Multi-Agent die Antwort auf spezifische, identifizierte Probleme ist – nicht eine Default-Architektur.

Die Anti-Patterns, die du vermeiden solltest

Anti-Pattern 1: Multi-Agent, weil es sich fortschrittlicher anhört

Das ist die architektonische Entsprechung davon, Enterprise-Software zu kaufen, weil sie seriöser klingt als die Startup-Version. Die Multi-Agent-Infrastruktur, die du baust, wird deine Iterationsgeschwindigkeit einschränken. Wenn die Aufgabe es nicht erfordert hat, hast du Komplexität ohne Benefit hinzugefügt.

Anti-Pattern 2: Single-Agent für genuin komplexe Synthese-Aufgaben

Ein einzelner Agent, der gleichzeitig über Legal Risk, Financial Impact und Operational Feasibility reasonen soll, wird gegenüber einem System mit spezialisierten Agenten für jede Domäne underperformen. Der Prompt-Engineering-Weg, um einen einzelnen Agenten dazu zu bringen, alle drei gut zu machen, ist länger als der Multi-Agent-Weg. Miss die Lücke, bevor du entscheidest.

Anti-Pattern 3: Die Token-Kosten-Gleichung ignorieren

Multi-Agent bei 3,7x der Token-Kosten von Single-Agent ist kein Problem, wenn der Multi-Agent-Output nachweislich besser ist. Es ist ein Problem, wenn die Outputs äquivalent sind und du Multi-Agent gewählt hast, weil es sich sophistizierter anfühlte.

Praktische nächste Schritte

Starre mit einer Single-Agent-Baseline: Baue die einfachste mögliche Single-Agent-Version von dem, was du erreichen willst. Nutze gutes Prompting, gutes Retrieval und einen sauber strukturierten System Prompt. Diese Baseline ist dein Referenzpunkt.

Miss die Lücke: Lass die Baseline gegen echte Produktions-Inputs laufen. Miss die Output-Qualität mit einer Bewertungsrubrik, nicht mit einem Gefühl. Wenn die Qualität konsistent unter der Schwelle liegt, identifiziere die konkreten Fehlermodi.

Wende die Diagnostik an: Für jeden Fehlermodus frag: Ist es ein Prompting-Problem, ein Retrieval-Problem, ein Kontextfenster-Problem oder ein Reasoning-Kapazitäts-Problem? Prompting- und Retrieval-Probleme sind in Single-Agent lösbar. Reasoning-Kapazitäts-Probleme – wenn das Modell mehrere Dinge tun muss, die schwer in einem Prompt zu kombinieren sind – sind das Signal für Multi-Agent.

Baue Multi-Agent erst, wenn die Lücke nachgewiesen ist und die Diagnostik darauf zeigt: Nicht vorher.

Die Projekte, die scheitern, starten mit Multi-Agent, weil es sich richtig anfühlt, und verbringen dann sechs Monate damit, die Architektur zum Laufen zu bringen. Die Projekte, die erfolgreich sind, starten mit Single-Agent, messen ehrlich und fügen Agenten nur hinzu, wenn das spezifische Problem es erfordert.