Was ein Multi-Agent-System wirklich ist und was nicht
Ein Multi-Agent-System besteht aus mehreren autonomen, interagierenden Agenten, die sich eine gemeinsame Umgebung teilen. Sie kooperieren, koordinieren oder konkurrieren, um eigene oder gemeinsame Ziele zu erreichen. Der entscheidende Unterschied zum klassischen Ansatz liegt in der Kontrolle. Statt einer zentralen Instanz, die alles entscheidet, ist die Kontrolle verteilt. Jeder Agent verantwortet einen Teil. Stellen Sie sich ein gut eingespieltes Team vor, in dem jeder seine Rolle kennt.
Der Gegenpol ist der Single-Agent. Er arbeitet isoliert, mit einer einzigen zentralen Entscheidungsinstanz. Das klassische Beispiel ist eine Schach-KI: Sie sieht das Brett, bewertet Züge, entscheidet allein. Niemand redet ihr rein, sie verhandelt mit niemandem.
Was ein MAS attraktiv macht, sind drei Eigenschaften. Es ist flexibel, weil sich Rollen und Zuständigkeiten anpassen lassen. Es ist robust, weil der Ausfall eines Agenten nicht zwingend das ganze System lahmlegt. Und es skaliert, weil sich Last auf mehrere spezialisierte Einheiten verteilen lässt. Klingt gut. Ist aber nicht umsonst.
Der Preis ist ein deutlich komplexeres Design. Sobald Agenten zusammenarbeiten, brauchen sie robuste Kommunikations- und Koordinationsprotokolle. Genau diese Mechanik ist es, die in der Praxis schiefgeht. Tiefer in die einzelnen Architektur-Muster gehe ich im Leitfaden Multi-Agent-Systeme und im Detailbeitrag zu den Multi-Agent-Topologien.
Wie ein einzelner Agent intern denkt: das BDI-Modell
Bevor wir mehrere Agenten verbinden, lohnt ein Blick darauf, wie ein einzelner Agent überhaupt zu Entscheidungen kommt. Ein etabliertes Erklärungsmodell stammt von Michael Bratman: die BDI-Architektur. BDI steht für Beliefs, Desires, Intentions.
Beliefs sind die Überzeugungen des Agenten über die Welt, über sich selbst und über andere Agenten. Sie können falsch sein und sich ändern. Desires oder Goals sind die Motivationen, die der Agent verfolgt. Ein Goal ist dabei ein aktiv verfolgtes, in sich konsistentes Desire. Intentions sind das, worauf sich der Agent festgelegt hat und dessen Ausführung bereits begonnen hat. Dazu kommen Plans, also konkrete Aktionssequenzen, und Events als Auslöser.
Der Kerngedanke ist die Trennung von Plan-Auswahl und Plan-Ausführung. Der Agent balanciert zwischen Nachdenken, was zu tun ist, und Handeln. Diese Trennung ist auch im LLM-Zeitalter relevant: Ein moderner Agent, der erst einen Plan entwirft und ihn dann Schritt für Schritt mit Tools abarbeitet, folgt im Grunde diesem Muster.
# BDI-Schleife, stark vereinfacht
beliefs = sense(environment) # Überzeugungen aktualisieren
goal = select_goal(beliefs) # konsistentes Desire wählen
plan = deliberate(beliefs, goal) # Plan auswählen (was tun)
for action in plan: # Plan ausführen (tun)
beliefs = sense(environment)
if not still_valid(plan, beliefs):
break # Welt hat sich geändert: neu planen
execute(action)
Wer versteht, dass schon ein einzelner Agent diesen Deliberations-Aufwand hat, ahnt, was passiert, wenn fünf davon gleichzeitig denken und handeln.
Reden, ausschreiben, einigen: wie Agenten sich koordinieren
Sobald Agenten zusammenarbeiten, brauchen sie eine gemeinsame Sprache und Spielregeln. Das ist kein neues Problem. Schon ab 1996 gab es mit FIPA-ACL und KQML standardisierte Agent Communication Languages, die auf der Sprechakttheorie von Austin und Searle aufbauen. Nachrichten sind dort Performative, also illokutionäre Akte: INFORM, REQUEST, AGREE, PROPOSE. Darauf setzen Konversationsprotokolle wie request-inform-agree oder subscribe-notify auf.
Für die Aufgabenverteilung ist das Contract Net Protocol von Reid G. Smith aus dem Jahr 1980 bis heute prägend. Ein Manager schreibt eine Aufgabe an mehrere Agenten aus, die Agenten machen Angebote, der Manager vergibt den Zuschlag. Das ähnelt einer verdeckten Auktion. Vergebene Aufgaben können weiter zerlegt und untervergeben werden.
In der LLM-Welt haben sich zwei Protokolle herauskristallisiert, die man nicht verwechseln sollte. Das Model Context Protocol (MCP) bindet einen Agenten an Werkzeuge und Datenquellen an. Agent-to-Agent (A2A) regelt die direkte Zusammenarbeit zwischen Agenten. Merksatz: MCP ist Agent-an-Werkzeug, A2A ist Agent-an-Agent. Wie diese beiden zusammenspielen, beschreibe ich ausführlich im Beitrag zur Agenten-Kommunikation mit MCP und A2A.
Die folgenden Bausteine bilden den Kern jeder MAS-Koordination:
- Kommunikationssprache: FIPA-ACL/KQML klassisch, A2A für moderne LLM-Agenten
- Werkzeug-Anbindung: MCP für den Zugriff auf Tools und Datenquellen
- Aufgabenverteilung: Contract Net Protocol mit Manager, Bids und Zuschlag
- Einigung: Auktionsmodelle und Konsens-Algorithmen
Das unterschätzte Problem: Agenten, die einander missverstehen
Hier wird es für mich besonders spannend, weil es ein Problem betrifft, das mit klassischen verteilten Systemen wenig zu tun hat. In einem normalen Cluster sind Konflikte syntaktisch: Zwei Knoten schreiben auf dasselbe Feld, ein Lock-Mechanismus löst das. Bei kooperierenden LLM-Agenten sind die Konflikte semantisch.
Jeder Agent arbeitet in seinem eigenen Kontextfenster mit seinem eigenen Prompt-Framing. Dadurch entwickeln zwei Agenten leicht unterschiedliche Interpretationen desselben geteilten Ziels, ohne dass es einen Mechanismus gäbe, das zu bemerken. Die Forschung nennt das Semantic Intent Divergence. Das jüngere Semantic Consensus Framework (arXiv, 2026) setzt genau dort an: eine prozessbewusste Middleware mit Komponenten wie einem Semantic Intent Graph, einer Conflict Detection Engine und einem Drift Monitor, protokoll-agnostisch und kompatibel zu MCP und A2A.
Wie ernst das in der Praxis ist, zeigen Zahlen aus demselben Umfeld, die ich bewusst als Studienschätzung einordne, nicht als hartes Benchmark. Laut dem Semantic-Consensus-Paper liegen die Produktions-Failure-Rates für Agentensysteme zwischen 41 und 86,7 Prozent. Bemerkenswert ist die Ursache: Rund 79 Prozent der Fehler stammen demnach aus Spezifikations- und Koordinationsproblemen, nicht aus mangelnder Modell-Fähigkeit. Gleichzeitig wollen laut derselben Quelle 85 Prozent der Unternehmen in drei Jahren auf agentische KI setzen, während 76 Prozent angeben, ihre Infrastruktur trage das noch nicht.
Aus meiner Projekterfahrung deckt sich das. Wenn ein Agentensystem scheitert, liegt es selten am Modell. Es liegt daran, dass niemand sauber definiert hat, wer für was zuständig ist.
Die ehrliche Entscheidungs-Heuristik: MAS oder ein Agent mit Tools?
Jetzt zur Kernfrage. Mein Rat: Behandeln Sie das Multi-Agent-System nicht als Standardlösung, sondern als Eskalationsstufe. Sie greifen erst dann dazu, wenn die Aufgabe es erzwingt.
Ein Multi-Agent-System ist sinnvoll, wenn mehrere der folgenden Bedingungen gleichzeitig zutreffen. Die Aufgabe ist zu gross oder zu komplex, als dass ein einzelner Agent sie im Kontext halten könnte. Sie zerfällt in klar trennbare Rollen, die wenig miteinander reden müssen. Teilaufgaben lassen sich echt parallelisieren, sodass mehrere Agenten gleichzeitig arbeiten. Oder es sind mehrere getrennte Systeme und Datenquellen im Spiel, die unterschiedliche Spezialisierung verlangen. Typische Felder sind Energiemanagement im Smartgrid mit P2P-Handel, Multi-Robot-Teams in der Robotik, automatisierter Handel oder mehrstufige Geschäftsprozesse wie lange Kundenservice-Ketten.
Ein Single-Agent mit gutem Tool-Zugriff reicht dagegen in der grossen Mehrheit der Fälle. Wenn die Aufgabe in ein Kontextfenster passt, wenn eine Entscheidungsinstanz genügt, wenn die Schritte sequenziell ablaufen, dann ist ein zusätzlicher Agent nur eine weitere Fehlerquelle. Ein einzelner Agent, der über MCP auf Suche, Datenbank und API zugreift, deckt erstaunlich viel ab, ohne dass Sie ein Koordinationsprotokoll betreiben müssen.
Ein kompakter Entscheidungspfad in Pseudocode:
WENN Aufgabe passt in einen Kontext UND eine Entscheidungsinstanz reicht
-> Single-Agent mit Tools (MCP)
SONST WENN Rollen klar trennbar UND parallelisierbar
UND mehrere Systeme/Datenquellen im Spiel
-> Multi-Agent-System (mit Koordinationsprotokoll + Observability)
SONST
-> Single-Agent, bis die Komplexität es wirklich erzwingt
Diese Bedingungen sollten den Ausschlag geben, nicht der Architektur-Trend:
- Aufgabe zu gross für ein Kontextfenster
- klar trennbare, wenig gekoppelte Rollen
- echte Parallelisierbarkeit der Teilaufgaben
- mehrere getrennte Systeme oder Datenquellen
- mehr als ein Single-Agent vertretbar gescheitert ist
Wenn es doch MAS wird: Topologie, Grenzen und Governance
Haben Sie sich für ein Multi-Agent-System entschieden, steht die nächste Frage an: Wie sind die Agenten angeordnet? Üblich sind ein zentralisierter Supervisor nach dem Hub-and-Spoke-Muster, ein dezentrales Peer-to-Peer-Netz, eine hierarchische Baumstruktur mit Meta-Agenten oder dynamisch-adaptive Topologien, die sich erst zur Laufzeit formen. Frameworks gehen das unterschiedlich an: LangGraph modelliert Graphen als Zustandsmaschinen mit conditional edges, CrewAI setzt auf rollenbasiertes Teamplay, AutoGen auf konversationsgesteuerte Koordination, MetaGPT auf standardisierte Arbeitsprozesse über Dokumentenaustausch. Den Vergleich vertiefe ich im Beitrag zum Multi-Agent-Frameworks-Vergleich.
Rechnen Sie mit zwei strukturellen Hürden. Erstens die Nichtstationarität: Weil alle Agenten gleichzeitig lernen und handeln, ändert sich die Umgebung ständig, jeder zielt auf ein bewegliches Ziel. Zweitens die Komplexitäts-Explosion mit jeder zusätzlichen Agenteneinheit. Dazu kommen Sicherheitsfragen, etwa Prompt-Injection über Agentengrenzen hinweg. Diese und weitere Stolpersteine behandle ich im Beitrag zu den Herausforderungen von Multi-Agent-Systemen.
Im DACH-Mittelstand kommt eine Dimension hinzu, die gern übersehen wird. Mehr Agenten bedeuten mehr Datenflüsse und mehr Autonomie. Damit rücken DSGVO-Prinzipien wie Zweckbindung und Datenminimierung in den Vordergrund. Der EU AI Act verlangt mit Artikel 50 ab dem 2. August 2026 eine Kennzeichnung von KI-Interaktionen. Audit-Trails, Tracing und Observability sind dann keine Kür mehr, sondern Pflicht. Mehr zum agentischen Grundgerüst finden Sie im Überblick zu KI-Agenten.
Mein abschliessender Rat fällt nüchtern aus. Bauen Sie das einfachste System, das die Aufgabe löst. Wenn das ein einzelner Agent mit drei sauber angebundenen Tools ist, dann ist das die richtige Architektur, auch wenn es weniger beeindruckend klingt. Multi-Agent wird dann zur Stärke, wenn die Aufgabe es verlangt, nicht der Pitch.
Sie planen ein Agentensystem und sind unsicher über die Architektur?
Genau hier helfe ich. Gemeinsam klären wir, ob Ihre Aufgabe ein Multi-Agent-System erzwingt oder ob ein gut gebauter Single-Agent günstiger und stabiler ans Ziel kommt, inklusive sauberer Tool-Anbindung, Governance und Observability. Schreiben Sie mir über das Kontaktformular, und wir schauen uns Ihren konkreten Fall an.
FAQ
Häufige Fragen
Was ist der Unterschied zwischen einem Multi-Agent-System und einem Single-Agent?
Ein Single-Agent ist eine isolierte, zentrale Entscheidungsinstanz, etwa eine Schach-KI. Ein Multi-Agent-System besteht aus mehreren autonomen Agenten in einer gemeinsamen Umgebung mit verteilter Kontrolle und spezialisierten Rollen. Der Kernunterschied ist die Kontrolle: zentral beim Single-Agent, verteilt im MAS.
Wann sollte ich ein Multi-Agent-System einsetzen?
Wenn die Aufgabe für einen einzelnen Agenten zu gross oder zu komplex ist, sich in klar trennbare Rollen zerlegen lässt, echt parallelisierbar ist oder über mehrere getrennte Systeme und Datenquellen läuft. Treffen diese Punkte nicht zu, ist ein Single-Agent mit Tools meist die robustere und günstigere Wahl.
Reicht für die meisten Anwendungsfälle nicht ein einzelner Agent mit Tools?
Ja. In der grossen Mehrheit der Fälle deckt ein einzelner Agent, der über das Model Context Protocol auf Suche, Datenbanken und APIs zugreift, die Aufgabe ab, ohne ein Koordinationsprotokoll zu erfordern. Jeder zusätzliche Agent ist auch eine zusätzliche Fehlerquelle, die sich rechtfertigen muss.
Was bedeutet das BDI-Modell?
BDI steht für Beliefs, Desires und Intentions und beschreibt, wie ein einzelner Agent intern zu Entscheidungen kommt. Beliefs sind seine Überzeugungen über die Welt, Desires seine Ziele, Intentions die Vorhaben, auf die er sich festgelegt hat. Der Kern ist die Trennung von Plan-Auswahl und Plan-Ausführung.
Warum scheitern so viele Multi-Agent-Systeme in der Produktion?
Laut dem Semantic-Consensus-Paper stammen rund 79 Prozent der Fehler aus Spezifikations- und Koordinationsproblemen, nicht aus mangelnder Modell-Fähigkeit. Diese Zahl ist eine Studienschätzung, kein hartes Benchmark. Ein häufiger Grund sind semantische Konflikte: Agenten interpretieren dasselbe Ziel unterschiedlich, ohne es zu merken.
Was ist der Unterschied zwischen MCP und A2A?
Das Model Context Protocol bindet einen Agenten an Werkzeuge und Datenquellen an, also Agent-an-Werkzeug. Agent-to-Agent regelt die direkte Zusammenarbeit zwischen mehreren Agenten, also Agent-an-Agent. In einem Multi-Agent-System kommen beide oft kombiniert zum Einsatz.