Multi-Agenten-Systeme: Wann mehrere Agenten besser sind als einer

Ein Agent, mehrere Agenten: wovon reden wir eigentlich

Ein autonomer KI-Agent läuft allein, mit eigenen Werkzeugen, eigenem Gedächtnis und eigenem Ziel. Ein Multi-Agenten-System dagegen setzt mehrere Agenten auf dieselbe Aufgabe an, jeder mit einer klaren Rolle. Die Idee ist in der verteilten Informatik nicht neu, bekommt aber erst seit Sprachmodelle Werkzeuge nutzen und Schritte ohne ständige Aufsicht aneinanderreihen können eine konkrete Bedeutung.

Der Begriff deckt unterschiedliche Realitäten ab. Es gibt das System "Orchestrator plus Unteragenten", bei dem ein Hauptagent die Arbeit zerlegt und Teile an spezialisiertere Agenten delegiert. Es gibt auch gleichrangige Agenten, die untereinander kommunizieren, um Ergebnisse ohne strikte Hierarchie zu teilen. Wichtig ist die Nuance: "Mehrere Agenten" bedeutet nicht "mehrere identische Instanzen, die parallel dasselbe tun", jeder Agent hat einen abgegrenzten Zuständigkeitsbereich. Das Glossar von Atako erläutert diese Unterscheidung ausführlicher.

Das Prinzip der Orchestrierung

Was ein echtes Multi-Agenten-System von einer simplen Sammlung parallel laufender Skripte unterscheidet, ist die Orchestrierung: die Logik, die entscheidet, wer was in welcher Reihenfolge tut und wie sich die Ergebnisse wieder zusammensetzen. Anthropic hat die Architektur, die für die eigene Tiefenrecherche-Funktion genutzt wird, ausführlich dokumentiert: Ein "Lead"-Agent analysiert die Anfrage, legt eine Strategie fest und erzeugt dann Unteragenten, die jeweils eine Spur parallel verfolgen, bevor ihre Ergebnisse zusammenfließen (Quelle: Anthropic, "How we built our multi-agent research system", https://www.anthropic.com/engineering/multi-agent-research-system, abgerufen am 2026-09-04).

Dieses Orchestrator/Worker-Modell taucht in fast jeder ernsthaften Implementierung wieder auf. Der Hauptagent erledigt die Arbeit nicht selbst: Er plant, verteilt, prüft und fügt zusammen. Das nennt man Agenten-Orchestrierung. Der Unteragent wiederum ist als kurzlebig und wegwerfbar gedacht: Er existiert für die Dauer einer Teilaufgabe und verschwindet dann.

Warum mehrere Agenten manchmal besser sind als einer

Das meistzitierte Ergebnis zu diesem Thema stammt ausgerechnet von Anthropic selbst. In der internen Auswertung hat ein System aus einem Opus-Agenten als Dirigent und Sonnet-Unteragenten die Leistung eines einzelnen Opus-Agenten bei denselben Rechercheaufgaben um 90,2 % übertroffen (gleiche Quelle wie oben). Die Erklärung lässt sich in einem Wort zusammenfassen: Parallelisierung. Ein einzelner Agent erkundet Spuren nacheinander, in einem einzigen Kontextfenster, das irgendwann an seine Grenzen stößt. Mehrere Agenten können mehrere Spuren gleichzeitig erkunden, jeder in seinem eigenen Kontext, bevor sie zusammenführen, was sie gefunden haben.

Dieser Vorteil ist nicht universell. Er zeigt sich vor allem bei Aufgaben "in der Breite": Recherche, Erkundung mehrerer Hypothesen, Verarbeitung eines großen Volumens unzusammenhängender Informationen. LangChain fasst die Bedingung in einem Referenzartikel zum Thema treffend zusammen: Multi-Agenten-Systeme glänzen bei hochwertigen Aufgaben, die sich gut parallelisieren lassen, und verlieren ihren Nutzen, sobald die Arbeit stark sequenziell ist oder von einem gemeinsamen Kontext abhängt (Quelle: LangChain, "How and when to build multi-agent systems", https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems, abgerufen am 2026-09-04).

Anthropic ist sogar so weit gegangen, statistisch aufzuschlüsseln, was die Leistungsunterschiede zwischen Konfigurationen erklärt. Drei Faktoren erklären allein 95 % der beobachteten Varianz: die genutzte Tokenmenge, die Anzahl der Werkzeugaufrufe und die Wahl des Modells. Der Tokenverbrauch allein erklärt 80 % dieser Varianz (gleiche Quelle). Anders gesagt: Nicht "mehrere Agenten zu haben" bringt den Leistungsgewinn, sondern die Fähigkeit, dadurch mehr Rechenleistung parallel auf ein dafür geeignetes Problem zu verwenden. Bei einem Problem, das sich dafür nicht eignet, nützt genau diese Fähigkeit nichts, sie kostet nur mehr für ein vergleichbares Ergebnis wie bei einem einzelnen Agenten.

Der Preis der Koordination

Dieser Leistungsgewinn hat einen Preis, und der ist alles andere als marginal. Laut Anthropic verbraucht ein einzelner Agent bereits rund 4-mal mehr Tokens als eine klassische Chat-Konversation. Ein Multi-Agenten-System verbraucht rund 15-mal mehr (gleiche Quelle). Das ist keine buchhalterische Randnotiz: Bei diesem Multiplikationsfaktor rechtfertigen nur Aufgaben mit wirklich hohem geschäftlichem Wert die Investition.

Die Koordinationskosten beschränken sich nicht auf Tokens. LangChain weist auf ein strukturelleres Problem hin: Gleichzeitige Schreibzugriffe verursachen deutlich mehr Probleme als gleichzeitige Lesezugriffe. Zwei Agenten, die parallel dieselbe Datenbank lesen, das ist unproblematisch. Zwei Agenten, die gleichzeitig dasselbe Dokument, dasselbe Ticket oder dieselbe Codezeile ändern, das erzeugt Konflikte, die anschließend aufgelöst werden müssen, oft manuell. Je mehr Agenten, desto größer die Angriffsfläche für Fehler: Jeder zusätzliche Agent fügt eine weitere Schicht geteilten Zustands hinzu, ein Kommunikationsprotokoll und einen neuen Punkt, an dem das System abstürzen kann, ohne dass sofort jemand versteht, warum.

Auch die Debugging-Kosten müssen mitgerechnet werden. Dem Schlussfolgern eines einzelnen Agenten mit seiner Aktions-Timeline zu folgen, ist bereits eine eigene Aufgabe. Die Abfolge von Entscheidungen zwischen mehreren Agenten zu verfolgen, die sich eine Aufgabe teilen, mit ihrem Nachrichtenaustausch und möglichen Abweichungen, erfordert eine deutlich weiterreichende Observability. Das ist ein eigenständiges Projekt für sich.

Wann man die Finger vom Multi-Agenten-Ansatz lassen sollte

Der Reflex "mehr Agenten, mehr Power" ist einer der sichersten Wege, ein KI-Budget ohne proportionalen Gewinn explodieren zu lassen. Gartner hat das hart beziffert: Das Analystenhaus prognostiziert, dass mehr als 40 % der agentischen KI-Projekte bis Ende 2027 eingestellt werden, unter anderem wegen aus dem Ruder laufender Kosten, schlecht definiertem geschäftlichem Wert und unzureichenden Risikokontrollen (Quelle: Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027, abgerufen am 2026-09-04). Ein guter Teil dieser Misserfolge stammt von Projekten, die Orchestrierungskomplexität hinzufügen, ohne dass die Aufgabe es rechtfertigt.

Konkret bleibt man besser bei einem einzelnen Agenten, wenn die Aufgabe in ein einziges Kontextfenster passt, wenn sie stark sequenziell ist (jeder Schritt hängt strikt vom vorherigen ab), oder wenn das Arbeitsvolumen die Tokenrechnung nicht rechtfertigt. LangChain nennt Coding als Beispiel: Anders als bei der Recherche enthält eine Entwicklungsaufgabe selten echte parallelisierbare Arbeit, was den Multi-Agenten-Ansatz für diesen konkreten Anwendungsfall weniger sinnvoll macht, als man annehmen könnte.

Die richtige Frage vor dem Hinzufügen eines zweiten Agenten lautet also nicht "kann das helfen?", sondern "hat diese Aufgabe eine echte, natürliche Trennlinie?". Braucht ein Teil der Arbeit Dateizugriff, ein anderer Datenbankzugriff, und ein dritter einen Aufruf einer externen API, gibt es eine echte mögliche Aufteilung. Hängt alles vom selben Gedankenstrang ab, fügt das Hinzufügen von Agenten vor allem Reibung hinzu.

Eine einfache Checkliste vor dem Start: Erzeugt die Aufgabe mehrere unabhängige Spuren, die sich parallel erkunden lassen? Rechtfertigt das Arbeitsvolumen eine mehrfach höhere Tokenrechnung? Schreiben die Teilaufgaben in unterschiedliche Systeme, oder laufen sie Gefahr, sich bei denselben Daten gegenseitig ins Gehege zu kommen? Lautet die Antwort bei einer dieser drei Fragen Nein, wird ein einzelner, gut ausgestatteter Agent mit guten Zugriffsrechten und klaren Anweisungen wahrscheinlich schneller und günstiger sein als eine Multi-Agenten-Architektur.

Was Atako konkret ändert

Bei Atako ist diese Orchestrator/Unteragenten-Logik nativ eingebaut: Ein Agent kann eine komplexe Teilaufgabe an einen kurzlebigen Unteragenten delegieren, dessen Arbeit als Schritte in der Aktivitäts-Timeline des Hauptagenten erscheint, ohne einen zusätzlichen Slot zu verbrauchen. Das vermeidet die häufigste Falle: vollwertige Agenten (und ihre Kosten) zu vervielfachen, obwohl ein einfacher temporärer Unteragent ausgereicht hätte. Wenn Sie sich näher mit der Budgetseite befassen möchten, erläutert der folgende Artikel die tatsächlichen Kostenposten eines KI-Agenten im Unternehmen, und der Artikel zur ROI-Messung hilft Ihnen, nach der Einführung zu prüfen, ob sich die Investition gelohnt hat.