Zwei Agenten, ein Ziel, zwei Wahrheiten
Stellen Sie sich zwei Agenten in einem Bestellprozess vor. Der eine soll eine Rückerstattung „bearbeiten", der andere soll sie „prüfen". Beide bekommen dasselbe Ziel im Prompt. Der eine versteht „bearbeiten" als sofort auszahlen. Der andere blockiert die Auszahlung, weil er „prüfen" als Freigabevorbehalt liest. Keiner von beiden merkt, dass sie aneinander vorbeireden. Das Ergebnis: ein Konflikt, der nicht technisch ist, sondern inhaltlich.
Genau hier setzt das Thema Agenten-Kommunikation an. Sobald mehrere autonome Agenten in einer gemeinsamen Umgebung kooperieren, koordinieren oder konkurrieren, lösen sie zusammen Aufgaben, die für einen einzelnen Agenten zu groß wären. Der Preis dafür ist komplexeres Design, denn ohne robuste Kommunikations- und Koordinationsprotokolle wird aus dem gut eingespielten Team schnell ein Haufen, der sich gegenseitig blockiert. Wer tiefer in die Architektur solcher Systeme einsteigen will, findet die Grundlagen im Leitfaden Multi-Agent-Systeme.
Sprechakte: warum Agenten Verben brauchen, keine Sätze
Die klassische Antwort auf das Problem stammt nicht aus der LLM-Ära. Schon ab 1996 gab es mit KQML und FIPA-ACL standardisierte Agentensprachen, sogenannte Agent Communication Languages. Ihre theoretische Basis ist die Sprechakttheorie von Austin (1962) und Searle (1969). Die Kernidee: Eine Nachricht ist nicht nur Information, sondern eine Handlung. Wenn ich sage „Ich verspreche, das zu liefern", dann beschreibe ich nichts, ich tue etwas.
Übertragen auf Agenten heißt das: Jede Nachricht trägt ein Performativ, also einen illokutionären Akt, der die Absicht eindeutig macht. Vier davon prägen den Alltag.
Das Schöne daran: Der Empfänger muss den Inhalt nicht erst interpretieren, um die Absicht zu kennen. Ein REQUEST ist immer eine Bitte, egal was im Inhaltsfeld steht. Diese Trennung von Absicht und Inhalt ist der eigentliche Trick, und sie ist heute genauso relevant wie vor knapp drei Jahrzehnten.
- INFORM teilt dem Empfänger einen Fakt mit.
- REQUEST bittet um eine Handlung.
- PROPOSE macht ein Angebot, über das verhandelt werden kann.
- AGREE signalisiert Zustimmung zu einer vorher angefragten Handlung.
Von der Einzelnachricht zum Protokoll
Eine einzelne Nachricht reicht selten. Echte Zusammenarbeit ist ein Hin und Her, und dafür gibt es Konversationsprotokolle. Sie legen fest, welche Nachricht auf welche folgen darf. Drei klassische Muster tauchen immer wieder auf: request-inform-agree für einfache Auftragsketten, subscribe-notify für Ereignis-Abonnements, und das Contract Net Protocol für die Aufgabenverteilung. Implementiert wurde das jahrelang in Frameworks wie JADE für Java und SPADE für Python.
Das Contract Net Protocol von Reid G. Smith aus dem Jahr 1980 lohnt einen genaueren Blick, weil es bis heute trägt. Es funktioniert wie eine Ausschreibung. Ein Manager-Agent schreibt eine Aufgabe an mehrere mögliche Auftragnehmer aus. Diese antworten mit Geboten. Der Manager vergleicht und vergibt den Zuschlag. Das kommt einer versiegelten Auktion nahe. Und es ist rekursiv: Ein Agent, der einen Zuschlag erhalten hat, darf die Aufgabe weiter zerlegen und Teile davon selbst wieder ausschreiben. Subcontracting, ganz wie in einer echten Lieferkette.
Aus meiner Projekterfahrung ist dieses Muster bemerkenswert robust, weil es ohne zentrale Allwissenheit auskommt. Der Manager muss nicht wissen, wer am besten geeignet ist. Er fragt einfach, und die Agenten melden sich selbst, wenn sie können. Das skaliert besser als ein Orchestrator, der alle Fähigkeiten aller Worker kennen muss.
MCP und A2A: zwei Standards, zwei Aufgaben
In der heutigen LLM-Welt haben sich zwei moderne Standards herausgebildet, und die wichtigste Erkenntnis vorweg: Sie konkurrieren nicht, sie ergänzen sich. Sie lösen unterschiedliche Probleme.
MCP, das Model Context Protocol, regelt die Anbindung von Werkzeugen. Wenn ein Agent eine Datenbank abfragen, eine Datei lesen oder eine Funktion aufrufen soll, läuft das über MCP. Der Agent spricht mit einem Tool oder einer Datenquelle. Wie das im Unternehmenskontext herstellerunabhängig und DSGVO-konform an Bestandssysteme andockt, behandelt der MCP-Enterprise-Leitfaden im Detail.
A2A, Agent-to-Agent, regelt die direkte Zusammenarbeit zwischen Agenten. Wenn ein Recherche-Agent einem Schreib-Agenten ein Zwischenergebnis übergibt und der wiederum einen Lektorats-Agenten beauftragt, dann ist das A2A. Hier spricht Agent mit Agent, auf Augenhöhe.
Der Merksatz, den ich Teams gerne mitgebe: MCP ist Agent-an-Werkzeug, A2A ist Agent-an-Agent. Ein einziges System nutzt fast immer beides. Der Agent holt sich über MCP Daten aus dem ERP und reicht das Ergebnis über A2A an den nächsten Agenten weiter. Verwechselt man die beiden Ebenen, baut man entweder Werkzeuge, die wie Agenten tun, oder Agenten, die wie dumme Funktionen behandelt werden. Beides rächt sich später.
- MCP: ein Agent greift auf Tools und Datenquellen zu.
- A2A: mehrere Agenten arbeiten direkt zusammen und reichen Aufgaben weiter.
- Beide Protokolle laufen typischerweise im selben System parallel.
Wie eine A2A-Nachricht konkret aussieht
Genug Theorie. So sieht eine strukturierte Nachricht im Geiste von FIPA-ACL und A2A aus, wenn ein Manager-Agent eine Aufgabe an einen Worker delegiert. Beachten Sie, wie das Performativ ganz oben steht und der eigentliche Inhalt sauber davon getrennt in einem typisierten Objekt liegt.
{
"performative": "REQUEST",
"sender": "agent://orchestrator",
"receiver": "agent://refund-worker",
"conversation_id": "conv-4f9a-2026",
"reply_with": "msg-018",
"ontology": "refund-process/v1",
"language": "application/json",
"content": {
"intent": "process_refund",
"order_id": "ORD-55213",
"amount": 149.90,
"currency": "EUR",
"constraints": {
"requires_approval": true,
"max_auto_approve": 100.00
}
}
}
Drei Felder entscheiden über Erfolg oder Missverständnis. Das performative macht die Absicht maschinenlesbar — hier eine Bitte, keine reine Mitteilung. Die conversation_id und reply_with halten den Gesprächsfaden zusammen, sodass die Antwort eindeutig zugeordnet werden kann. Und das ontology-Feld verweist auf ein geteiltes Vokabular. Es legt fest, was process_refund und requires_approval bedeuten sollen. Ohne dieses gemeinsame Vokabular sind wir wieder bei den zwei Agenten vom Anfang, die dasselbe Wort verschieden auslesen.
Die Antwort des Workers folgt demselben Schema, nur mit umgekehrter Richtung und passendem Performativ. Statt REQUEST steht dann AGREE, wenn er die Aufgabe annimmt, oder PROPOSE, wenn er Bedingungen aushandeln will. So entsteht aus einzelnen Nachrichten ein nachvollziehbares Protokoll.
{
"performative": "AGREE",
"sender": "agent://refund-worker",
"receiver": "agent://orchestrator",
"conversation_id": "conv-4f9a-2026",
"in_reply_to": "msg-018",
"content": {
"intent": "process_refund",
"order_id": "ORD-55213",
"action": "queued_for_human_approval",
"reason": "amount_above_auto_threshold"
}
}
Der Worker hat hier die Bedingung aus dem constraints-Block korrekt gelesen und die Auszahlung nicht selbst angestoßen. Genau das ist strukturierte Kommunikation: Die Absicht des Managers kommt unverfälscht an.
Semantic Intent Divergence: das eigentliche Risiko
Warum so viel Aufwand für ein paar JSON-Felder? Weil das Hauptrisiko im Mehr-Agenten-Betrieb nicht technischer Natur ist. In klassischen verteilten Systemen sind Konflikte meist syntaktisch: zwei Prozesse schreiben gleichzeitig auf denselben Wert, und ein Sperrmechanismus löst das. Bei LLM-Agenten ist der Konflikt semantisch.
Das Phänomen heißt Semantic Intent Divergence. Jeder LLM-Agent arbeitet in seinem eigenen Kontextfenster, mit eigenem Prompt-Framing. Dadurch entwickeln kooperierende Agenten unterschiedliche Interpretationen desselben geteilten Ziels, ohne dass ein Mechanismus das erkennt oder auflöst. Zwei Agenten handeln auf verschiedenen Ressourcen und widersprechen sich auf der Ebene der Absicht, nicht auf der Ebene der Bytes. Ein klassischer Lock hilft da nicht, weil gar kein gemeinsamer Wert umkämpft ist.
Die Forschung adressiert das inzwischen direkt. Ein Semantic Consensus Framework, beschrieben in einer Arbeit von 2026, schlägt eine prozessbewusste Middleware vor. Sie besteht aus mehreren Komponenten, darunter ein Semantic Intent Graph, der die Absichten der Agenten explizit modelliert, eine Conflict Detection Engine, die Widersprüche aufspürt, und ein Drift Monitor, der beobachtet, ob Agenten im Verlauf vom ursprünglichen Ziel abweichen. Wichtig für die Praxis: Dieser Ansatz ist protokoll-agnostisch und ausdrücklich mit MCP und A2A kompatibel. Er ersetzt die Protokolle nicht, er legt sich darüber.
Wie ernst das Problem in der Praxis ist, zeigen Zahlen aus derselben Arbeit, die ich bewusst als Studienschätzung framen möchte und nicht als hartes Benchmark. Laut dem Paper liegen die Produktions-Fehlerraten von Agentensystemen zwischen 41 und 86,7 Prozent. Bemerkenswert ist dabei vor allem die Ursache: Rund 79 Prozent der Fehler sollen aus Spezifikations- und Koordinationsproblemen stammen, nicht aus mangelnder Modellfähigkeit. Das Modell ist also selten das Problem. Die Abstimmung ist es.
Strukturierte Kommunikation ist Architektur, nicht Beiwerk
Wer aus diesen Bausteinen ein System baut, merkt schnell: Die Kommunikation ist kein Anhängsel, sie ist die Architektur. Die Topologie entscheidet mit. Ein zentraler Supervisor im Hub-and-Spoke-Muster routet jede Nachricht über sich selbst, ein dezentrales Peer-to-Peer-Netz lässt Agenten direkt reden. Beides hat seine Berechtigung, und beides stellt andere Anforderungen an die Protokolle. Die verschiedenen Topologien für Mehr-Agenten-Systeme gehen darauf im Detail ein.
Auch die Wahl des Frameworks prägt den Kommunikationsstil. AutoGen setzt auf konversationsgesteuerte Koordination, bei der die Agenten sich regelrecht unterhalten und ein Mechanismus pro Zug den nächsten Sprecher wählt. LangGraph modelliert das Ganze als Zustandsmaschine mit bedingten Kanten und deterministischem Routing. MetaGPT lässt Agenten strukturierte Artefakte weiterreichen, fast wie Dokumente in einer Firma. Welcher Stil passt, hängt von der Aufgabe ab — ein Vergleich der Optionen findet sich im Beitrag zu den Multi-Agent-Frameworks im Vergleich.
Mein Rat aus der Praxis: Legen Sie das Nachrichtenschema und die geteilte Ontologie fest, bevor Sie den ersten Agenten bauen. Nicht danach. Ein gemeinsames Vokabular nachträglich einzuziehen, wenn schon fünf Agenten ihre eigenen Auslegungen verfestigt haben, ist deutlich teurer als ein sauberer Vertrag von Anfang an.
Governance: mehr Agenten, mehr Verantwortung
Für den DACH-Mittelstand kommt eine Ebene dazu, die in den Forschungspapieren oft fehlt. Mehr Agenten bedeuten mehr Datenflüsse und mehr Autonomie. Das berührt direkt die DSGVO mit ihren Prinzipien der Zweckbindung und Datenminimierung. Wenn ein Agent über A2A Kundendaten an einen anderen Agenten weiterreicht, muss klar sein, wofür. Strukturierte Nachrichten helfen hier doppelt: Sie machen den Zweck explizit und sie sind protokollierbar.
Dazu kommt der EU AI Act mit seiner Kennzeichnungspflicht nach Artikel 50, die ab dem 2. August 2026 greift. Audit-Trails, Tracing und Observability werden damit von der Kür zur Pflicht. Ein System, dessen Agenten in freiem Text durcheinanderreden, lässt sich kaum auditieren. Eines, das jede Nachricht mit Performativ, Sender, Empfänger und Conversation-ID protokolliert, schon. Strukturierte Kommunikation ist also nicht nur sauberer Code. Sie ist die Voraussetzung dafür, dass Sie später überhaupt nachweisen können, was Ihre Agenten getan haben und warum.
Strukturierte Kommunikation von Anfang an mitdenken
Mehr-Agenten-Systeme scheitern selten am Modell und oft an der Abstimmung. Wer das Nachrichtenschema, die geteilte Ontologie und die Trennung von MCP und A2A früh festlegt, baut ein System, das nicht nur funktioniert, sondern auch auditierbar bleibt. Genau das wird im DACH-Mittelstand mit DSGVO und EU AI Act zur Pflicht.
Sie planen ein System, in dem mehrere KI-Agenten sauber und nachvollziehbar zusammenarbeiten sollen? Lassen Sie uns über Ihr Vorhaben sprechen. Ich helfe Ihnen, die Kommunikationsarchitektur so aufzusetzen, dass sie trägt — technisch und regulatorisch.
FAQ
Häufige Fragen
Was ist der Unterschied zwischen MCP und A2A?
MCP, das Model Context Protocol, verbindet einen Agenten mit Werkzeugen und Datenquellen — etwa einer Datenbank oder einer API. A2A, Agent-to-Agent, verbindet Agenten direkt miteinander für die gemeinsame Bearbeitung einer Aufgabe. Kurz: MCP ist Agent-an-Werkzeug, A2A ist Agent-an-Agent. In der Praxis nutzt ein System fast immer beide gleichzeitig.
Sind FIPA-ACL und KQML heute noch relevant?
Die konkreten Implementierungen wie JADE und SPADE spielen im LLM-Alltag kaum noch eine Rolle. Die zugrunde liegenden Konzepte aber sehr wohl. Performative wie INFORM und REQUEST, die Trennung von Absicht und Inhalt und Konversationsprotokolle wie das Contract Net Protocol finden sich in moderner Form direkt in der Logik von A2A wieder. Das Vokabular ist neu, das Denken dahinter ist erprobt.
Was bedeutet Semantic Intent Divergence?
Es beschreibt das Phänomen, dass kooperierende LLM-Agenten dasselbe geteilte Ziel unterschiedlich auslegen, weil jeder in seinem eigenen Kontextfenster arbeitet. Anders als klassische Konflikte in verteilten Systemen ist dieser Konflikt nicht syntaktisch, sondern semantisch — die Agenten widersprechen sich auf der Ebene der Absicht. Strukturierte Nachrichten mit geteilter Ontologie und spezialisierte Frameworks wie das Semantic Consensus Framework sollen das eindämmen.
Brauche ich für ein kleines Agentensystem überhaupt ein Protokoll?
Sobald mehr als zwei Agenten beteiligt sind oder ein Agent Aufgaben an andere übergibt, lohnt sich ein festes Nachrichtenschema. Es kostet am Anfang etwas Disziplin, verhindert aber genau die teuren Missverständnisse, die laut Studien den Großteil der Fehler in Produktionssystemen ausmachen. Bei einem einzelnen Agenten mit Werkzeugen reicht oft MCP allein.
Wie hängen Kommunikation und EU AI Act zusammen?
Der EU AI Act verlangt ab August 2026 unter anderem die Kennzeichnung von KI nach Artikel 50 und allgemein nachvollziehbare Systeme. Strukturierte Agenten-Kommunikation mit protokollierten Nachrichten ist die technische Grundlage für Audit-Trails. Ein System, das jede Nachricht typisiert und mit Conversation-ID festhält, lässt sich prüfen — eines mit freiem Textaustausch zwischen Agenten kaum.
Welche Rolle spielt das Contract Net Protocol heute noch?
Das Contract Net Protocol von 1980 beschreibt Aufgabenverteilung als Ausschreibung: Ein Manager schreibt aus, Agenten bieten, der Manager vergibt. Genau dieses Muster taucht in modernen Orchestrierungs-Frameworks wieder auf, wenn ein Supervisor-Agent eine Teilaufgabe an den am besten geeigneten Worker delegiert. Es ist ein gutes Beispiel dafür, dass viele vermeintlich neue Ideen in der Agentenwelt solide Wurzeln haben.