Multi-Agent: Wann ist es sinnvoll — und wann nicht?

Im letzten Post haben wir dem Agenten ein Fundament gegeben — LangGraph für Struktur, MCP für standardisierte Tools. Das Ergebnis: ein einzelner Agent, der verschiedene Tool-Quellen kombiniert und dessen Kontrollfluss transparent und testbar ist.

Aber irgendwann reicht ein einzelner Agent nicht mehr aus.

Nicht weil er zu wenig Tools hat, sondern weil die Aufgabe so komplex wird, dass ein einzelnes LLM zu viele Rollen gleichzeitig übernehmen muss. Es soll analysieren, Maßnahmen ableiten und einen Bericht schreiben — alles in einem Kontext. Je mehr Verantwortung man einem Agent gibt, desto größer wird der Kontext und desto wahrscheinlicher wird Halluzination.

Die Frage ist weniger “brauche ich Multi-Agent?” — sondern: Wann sollte man die Aufgabe auf mehrere Agenten verteilen?

Wann mehrere Agenten Sinn machen

Folgende Kriterien können bei der Entscheidung helfen:

Sub-Aufgaben sind komplex genug. Wenn eine Teilaufgabe eigene LLM-Calls, eigene Tools und einen eigenen State rechtfertigt, ist sie ein Kandidat für einen eigenen Agenten. Eine einfache Textformatierung gehört nicht in einen separaten Agenten — eine Log-Analyse mit Tool-Zugriff schon.

Klare Abgrenzung. Die Rollen müssen sich sauber trennen lassen. Wenn zwei Agenten ständig denselben State lesen und schreiben müssen, ist die Trennung künstlich.

Spezialisierung reduziert Halluzination. Ein Agent, der nur Log-Analyse macht, hat einen kleineren Kontext als einer, der analysieren, Maßnahmen ableiten und berichten muss. Weniger Kontext, weniger Halluzination.

Parallelisierung. Wenn Sub-Aufgaben unabhängig voneinander laufen können, spart die Aufteilung Zeit.

Wiederverwendbarkeit. Ein spezialisierter Agent — etwa ein MLflow-Agent, der Experimente analysiert — kann in verschiedene Multi-Agenten-Systeme eingebunden sein. Die Integration kann auf Graph-Ebene sein oder lose gekoppelt über eine REST-Schnittstelle — im Grunde ein Microservice, der zufällig ein Agent ist.

Wenn keines dieser Kriterien zutrifft: Ein Agent mit mehr Tools ist einfacher, günstiger und leichter zu debuggen.

Orchestrierung — ein Spektrum an Möglichkeiten

Die Koordination mehrerer Agenten ist keine binäre Entscheidung, sondern ein Spektrum — von maximaler Kontrolle bis maximaler Flexibilität.

Handoff steht am kontrollierten Ende. Die Reihenfolge der Agenten ist zur Design-Zeit festgelegt — feste Graph-Kanten, kein Routing-LLM. Agent A übergibt an Agent B, B an C. Deterministisch, günstig, gut zu debuggen. Aber jede Abweichung vom Happy Path muss in den Kanten kodiert sein.

Supervisor balanciert Kontrolle und Flexibilität. Ein zentrales Routing-LLM entscheidet nach jedem Sub-Agenten, wer als nächstes dran ist. Die Reihenfolge kann vom Input abhängen — der Supervisor kann Schritte überspringen oder wiederholen. Dafür kostet jede Routing-Entscheidung einen zusätzlichen LLM-Call.

Swarm steht am flexiblen Ende. Jeder Agent entscheidet selbst, an wen er übergibt — über transfer_to_X-Tool-Calls. Das Routing emergiert aus Einzelentscheidungen. Kein zentraler Überblick, kein fixer Graph. Mächtig, aber schwer zu debuggen.

Die Wahl hängt davon ab, ob die Reihenfolge der Schritte zur Design-Zeit bekannt ist. Ist sie bekannt → Handoff. Variiert sie je nach Input → Supervisor. Ist sie nicht vorhersehbar und dynamisch → Swarm.

Erkenntnisse, die geblieben sind

Structured Output gegen Pipeline-Halluzination. In einem Multi-Agent-System ist der Output eines Agenten der Input des nächsten. Wenn der erste Agent halluziniert — etwa Befehle erfindet, die nicht im Runbook stehen — pflanzt sich der Fehler durch die gesamte Pipeline fort. Die Lösung: Jeder Agent, dessen Output weiterverarbeitet wird, gibt nicht freien Text zurück, sondern ein typisiertes Pydantic-Modell. Das LLM kann nur ausfüllen, was das Schema erlaubt. Halluzinierte Felder haben strukturell keinen Platz. Das geht über Multi-Agent hinaus — überall, wo LLM-Output weiterverarbeitet wird, reduziert ein Schema die Angriffsfläche für Halluzination.

Multi-Agent-Systeme haben ein anderes Ausführungsprofil. Mehr LLM-Calls (Routing + Sub-Agenten), aber potenziell weniger Tokens pro Call durch kleinere Kontexte. Ob das netto teurer oder günstiger ist, hängt vom Setup ab. In unserem Beispiel hat der Supervisor vier LLM-Calls nur fürs Routing verbraucht — bei einem Workflow, der fast immer dieselbe Reihenfolge durchläuft. Ein Handoff wäre effizienter gewesen. Die Empfehlung: messen und in die Entscheidung zwischen Single- und Multi-Agent einfließen lassen.

Non-deterministisches Routing erschwert Debugging. Ein Supervisor kann bei identischem Input unterschiedlich routen. Das macht Reproduzierbarkeit schwierig — sowohl für Tests als auch für die Analyse, wenn etwas schiefgeht. Tracing wird damit zur Pflicht, nicht zur Option.

Ausblick

Multi-Agent-Systeme zeigen deutlich, wo die nächsten Herausforderungen liegen: Wenn Agenten non-deterministisch routen und halluzinieren können, reicht es nicht, sie nur zu orchestrieren. Man muss sie absichern — durch Evaluation, Guardrails und Observability. Genau darum geht es in den nächsten Posts.

Code und Details: Beide Blöcke — Supervisor-Agent mit DevOps Incident-Response und Handoff mit Evaluation-Framework (inkl. Vergleich dreier Pattern) — sind auf GitHub dokumentiert: → agentic-ai / Phase 3: Multi-Agent

Ich bin ML Engineer mit Fokus auf Self-Hosted AI und Datensouveränität. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.