Multi-Agenten-Systeme im Unternehmensumfeld

Ein einzelner generalistischer Agent kann viele Aufgaben gut erledigen – aber je komplexer die Aufgabe, desto mehr leidet die Qualität. Lange Prompts mit vielen Anweisungen führen zu Verwässerung, Vergessen von Detailregeln, längeren Antwortzeiten. Das ist ein bekanntes Phänomen großer Sprachmodelle: Mehr Aufgaben gleichzeitig senken die Qualität jeder einzelnen.

Multi-Agenten-Systeme adressieren dieses Problem durch Spezialisierung. Ein Supervisor-Agent koordiniert, ein Recherche-Agent sammelt Informationen, ein Compliance-Agent prüft Regeln, ein Schreib-Agent formuliert die Antwort. Jeder Agent hat einen klar abgegrenzten Aufgabenbereich, eigene Tools, eigene Wissensbasis und eigene Erfolgsmetriken.

Der Effekt ist messbar: Spezialisierte Agenten in einem gut orchestrierten Verbund liefern um 15–25 Prozent höhere Qualität als ein generalistischer Agent gleicher Größe. Sie sind besser wartbar, leichter zu testen und einfacher zu erweitern – aber auch komplexer in Aufbau und Betrieb.

Die Entscheidung zwischen Single- und Multi-Agent ist eine Architektur-Entscheidung mit Folgen. Wir empfehlen Multi-Agent, wenn drei oder mehr der folgenden Kriterien zutreffen:

Das häufigste und einfachste Muster: Ein zentraler Supervisor-Agent empfängt die Anfrage, klassifiziert sie und delegiert an spezialisierte Sub-Agenten. Diese arbeiten ihre Teilaufgaben ab und geben das Ergebnis an den Supervisor zurück, der die Gesamtantwort komponiert und an den Nutzer ausliefert.

Vorteile: Klare Verantwortlichkeiten, einfache Steuerung, gut auditierbar. Nachteile: Supervisor wird schnell zum Engpass und zum Bottleneck. Bei vielen Sub-Agenten oder hoher Last skaliert das Muster nicht beliebig.

Praxisbeispiel: Ein Versicherer setzt einen Supervisor-Agent für die Schadenbearbeitung ein. Er klassifiziert die Schadensmeldung, ruft den Recherche-Agent (Vertragsdaten), den Bewertungs-Agent (Schadenshöhe), den Compliance-Agent (Betrugsprüfung) und den Kommunikations-Agent (Antwort) auf. Der Supervisor stellt das Ergebnis zusammen und legt es dem menschlichen Sachbearbeiter zur Freigabe vor.

Bei stark sequenzieller Arbeit eignet sich ein Pipeline-Muster: Agent A leitet das Ergebnis an Agent B weiter, der an Agent C usw. Jeder Agent in der Pipeline hat klare Eingabe- und Ausgabe-Spezifikationen. Es gibt keinen Supervisor – die Pipeline-Logik ist in der Architektur fixiert.

Vorteile: Hohe Vorhersagbarkeit, einfaches Debugging, gute Performance. Nachteile: Wenig Flexibilität für ad-hoc-Anforderungen, jede Erweiterung verändert die Pipeline-Struktur.

Praxisbeispiel: Eine Buchhaltung verarbeitet eingehende Rechnungen mit einer Pipeline aus OCR-Agent → Klassifikations-Agent → Validierungs-Agent → Buchungs-Agent → Freigabe-Agent. Jeder Schritt ist spezialisiert, das Ergebnis ist deterministisch.

Ein moderneres Muster: Eine Anfrage wird an einen „Marketplace“ gestellt, auf dem mehrere spezialisierte Agenten ihre Eignung „bewerben“. Der Auftrag wird an den Agenten mit der höchsten Eignung vergeben. Der Auftraggeber prüft das Ergebnis und akzeptiert oder weist zurück.

Vorteile: Hohe Flexibilität, automatische Auswahl des besten Agenten, einfache Erweiterbarkeit (neuer Agent = neuer „Anbieter“). Nachteile: Höhere Komplexität, schwierigere Erklärbarkeit, oft Mehrkosten durch parallele Bewertung.

Praxisbeispiel: Eine technische Hotline nutzt einen Marketplace mit 12 spezialisierten Agenten (je nach Produktlinie und Fehlerart). Der Marketplace wählt automatisch den für die konkrete Anfrage am besten passenden Agenten – mit messbar besserer Trefferquote.

Bei komplexen Domänen lohnt sich eine mehrstufige Hierarchie: Ein Top-Level-Manager delegiert an Mid-Level-Agenten, die ihrerseits Worker-Agenten steuern. Jede Ebene hat einen anderen Abstraktionsgrad – der Top-Level denkt in Geschäftsprozessen, die Worker in einzelnen Tool-Aufrufen.

Vorteile: Skaliert für sehr komplexe Domänen, ermöglicht Wiederverwendung von Worker-Agenten in mehreren Prozessen. Nachteile: Hohe Initial-Komplexität, lange Latenzen durch mehrere Ebenen, schwierigere End-to-End-Auditierung.

Praxisbeispiel: Ein international tätiges Industrieunternehmen koordiniert die Lieferkette mit einer dreistufigen Agenten-Hierarchie: Top-Level (globale Lieferplanung), Mid-Level (regionale Steuerung), Worker (einzelne Lieferanten-Kommunikation). Die Architektur ermöglicht eine konsistente Steuerung über mehrere Standorte hinweg.

Das experimentellste Muster: Mehrere gleichrangige Agenten arbeiten ohne zentrale Steuerung an einem Problem. Sie kommunizieren miteinander, teilen Zwischenergebnisse, einigen sich auf eine Lösung. Inspirationen kommen aus der Schwarmintelligenz und kollektiven Entscheidungsfindung.

Vorteile: Hohe Robustheit, kein Single-Point-of-Failure, gut für explorative Aufgaben. Nachteile: Schwer kontrollierbar, hohe Token-Kosten durch viel Kommunikation, schwer auditierbar.

Schwarm-Muster sind in produktiven Unternehmens-Setups noch selten. Sie eignen sich für Forschung, kreative Aufgaben oder Szenario-Analyse, aber nicht für streng regulierte Geschäftsprozesse.

Das Herzstück jedes Multi-Agenten-Systems sind die Kommunikationsprotokolle. Ohne klare Schnittstellen zwischen den Agenten entsteht Chaos. Wir empfehlen ein strukturiertes Nachrichten-Format mit folgenden Pflicht-Feldern: Absender, Empfänger, Aufgabentyp, Eingabe-Daten (typisiert), Erwartete Ausgabe-Spezifikation, Korrelations-ID, Zeitstempel.

Daneben braucht es ein gemeinsames Daten-Schema (z.B. Customer, Order, Document), das von allen Agenten verstanden wird. Dieses Schema ist die „lingua franca“ des Multi-Agenten-Systems. Änderungen am Schema sind versionsbehaftet und werden über die Plattform ausgerollt.

Asynchrone Kommunikation (Message Queue, Event Bus) skaliert besser als synchrone (HTTP). Bei kritischer Latenz kann synchron sinnvoll sein; bei robustem Throughput und Resilienz ist asynchron meistens besser.

Wenn ein Agent eine Aufgabe nicht abschließen kann, muss er sie sauber übergeben – an einen anderen Agenten oder an einen Menschen. Ein gutes Handover-Protokoll umfasst: vollständigen Kontext (was wurde versucht, was hat funktioniert, was nicht), eindeutige Empfehlung (wer/was als Nächstes), strukturierte Daten für nahtloses Weiterarbeiten, klare Zeitstempel und Audit-Information.

Im Übergang an Menschen ist die Anschlussfähigkeit zentral: Der Mensch will nicht von vorn anfangen, sondern bei dem ansetzen, was der Agent bereits geleistet hat. Eine gute UI zeigt Kontext, Verlauf und Empfehlung übersichtlich an.

Eskalationsregeln sollten explizit definiert sein: Bei welcher Unsicherheit, welchem Risiko, welcher Komplexität wird eskaliert? Diese Regeln werden in den Eval-Pipelines getestet und über den Lebenszyklus angepasst.

Zur Implementierung von Multi-Agenten-Systemen gibt es mittlerweile mehrere bewährte Frameworks. Die wichtigsten: LangGraph (graph-basierte Orchestrierung mit klarer State-Machine), AutoGen (Microsoft, fokus auf konversationelle Multi-Agent-Patterns), CrewAI (Rollen-basiert, einfacher Einstieg), Semantic Kernel (Microsoft, integriert mit M365-Welt), eigene Implementierungen mit FastAPI und Message-Queue.

Wahl des Frameworks hängt ab von: Komplexität der Orchestrierung, Integration mit bestehender Infrastruktur, Sprache (Python vs. TypeScript), Anforderungen an Auditierung und Observability. Mehr Detail im Frameworks-Vergleich.

In einem Multi-Agenten-System ist Observability noch wichtiger als bei einem Single-Agent. Sie müssen jede Anfrage über alle beteiligten Agenten hinweg nachverfolgen können – sonst sind Fehler nicht diagnostizierbar.

Mindest-Bausteine: End-to-End-Trace mit Korrelations-ID, Latenz-Messung pro Agent und Übergang, Token-Kosten pro Agent, Erfolgs- und Eskalationsquote pro Agent, Eval-Pipeline für jede Agent-Rolle separat.

Tools: LangSmith, Langfuse, Phoenix, Arize, OpenTelemetry-basierte Lösungen. Die Wahl hängt von der bestehenden Observability-Landschaft und den Compliance-Anforderungen ab.

Aus vielen Implementierungen kennen wir wiederkehrende Probleme bei Multi-Agenten-Systemen: