Die 5 Integrationsmuster für Multi-Agenten-Systeme von Google Cloud: A2A und MCP

Google Cloud hat auf der Cloud Next 26 eine Infrastruktur vorgestellt, mit der sich Multi-Agenten-Systeme im Enterprise-Maßstab aufbauen lassen. Im Kern stehen zwei Protokolle: A2A (Agent-to-Agent) für die Kommunikation zwischen Agenten und MCP (Model Context Protocol), das Agenten beim Zugriff auf externe Tools und Daten verwenden. Der Beitrag stellt fünf Integrationsmuster vor, die diese beiden Protokolle kombinieren.

Muster 1: Entdeckung und Registrierung von Agenten

• Agent Card — Jeder Agent, der A2A unterstützt, veröffentlicht seine Funktionen, Authentifizierungsanforderungen, Aufrufbeschränkungen usw. als JSON-Dokument. Ähnlich wie eine OpenAPI-Spezifikation, aber als eine Art „Visitenkarte“ für die Interaktion zwischen Agenten konzipiert.
• Agent Registry — Wenn Agenten innerhalb einer Organisation in einem zentralen Register eingetragen werden, können andere Agenten Funktionen suchen und darauf zugreifen, auch ohne die URL zu kennen. Das erfüllt eine ähnliche Rolle wie ein Service Mesh in einer Microservices-Architektur.

Muster 2: Teamübergreifende Delegation

• Mehrsprachige, teamübergreifende Zusammenarbeit — Ein einzelner Koordinations-Agent delegiert Aufgaben an den Go-Agenten des Security-Teams, den Java-Agenten des Risk-Teams oder den TypeScript-Agenten des Marketing-Teams. Auch wenn jedes Team andere Sprachen und Frameworks nutzt, funktioniert die Integration, solange das A2A-Protokoll implementiert ist.
• Unabhängige Deployments, unabhängige Weiterentwicklung — Nach demselben Prinzip, das Microservices erfolgreich gemacht hat, kann jeder Agent unabhängig bereitgestellt und aktualisiert werden, ohne Änderungen am Koordinations-Agenten zu erfordern.

Muster 3: Tool-Anbindung über MCP (Tool Bridge)

• Verschiedene Datenquellen über ein einziges Protokoll anbinden — Ohne MCP müssten für jede REST API, Datenbank oder jedes Legacy-System eigene Connectoren gebaut werden. MCP fasst das in einer standardisierten Schnittstelle zusammen.
• Vorhandene API-Governance weiterverwenden — Über den Apigee API Hub lassen sich bestehende REST APIs automatisch in Agenten-Tools umwandeln, wobei vorhandene Verwaltungsmechanismen wie Authentifizierung, Logging und Zugriffskontrolle unverändert weitergelten.
• Mehr als 60 vorgefertigte Tools — Es stehen sofort nutzbare MCP-Integrationen für GitHub, Notion, Stripe und andere bereit.

Muster 4: Zusammenarbeit zwischen Organisationen

• Agent Gallery — Innerhalb von Gemini Enterprise lassen sich mehr als 100 verifizierte Partner-Agenten von Adobe, ServiceNow, Salesforce und anderen direkt nutzen.
• Unabhängige Governance beibehalten — Jede Organisation behält ihr eigenes Sicherheitsmodell bei und arbeitet dennoch über A2A zusammen. Mit Agent-Gateway-Richtlinien lässt sich granular steuern, welche Daten geteilt und welche Aktionen erlaubt werden.

Muster 5: Ereignisgesteuertes Agent Mesh

• Stets aktive Agenten-Netzwerke — Agenten, die mit BigQuery-Tabellen oder Pub/Sub-Streams (Dienst für Echtzeit-Message-Streaming) verbunden sind, erkennen Ereignisse und delegieren bei Bedarf über A2A an spezialisierte Agenten oder eskalieren an Menschen.
• Selbstorganisation — Beim Hinzufügen eines neuen spezialisierten Agenten genügt es, ihn in der Registry zu registrieren und nur die Routing-Logik anzupassen; ein Redesign des gesamten Mesh ist nicht nötig.
• Observability — Über Agent Identity, Agent Gateway und Agent Observability lassen sich alle Agenten-Aktivitäten im Mesh nachverfolgen.

Unterscheidungsmerkmale

• Offenheit von A2A — Das Design setzt auf ein offenes Protokoll, das nicht an ein bestimmtes Framework, eine bestimmte Sprache oder eine bestimmte Cloud gebunden ist, und zielt damit auf einen Standard für die Agenten-Integration in heterogenen Umgebungen.
• Getrennte Rollen von A2A und MCP — Durch die Trennung von Agenten-Kommunikation und Tool-Zugriff in unterschiedliche Protokolle entsteht eine Struktur, in der sich beide Ebenen unabhängig voneinander weiterentwickeln lassen.
• Nutzung bestehender Infrastruktur — Da die Agenten-Schicht auf bereits genutzter Google-Cloud-Infrastruktur wie Apigee oder BigQuery aufsetzt, scheint das Ziel zu sein, die Hürde für die Einführung eines komplett neuen Stacks zu senken.

Worauf zu achten ist

• Starker Fokus auf das Google-Cloud-Ökosystem — Zentrale Funktionen wie Agent Gallery oder die Gemini Enterprise Agent Platform sind eng mit der Google-Cloud-Plattform verzahnt, sodass sich die tatsächliche Offenheit in Multi-Cloud-Umgebungen erst noch beweisen muss.
• Enterprise-Komplexität — Wenn alle fünf Muster kombiniert im Betrieb eingesetzt werden, kann die für verteilte Systeme typische Komplexität hinzukommen, etwa bei der Verwaltung von Abhängigkeiten zwischen Agenten oder der Ausbreitung von Ausfällen.

Das von Google Cloud vorgestellte Framework ist der Versuch, AI-Agenten nicht nur als einzelne Tools, sondern als kollaborative Infrastruktur für ganze Organisationen zu etablieren. So wie die Microservices-Architektur die Grenzen monolithischer Anwendungen überwunden hat, zielen A2A und MCP darauf ab, die Isolation einzelner Agenten zu überwinden. Wie reibungslos diese Vision in realen Enterprise-Umgebungen tatsächlich funktioniert, wird sich aber wohl erst mit zunehmenden Praxisbeispielen zeigen. Die praktische Bedeutung dieses Ökosystems dürfte letztlich von drei Faktoren abhängen: dem Reifegrad der Protokolle, der Qualität der Partner-Agenten und der Abstimmung der Governance zwischen Organisationen.

[bluenyx]

Schon mit nur 3–4 Senior-Leuten entsteht offenbar eine Struktur, die die Arbeit von 3–40 Personen tragen kann. (Noch klarer als heute …)