Auf Google Cloud Next 2026 am 22. April hat Google das Agent2Agent-Protokoll (A2A) in Version 1.2 als Linux-Foundation-Projekt in den Produktivstatus gestellt. 150 Organisationen fahren A2A bereits produktiv, darunter Microsoft, AWS, Salesforce, SAP und ServiceNow. Native Unterstützung existiert in Google Agent Development Kit, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel und AutoGen. Für DACH-Cloud-Architekten ist damit eine Frage akut, die seit der initialen A2A-Ankündigung im vergangenen Jahr nur theoretisch war: Braucht A2A eine eigene Infrastruktur-Schicht neben dem bestehenden Service-Mesh, oder fliegt es ins vorhandene Sidecar-Modell?

Was A2A technisch wirklich ist

Was ist das Agent2Agent-Protokoll (A2A)? A2A ist ein offenes Anwendungsprotokoll auf HTTP/JSON-Basis für die Kommunikation zwischen autonomen KI-Agenten unterschiedlicher Anbieter. Es definiert Standards für Agent-Cards (Metadaten, Capabilities, Endpoints), Task-Delegation, Ergebnis-Rückgabe und Signatur-Verifikation. A2A 1.2 bringt kryptographisch signierte Agent-Cards mit Domain-Bindung, sodass ein Salesforce-Agent einen Google-Vertex-Agent authentisch erkennen kann, ohne dass die beiden Systeme sich intern kennen. Das Protokoll ist seit Cloud Next 2026 unter dem Dach der Linux Foundation Agentic AI Foundation.

Die entscheidende Architektur-Eigenschaft: A2A arbeitet auf Layer 7, also oberhalb der Service-Mesh-Schicht. Ein klassisches Istio-Setup (mTLS, Envoy-Sidecar, Control-Plane) bleibt vollständig intakt. A2A nutzt die TLS-Verbindung, die das Mesh bereitstellt; darauf liegt die eigene Signatur-Kette. Wer A2A als Konkurrenz zum Service-Mesh begreift, liest das Protokoll falsch. A2A ist eine Application-Layer-Abstraktion für Agent-Interop, nicht eine Transport-Layer-Alternative.

Ein kurzer Blick in die Release-Notes von A2A 1.2: Signierte Agent-Cards enthalten ein Agent-DID (Decentralized Identifier) mit Verknüpfung zur Domain. Die Signatur-Kette wird über DNS-TXT-Records oder per Well-Known-Endpoint validiert. Für die Praxis bedeutet das, dass ein eigener A2A-Agent eine öffentlich erreichbare Agent-Card bereitstellen muss, deren Signatur mit einem Domain-Key gegengezeichnet wird. Wer DNSSEC und einen Well-Known-Endpoint betreibt, hat die technische Voraussetzung bereits im Hausstandard.

Der Unterschied zu MCP, den die meisten Architektur-Runden überspringen

Das Model Context Protocol (MCP) von Anthropic, das seit 2024 etabliert ist, beschreibt die Schnittstelle zwischen einem einzelnen Agenten und externen Tools oder Datenquellen. A2A regelt dagegen die Kommunikation zwischen zwei Agenten, auch über Plattform- und Organisationsgrenzen hinweg. Ein typisches Szenario: Ein Salesforce-Agent auf Agentforce bekommt über A2A einen Task von einem Vertex-AI-Agent, fragt über MCP ein internes CRM-Tool ab, liefert per A2A das Ergebnis zurück. Beide Protokolle komplementieren sich. Wer eines ohne das andere plant, produziert unnötige Integrations-Kosten.

Drei Zahlen zur Einordnung

Jede gute Web-Architektur lässt sich auf einem Post-It skizzieren. Wenn nicht, ist irgendwo eine Abstraktion zu viel drin. A2A gehört in diese Skizze als dünne Schicht über dem Mesh, nicht als zweites Mesh daneben.

Integration ins bestehende Service-Mesh: drei Architektur-Entscheidungen

Die praktische Frage, die in DACH-Architektur-Runden aktuell die Agenda dominiert, lautet: Wie integriert man A2A in ein bestehendes Istio- oder Linkerd-Setup, ohne das Mesh-Design zu brechen? Drei Entscheidungen stehen konkret an.

Entscheidung 1: Agent-Card-Service separieren oder in Bestehende Discovery integrieren

A2A verlangt einen erreichbaren Agent-Card-Endpoint pro veröffentlichtem Agenten. Zwei Muster haben sich seit der Version 1.0-Veröffentlichung etabliert. Erstens, ein dedizierter Agent-Card-Service als eigenes Deployment hinter dem Ingress, mit eigenem Caching und eigener Rate-Limit-Policy. Zweitens, Integration der Agent-Card in die bestehende Service-Discovery (Consul, Istio Workload Entries), wobei die Karte als Metadaten-Attribut mitläuft. Unsere Erfahrung: Der separate Service ist sauberer zu betreiben und zu auditen, weil er Zugriffsmuster isoliert. Für eine Greenfield-Einführung empfehlen wir den separaten Service; für brownfield mit starker Consul-Landschaft reicht die Metadaten-Lösung.

Entscheidung 2: Signatur-Validierung im Sidecar oder im Agent-Runtime

A2A 1.2 bringt kryptographisch signierte Agent-Cards. Die Signatur-Validierung kann entweder im Envoy-Sidecar per Lua-Filter oder WASM-Plugin stattfinden, oder direkt im Agent-Runtime über das offizielle Agent-SDK. Für Hochdurchsatz-Setups (mehr als 200 Agent-Calls pro Sekunde pro Service) empfehlen wir die Sidecar-Variante, weil sie Cache-Warm-Up und Revocation-Listen einheitlich verwaltet. Für experimentelle und mittelgroße Setups ist die Runtime-Variante einfacher und schneller zu deployen. Wichtig: Wer Sidecar-Validierung wählt, muss die Agent-Card-CRL (Certificate Revocation List) mit dem Mesh-Update-Zyklus synchronisieren. Sonst landen revozierte Cards mit Verzögerung im System, was Audit-Trails verfälscht.

Entscheidung 3: Delegations-Audit-Trail in SIEM oder dediziert

Agent-zu-Agent-Delegation erzeugt eine Audit-Spur, die in den klassischen Istio-Access-Logs nicht vollständig sichtbar ist. Für Compliance-Anforderungen (DORA, NIS2, EU AI Act) ist der Delegations-Trail ein separates Audit-Artefakt: Welcher Agent hat welchem Agenten welchen Task übergeben, mit welcher Begründung, welchem Ergebnis, welcher Laufzeit. Wir sehen zwei Muster in der Praxis. Erstens, Export ins SIEM über eine dedizierte A2A-Event-Pipeline (Kafka-Topic plus Parser). Zweitens, ein dediziertes Agent-Observability-Tool (Arize, Helicone, LangSmith). Für regulierte Branchen ist der SIEM-Export meist Pflicht, das Observability-Tool läuft parallel für Performance-Analytics. Beides zusammen kostet im Mittelstand realistisch 15.000 bis 35.000 Euro pro Jahr, abhängig von Transaktionsvolumen.

Was das für die Architektur-Roadmap bedeutet

Für DACH-Architekten ergibt sich aus den drei Entscheidungen eine konkrete acht- bis zwölf-Wochen-Roadmap. Woche eins bis drei: Inventarisierung bestehender Agenten und Identifikation der ersten Integration-Use-Cases (meist ein Assistenz-Agent plus ein System-Agent). Woche vier bis sechs: Agent-Card-Service als separates Deployment, DNS-TXT-Record-Setup für Signatur-Kette, SDK-Integration in den Ziel-Agent. Woche sieben bis neun: Sidecar-Validierung oder Runtime-Validierung aktivieren, Load-Tests, Observability-Pipeline. Woche zehn bis zwölf: SIEM-Export, Audit-Trail-Review, produktive Freigabe. Wer früher fertig ist, hat entweder einen sehr einfachen Use-Case oder Abstriche in der Compliance-Dokumentation gemacht.

Was im eigenen Mesh-Ops-Alltag tatsächlich anders wird

Die spannendste operative Frage für DACH-Cloud-Architekten ist nicht „brauche ich A2A?“, sondern „was ändert sich an der Betriebsrealität meines Mesh, wenn ich A2A einführe?“. Drei Beobachtungen aus den ersten Integrations-Projekten. Erstens, die Control-Plane-Latenz steigt leicht (drei bis sieben Prozent), weil Signatur-Validierung zusätzliche Cache-Writes produziert. Zweitens, Envoy-WASM-Plugins brauchen mehr Review als klassische Lua-Filter, weil die A2A-Semantik komplex ist und Bug-Fixes zwei bis drei Tage dauern können. Drittens, das Observability-Team bekommt eine neue Event-Klasse (Agent-Delegation-Events), die in die bestehenden Dashboards integriert werden muss. Wer das nicht proaktiv plant, hat am Ende zwei parallele Observability-Oberflächen.

Ein konkreter Empfehlungssatz aus den Reviews: Betreiben Sie die erste A2A-Produktion mindestens drei Wochen im Shadow-Mode, bevor der eigentliche Traffic durchgereicht wird. Shadow-Mode bedeutet, dass echte Agent-Calls parallel verarbeitet werden, die Antworten aber nicht an die Applikations-Logik weitergeleitet sind. So erkennt das Team Regressionen an Response-Format, Signatur-Handling und Latenz, ohne Business-Impact zu riskieren. Diese drei Wochen zahlen sich in fast allen Mandaten aus, weil Regressionen früh sichtbar werden, bevor sie in der Produktivabnahme zum Thema werden.

Ein ehrlicher Blick auf den Reife-Grad

Obwohl A2A 1.2 in Produktion läuft, ist das Protokoll nicht fertig. Fehlende Bausteine, die wir in den nächsten 18 Monaten erwarten: Standardisierte Rate-Limits für cross-org-Calls, ein Rollback-Mechanismus für fehlerhafte Delegationen, klarere Governance-Regeln für Agent-Card-Widerruf. Wer heute A2A einführt, plant diese Lücken als eigene Zusatz-Bausteine ein. Die gute Nachricht: Die Linux-Foundation-Governance hat die Roadmap sauber veröffentlicht; die aktiven Mitglieder (Google, Microsoft, AWS, Salesforce, SAP, ServiceNow) haben sich verpflichtet, quartalsweise Roadmap-Updates zu liefern. Das ist mehr Governance-Disziplin als bei den meisten anderen AI-Standards 2025 zu sehen war.

Der Reife-Check in drei Fragen vor der Einführung: Ist der eigene erste Use-Case ein Intra-Org-Szenario (zwei eigene Agenten) oder bereits Cross-Org (Partner-Agent)? Wie viel Regulierungs-Druck wirkt auf die Delegation (Banken, Versicherer, Public-Sector sind hier deutlich empfindlicher als Industrie)? Ist das bestehende Mesh-Ops-Team bereit, Sidecar-Plugins zu betreiben und die A2A-Certificate-Lifecycle zu managen? Wer alle drei Fragen klar beantworten kann, hat die Grundlage für eine saubere Einführung. Wer bei einer der Fragen zögert, sollte mit einem Proof-of-Concept starten und nicht mit einem Produktiv-Roll-out.

Drei Fehlannahmen, die in den ersten Projekten regelmäßig auftauchen

Die erste Fehlannahme betrifft die Trennung zu MCP: Viele Teams nehmen an, dass A2A die Tool-Anbindung mit übernimmt. Das ist technisch nicht korrekt. A2A beschreibt ausschließlich Agent-zu-Agent, jede Tool-Anbindung läuft unverändert über MCP oder direkte API-Aufrufe. Wer in der Architektur-Runde diese Trennung nicht sauber zieht, produziert in drei Monaten zwei überlappende Protokoll-Schichten, die jeweils nur die Hälfte der Interaktionen abdecken.

Die zweite Fehlannahme betrifft die Performance-Kosten: Viele Teams rechnen mit einem linearen Zuschlag pro Agent-Call und dimensionieren die Infrastruktur entsprechend. In der Praxis ist der Overhead sublinear, weil Signatur-Caching und Connection-Pooling Skalen-Effekte erzeugen. Wer die Infrastruktur von Anfang an auf den linearen Worst-Case dimensioniert, bezahlt 20 bis 30 Prozent zu viel für die ersten sechs Monate.

Die dritte Fehlannahme betrifft die Governance: Viele Organisationen glauben, dass die Agent-Card-Signierung automatisch Compliance liefert. Sie liefert die technische Grundlage, aber die organisatorische Freigabe (Wer darf Agent-Cards zeichnen? Welche Prozesse stehen bei einem Card-Widerruf?) muss parallel aufgebaut werden. Ohne diese Prozesse ist die Signatur ein Stempel, der von niemandem überwacht wird. Für DACH-Organisationen, die in regulierten Branchen unterwegs sind, empfehlen wir die Governance-Schicht noch vor der technischen Einführung zu definieren, damit die erste produktive Freigabe nicht zum Prüfungs-Nadelöhr wird.

Häufige Fragen

Braucht A2A zwingend Istio oder Linkerd?

Nein. A2A ist Mesh-agnostisch und läuft auf jeder HTTP-basierten Infrastruktur. Ein Mesh vereinfacht die Betriebssicht (mTLS, Observability, Policy-Enforcement) und reduziert Integrations-Aufwand, ist aber keine Voraussetzung. Für cloud-natives Kubernetes-Setups empfehlen wir das Mesh, für Legacy-Enterprise mit AKS/EKS ohne Mesh funktioniert A2A via Standard-Ingress ebenso.

Wie hoch ist die Performance-Kosten von A2A-Signatur-Validierung im Sidecar?

Mit Envoy-WASM-Plugin und gutem Cache rechnen wir mit einer zusätzlichen Latenz von 2 bis 5 Millisekunden pro Call, bei Warm-Cache unter 1 Millisekunde. Das ist in fast allen Enterprise-Szenarien unproblematisch. Für Echtzeit-Trading oder Low-Latency-Gaming wäre die Runtime-Validierung die bessere Wahl, weil sie nur bei Bedarf anspringt.

Wie positioniert sich A2A zum EU AI Act?

Der EU AI Act fordert Transparenz und Rückverfolgbarkeit bei autonomen Systemen. A2A liefert mit signierten Agent-Cards und Delegations-Audit-Trail zwei von vier Pflicht-Bausteinen. Die fehlenden Teile (Modell-Identifikation und Output-Dokumentation) liegen auf MCP-Ebene und beim Applikations-Agent. Wer A2A plus MCP sauber instrumentiert, deckt rund 70 Prozent der AI-Act-Dokumentationsanforderungen ab.

Was kostet ein A2A-Rollout realistisch?

Für einen Mittelstands-Kontext mit bestehendem Istio-Setup rechnen wir mit 40.000 bis 90.000 Euro im ersten Projekt, abhängig von Use-Case-Komplexität und Zahl der Agenten. Cross-Org-Szenarien mit mehreren Partnern verdoppeln sich typisch, weil Governance und Vertragliches dazukommen.

Welche Risiken hat eine cross-org A2A-Delegation?

Die drei Hauptrisiken: Prompt-Injection über den externen Agenten, Datenabfluss über den Task-Payload und Vertrauenseskalation in der Delegations-Kette. Die Gegenmaßnahmen: Input-Sanitization vor Agent-Call, strikte Data-Classification-Policy für Payload-Inhalte und ein Maximum-Delegation-Depth im Agent-Runtime. Alle drei sind in der offiziellen A2A-Reference-Implementation dokumentiert und sollten in der eigenen Einführung nicht übergangen werden.

Netzwerk: Weiterlesen im cloudmagazin

• Einordnung zum Commvault-Clumio-Push auf Cloud Next 2026
• Faktencheck zum GCP-Pricing-Wandel und CUD-Konditionen im April 2026
• Architekturen im Multi-Cloud-Bereich 2026 und Broker-Plattformen

Quelle Titelbild: Pexels / Christina Morillo (px:1181675)