A2A-Protokoll: Muster für Multi-Agent-Systeme

TL;DR / Die wichtigsten Punkte

Das A2A-Protokoll ist ein offener Standard für die Agent-zu-Agent-Kommunikation: Agenten entdecken sich, kündigen Fähigkeiten an und delegieren Aufgaben über Team-, Stack- und Anbietergrenzen hinweg.
A2A und MCP ergänzen sich, sie konkurrieren nicht — MCP verbindet einen Agenten mit Werkzeugen und Daten, A2A verbindet Agenten mit anderen Agenten.
Mit der GA von Microsoft Agent Framework 1.0 (3. April 2026) und Azure AI Foundry als Governance-Drehscheibe ist A2A auf Azure produktionsrelevant geworden, keine Forschungskuriosität mehr.
Der schwierige Teil ist nicht das Protokoll, sondern Zuverlässigkeit, Observability, Sicherheit für Agentenidentitäten, Evaluierung und Kostenkontrolle. Das ist der Wandel von Pilot zu Produktion 2026.
Für europäische Unternehmen machen die expliziten Aufgabenverträge von A2A Multi-Agent-Entscheidungen prüfbar und unterstützen so EU-KI-Verordnung und NIS2.

Warum Agent-Interoperabilität plötzlich zählt

Den Großteil von 2024 und 2025 bedeutete „Multi-Agent" mehrere spezialisierte Prompts, die ein Team in einem Prozess zusammengeschaltet hatte. Das funktioniert, bis es das nicht mehr tut. Sobald ein zweites Team einen Agenten ausliefert, ein Anbieter eine Fähigkeit anbietet, die Sie lieber konsumieren als nachbauen wollen, oder Ihr Plattform-Team Agenten unabhängig deployen und versionieren möchte, stoßen Sie an dieselbe Wand wie jedes verteilte System: Sie brauchen einen Vertrag.

Das Agent-to-Agent-Protokoll (A2A) ist dieser Vertrag. Es standardisiert, wie ein Agent ankündigt, was er kann, wie ein anderer Agent diese Fähigkeit entdeckt und aufruft, und wie beide Aufgaben und Ergebnisse austauschen — unabhängig davon, wer sie geschrieben hat oder auf welcher Laufzeitumgebung sie sitzen. Als Microsoft Agent Framework 1.0 am 3. April 2026 allgemein verfügbar wurde, lieferte es A2A- und Model-Context-Protocol-Unterstützung (MCP) als erstklassige Bürger für .NET und Python aus, mit Azure AI Foundry als zentraler Plattform zum Erstellen, Deployen und Governance von Agenten. Diese Kombination hat A2A von „interessant" zu „einsetzbar" gemacht.

Das Signal ist real: Mehr als 160.000 Organisationen haben bereits über 400.000 benutzerdefinierte Agenten auf Copilot Studio bereitgestellt. Bei dieser Menge an Agenten im Feld müssen diese zwangsläufig über Grenzen hinweg miteinander kommunizieren, für die sie nie entworfen wurden. Interoperabilität ist damit kein Nice-to-have mehr.

Die Architektur des Frameworks selbst behandeln wir im Begleitbeitrag zur Architektur von Microsoft Agent Framework 1.0; dieser Artikel widmet sich den Mustern, die entstehen, sobald Agenten miteinander zu sprechen beginnen.

A2A vs. MCP: hört auf, sie zu verwechseln

Die häufigste Verwechslung in unseren Projekten ist, A2A und MCP als Alternativen zu behandeln. Sie sind orthogonal.

Dimension	MCP (Model Context Protocol)	A2A (Agent-to-Agent)
Verbindet	Einen Agenten mit Werkzeugen, Daten, Kontext	Einen Agenten mit anderen Agenten
Richtung	Vertikale Integration	Horizontale Integration
Primäres Verb	„Nutze dieses Werkzeug / lies diese Daten"	„Delegiere diese Aufgabe"
Austauscheinheit	Tool-Aufruf, Ressource, Prompt	Aufgabe, Fähigkeit, Ergebnis
Vertrauensgrenze	Agent ↔ Werkzeug/Datenquelle	Agent ↔ Agent (oft organisationsübergreifend)
Typischer Eigentümer	Das Team des Agenten	Mehrere Teams oder Anbieter

Ein ausgereiftes System nutzt beides. MCP gibt jedem Agenten seine Hände — die Werkzeuge und Daten, auf die er einwirken kann. Das vertiefen wir im Beitrag zum MCP-Server-Design für das Unternehmen. A2A gibt Agenten eine gemeinsame Sprache zur Kooperation. Wer nur eines einsetzt, erhält entweder fähige Agenten, die nicht zusammenarbeiten können, oder ein Kooperationsgewebe, in dem nichts Nützliches eingesteckt ist.

Das A2A-Kerninteraktionsmuster

Reduziert man A2A auf das Wesentliche, gibt es drei Schritte:

Ankündigen. Ein Agent veröffentlicht eine Fähigkeitsbeschreibung — welche Aufgaben er annimmt, welche Eingaben er benötigt, was er zurückgibt und seine Randbedingungen (Kosten, Latenz, Datenresidenz).
Entdecken. Ein anfragender Agent findet einen fähigen Anbieter, entweder über ein Verzeichnis oder einen direkt bekannten Endpunkt.
Delegieren. Der Anforderer sendet eine strukturierte Aufgabe; der Anbieter führt sie aus — möglicherweise mit weiterer Delegation — und liefert ein Ergebnis mit Status und Herkunftsnachweis zurück.

Loading diagram...

Der letzte Punkt wiegt schwerer, als er aussieht. Weil jede Delegation eine explizite, strukturierte Aufgabe ist und kein undurchsichtiger Prompt, der in einer Konversation vergraben liegt, ist jeder Schritt nachvollziehbar. Diese Eigenschaft macht Multi-Agent-Systeme prüfbar — und deshalb behandeln wir A2A-Aufgabenverträge als Compliance-Asset, nicht nur als technische Bequemlichkeit.

Fünf Multi-Agent-Muster, die den Produktivbetrieb überstehen

Nicht jedes Multi-Agent-Design hält Last und Audit stand. Dies sind die Muster, die wir tatsächlich geliefert haben und empfehlen würden.

1. Orchestrator–Worker (überwachte Delegation)

Ein einzelner Orchestrator zerlegt ein Ziel und delegiert Teilaufgaben über A2A an spezialisierte Worker-Agenten, dann fügt er die Ergebnisse zusammen. Das ist das Arbeitspferd. Es hält den Kontrollfluss lesbar und gibt Ihnen einen Ort, an dem Sie Policy, Budget und Timeouts durchsetzen. Bevorzugen Sie es, wann immer Sie vorhersagbares Verhalten und klare Verantwortlichkeit brauchen — bei regulierten Workloads also fast immer.

2. Peer-Kooperation (ausgehandelte Übergabe)

Agenten vergleichbarer Autorität übergeben einander Arbeit direkt anhand der Fähigkeit, ohne zentralen Dirigenten. Mächtig für lose gekoppelte Domänen (etwa ein Beschaffungsagent, der einen Vertrag an einen Rechtsprüfungsagenten übergibt), aber schwerer zu durchdenken. Begrenzen Sie es mit expliziten Fähigkeitsbereichen und harten Schleifenlimits, sonst entartet es zu teurem, geschwätzigem Ping-Pong.

3. Föderiert / organisationsübergreifend

Agenten verschiedener Organisationen interoperieren über A2A — der Agent eines Lieferanten bedient den Agenten eines Einkäufers. Hier zahlt sich die Anbieterneutralität von A2A am meisten aus, und hier müssen Sicherheits- und Datenresidenzkontrollen am stärksten sein. Behandeln Sie die Grenze wie jede andere externe Integration: Verträge, Rate-Limits, Egress-Policy und null implizites Vertrauen.

4. Hierarchische Spezialisierung

Orchestratoren delegieren an Sub-Orchestratoren und bilden einen Verantwortungsbaum. Nützlich für wirklich komplexe Domänen, aber jede Ebene fügt Latenz und Kosten hinzu. Begrenzen Sie die Tiefe bewusst; in der Praxis sehen wir selten mehr als zwei Ebenen gerechtfertigt.

5. Human-in-the-Loop-Checkpoint

A2A-Aufgaben pausieren an definierten Punkten zur menschlichen Freigabe, bevor sie fortfahren. Für Hochrisiko-Anwendungsfälle der EU-KI-Verordnung ist das nicht optional — menschliche Aufsicht ist gesetzliche Pflicht, und der sauberste Weg, sie umzusetzen, ist, den menschlichen Prüfer als Schritt im A2A-Aufgabenfluss zu modellieren, statt ihn nachträglich anzuflanschen.

Muster	Kontrollklarheit	Latenzkosten	Am besten für
Orchestrator–Worker	Hoch	Niedrig	Regulierte, vorhersagbare Abläufe
Peer-Kooperation	Mittel	Mittel	Lose gekoppelte Domänen
Föderiert org-übergreifend	Mittel	Mittel–Hoch	Anbieter-/Partner-Interoperabilität
Hierarchisch	Mittel	Hoch	Wirklich komplexe Zerlegung
Human-in-the-Loop	Hoch	Variabel	Hochrisiko, aufsichtspflichtige Aufgaben

Produktionsreife: der Teil, den niemand vorführt

Das Protokoll sind die einfachen 20 %. Der Wandel von Pilot zu Produktion 2026 dreht sich um die anderen 80 %: Zuverlässigkeit, Observability, Sicherheit, Evaluierung und Kostenkontrolle. Dies ist die Checkliste, die wir anwenden, bevor ein A2A-System live geht.

Zuverlässigkeit. Jeder agentenübergreifende Aufruf braucht Timeouts, begrenzte Retries und Idempotency Keys. Eine delegierte Aufgabe, die stillschweigend hängt, ist schlimmer als eine, die laut fehlschlägt. Definieren Sie eine maximale Delegationstiefe und ein globales Aufgabenbudget gegen unkontrolliertes Fan-out.
Observability. Propagieren Sie einen Trace-Kontext über jeden A2A-Schritt, damit Sie den vollständigen Entscheidungspfad jedes Ergebnisses rekonstruieren können. Ohne verteiltes Tracing ist ein Multi-Agent-System eine unwiderlegbare Blackbox. Für uns ist das nicht verhandelbar; die Umsetzung behandeln wir in Observability und Tracing für KI-Agenten.
Sicherheit und Identität. Jeder Agent ist eine nicht-menschliche Identität. Authentifizieren Sie mit Microsoft-Entra-Workload-Identitäten, begrenzen Sie die zulässigen Aufgaben und Delegationen jedes Agenten und wenden Sie Least Privilege auf Fähigkeitsebene an. Ein Agent, der alles an jeden delegieren kann, ist ein ungemanagter Pfad für laterale Bewegung.
Evaluierung. Multi-Agent-Verhalten ist emergent und regressiert still. Pflegen Sie Evaluierungs-Suites, die ganze Delegationsketten durchspielen, nicht nur einzelne Agenten, und führen Sie sie in der CI vor jeder Promotion aus.
Kostenkontrolle. Ordnen Sie Token- und Tool-Kosten pro Agent und pro Aufgabe zu. Fan-out-Architekturen können Ausgaben unsichtbar vervielfachen; ohne Budgets pro Aufgabe verbrennt eine Peer-Kooperationsschleife leise ein Quartalskontingent.

Governance: A2A und europäische Compliance

Für die CTOs und CISOs, mit denen wir arbeiten, landet die Compliance-Frage zuerst. Die gute Nachricht: Die Struktur von A2A arbeitet hier für Sie.

Weil jede Delegation eine explizite Aufgabe mit deklarierten Eingaben, Ausgaben und Herkunftsnachweis ist, erzeugt ein A2A-basiertes System einen natürlichen Audit-Trail. Das unterstützt direkt die Anforderungen der EU-KI-Verordnung an Nachvollziehbarkeit, technische Dokumentation und menschliche Aufsicht bei Hochrisikosystemen und speist Ihre Konformitätsbewertung und Ihre Nachweispflichten. Unter NIS2 liegt die Verantwortung für diese Systeme bei der Geschäftsleitung, und die nachzuweisenden Risikomanagementmaßnahmen umfassen genau die oben genannten Identitäts-, Logging- und Resilienzkontrollen. Greifen Agenten über Organisationsgrenzen hinweg, erstrecken sich Ihre Sicherheitspflichten für die Lieferkette auch auf sie.

In einem aktuellen Projekt verwandelte die Modellierung jedes Agenten als gemanagte nicht-menschliche Identität mit eingegrenzten A2A-Fähigkeiten das, was der Kunde als unprüfbares „KI-Wildwuchs"-Problem fürchtete, in ein handhabbares Berechtigungsmanagement — dieselbe Disziplin, die er bereits auf Service-Prinzipale anwendet, nun auf Agenten angewandt.

Eine pragmatische Einführungsreihenfolge

Beginnen Sie mit einem einzelnen, MCP-ausgestatteten Agenten, der eine Aufgabe gut erledigt. Bringen Sie Tooling, Identität und Tracing zuerst auf Einheitsebene in Ordnung.
Führen Sie einen zweiten Agenten und eine Orchestrator–Worker-A2A-Verbindung ein. Weisen Sie Zuverlässigkeit, Tracing und Kostenzuordnung über die Grenze hinweg nach.
Ergänzen Sie Evaluierungs-Suites für die Delegationskette, bevor Sie weitere Agenten hinzufügen.
Erst danach erweitern Sie auf Peer- oder föderierte Muster, und nur dort, wo unabhängige Verantwortung oder Anbieter-Interoperabilität es wirklich verlangt.
Bauen Sie Human-in-the-Loop-Checkpoints überall dort ein, wo der Anwendungsfall unter der EU-KI-Verordnung hochriskant ist.

Widerstehen Sie der Versuchung, mit einem ausufernden Agenten-Mesh zu starten. Jedes Team, das es tut, verbringt das folgende Quartal damit, die übersprungenen Observability- und Identitätskontrollen nachzurüsten.

FAQ

Was ist das A2A-Protokoll (Agent-to-Agent)?

A2A ist ein offenes Protokoll für die Agent-zu-Agent-Kommunikation. Autonome Agenten können sich gegenseitig entdecken, ihre Fähigkeiten ankündigen und Aufgaben über Prozess-, Anbieter- und Organisationsgrenzen hinweg delegieren. Produktionsrelevant wurde es, als Microsoft Agent Framework 1.0 am 3. April 2026 mit integrierter A2A- und Model-Context-Protocol-Unterstützung (MCP) allgemein verfügbar wurde. A2A ist der Vertrag zwischen Agenten, MCP der Vertrag zwischen einem Agenten und seinen Werkzeugen oder Daten.

Worin unterscheidet sich A2A von MCP?

Sie lösen unterschiedliche Probleme und ergänzen sich. MCP verbindet einen einzelnen Agenten mit Werkzeugen, Datenquellen und Kontext — eine vertikale Integration. A2A verbindet Agenten mit anderen Agenten, damit sie delegieren und kooperieren können — eine horizontale Integration. Ein ausgereiftes Multi-Agent-System nutzt beides: MCP, um jedem Agenten seine Fähigkeiten zu geben, und A2A, um diese Agenten zusammenarbeiten zu lassen. Keines ersetzt das andere.

Brauche ich A2A, wenn alle meine Agenten in einem Framework laufen?

Nicht zwingend. Wenn alle Agenten im selben Microsoft-Agent-Framework-Prozess leben, ist In-Process-Orchestrierung einfacher und schneller. A2A zahlt sich an Grenzen aus — wenn Agenten verschiedenen Teams gehören, unabhängig deployt werden, in unterschiedlichen Stacks geschrieben sind oder von externen Anbietern stammen. Setzen Sie es dort ein, wo Interoperabilität und unabhängiges Deployment echte Anforderungen sind, nicht als Standardannahme.

Wie sichert man A2A-Kommunikation im Unternehmen ab?

Behandeln Sie jeden Agenten als nicht-menschliche Identität. Authentifizieren Sie Agenten mit Workload-Identitäten (Microsoft Entra), begrenzen Sie, was jeder Agent anfordern und delegieren darf, und wenden Sie Least Privilege auf Fähigkeitsebene an. Ergänzen Sie Eingabe- und Ausgabevalidierung, eine Egress-Policy und durchgängiges Tracing, um jede agentenübergreifende Entscheidung rekonstruieren zu können. Unter NIS2 und der EU-KI-Verordnung ist dieser Audit-Trail für betroffene Systeme nicht optional.

Ist A2A für EU-KI-Verordnung und NIS2 relevant?

Ja. Multi-Agent-Systeme im Hochrisikobereich müssen unter der EU-KI-Verordnung Nachvollziehbarkeit, menschliche Aufsicht und Dokumentation unterstützen; unter NIS2 liegt die Verantwortung bei der Geschäftsleitung. Die expliziten Aufgabenverträge und Fähigkeitsankündigungen von A2A machen Agentenentscheidungen prüfbar, was die Konformitätsbewertung und die Nachweispflichten direkt unterstützt.

Was braucht ein produktionsreifer A2A-Rollout über das Protokoll hinaus?

Das Protokoll ist der einfache Teil. Der Produktivbetrieb verlangt Zuverlässigkeit (Retries, Idempotenz, Timeouts), Observability (verteiltes Tracing über Agenten hinweg), Evaluierungs-Suites gegen stille Regressionen, Kostenkontrolle pro Agent und pro Aufgabe sowie ein Sicherheitsmodell für Agentenidentitäten. Der prägende Wandel 2026 ist der Schritt vom Pilot in die Produktion — und genau diese betrieblichen Aspekte trennen die Demo vom System, das man für ein reguliertes Unternehmen betreiben kann.

Ein Multi-Agent-System zu entwerfen, das unter europäischer Regulierung zuverlässig, sicher und prüfbar sein muss, ist genau die Art von Arbeit, die wir leisten. Wenn Sie Agenten auf Azure vom Pilot in die Produktion bringen, hilft Ihnen unser Bereich KI & Data-Platform-Engineering, die Muster, Governance und Leitplanken gleich beim ersten Mal richtig zu setzen.