Eine Kundeneskalation beginnt häufig mit einer einfachen Nachricht:
„Diese Rechnung ist falsch. Bitte prüfen Sie sie.“
In einer Unternehmensumgebung kann diese Anfrage den Kundenservice, die Rechnungsstellung, die Vertragsprüfung, ERP-Daten, das Fallmanagement sowie eine menschliche Freigabe umfassen. Ein einzelner Prototyp eines KI-Assistenten könnte versuchen, all diese Aufgaben selbst zu übernehmen. Eine produktive Unternehmensarchitektur kann das in der Regel jedoch nicht.
Genau hier wird das Agent2Agent-Protokoll (A2A) relevant. Es bietet unabhängigen KI-Agenten einen standardisierten Weg, sich gegenseitig zu entdecken, Aufgaben zu delegieren, Kontext auszutauschen, den Fortschritt von Aufgaben nachzuverfolgen und verlässliche Ergebnisse zurückzugeben. A2A standardisiert die Zusammenarbeit zwischen Agenten, während APIs, Workflow-Engines und das Model Context Protocol (MCP) weiterhin für Geschäftsfunktionen, Datenzugriff und die Integration von Tools zuständig bleiben.
Die offizielle A2A-Spezifikation beschreibt A2A als einen offenen Standard für Kommunikation und Interoperabilität zwischen unabhängigen KI-Agentensystemen. Zu den Zielen gehören die Agentenerkennung (Discovery), die Aushandlung von Modalitäten, kollaboratives Aufgabenmanagement sowie der sichere Informationsaustausch – ohne Zugriff auf den internen Zustand, den Speicher oder die Werkzeuge eines anderen Agenten. Die aktuell veröffentlichte Spezifikation ist Version 1.0.0.
Das Agent2Agent-Protokoll ermöglicht es unabhängigen KI-Agenten, über verschiedene Systeme, Teams und Plattformen hinweg miteinander zu kommunizieren und zusammenzuarbeiten.
A2A definiert ein gemeinsames Interaktionsmodell. Anstatt individuelle Punkt-zu-Punkt-Integrationen zu entwickeln, stellen Agenten ihre Fähigkeiten über einen standardisierten Vertrag bereit. Andere Agenten können diese Fähigkeiten entdecken, Nachrichten senden, Aufgaben erstellen, Statusaktualisierungen empfangen und abschließende Ergebnisse abrufen.
A2A definiert jedoch nicht, wie ein Agent intern arbeitet. Das Protokoll schreibt weder Prompts noch Speicherarchitekturen, LLM-Auswahl, Planungslogik, Vektordatenbanken oder Business-APIs vor. Diese Trennung ermöglicht es Teams, die Fähigkeiten ihrer Agenten bereitzustellen, ohne deren interne Implementierung offenzulegen.
Eine hilfreiche Faustregel lautet:
A2A dient als externer Vertrag für die Zusammenarbeit zwischen Agenten – nicht als Modell für deren interne Architektur.
A2A gewinnt an Bedeutung, weil viele Unternehmen den Übergang von isolierten KI-Assistenten hin zu Landschaften spezialisierter KI-Agenten vollziehen. Ohne ein gemeinsames Interaktionsmodell werden solche Agentenlandschaften zunehmend schwierig zu integrieren, zu überwachen und zu steuern.
Die meisten Enterprise-AI-Initiativen beginnen mit einem klar abgegrenzten Anwendungsfall – beispielsweise einem Support-Assistenten, einem Agenten zur Dokumentenanalyse oder einem internen Wissensassistenten. Im Laufe der Zeit kommen weitere spezialisierte Agenten hinzu, etwa für Rechnungsprüfung, Vertragsanalyse, Compliance, Finanzen, IT-Betrieb oder Datenanalyse.
Diese Agenten werden häufig von unterschiedlichen Teams entwickelt, basieren auf verschiedenen Frameworks, laufen in unterschiedlichen Umgebungen oder stammen von verschiedenen Anbietern.
Die eigentliche Herausforderung besteht in der Koordination. Agenten benötigen einen gemeinsamen Standard, um Fragen wie diese beantworten zu können:
Sobald Agenten Teil geschäftskritischer Prozesse werden, wird Interoperabilität nicht mehr nur zu einer technischen Frage, sondern zu einer zentralen Architektur- und Governance-Anforderung.
A2A, MCP und APIs ergänzen sich gegenseitig. APIs stellen Geschäftsfunktionen und Daten bereit, MCP verbindet Agenten mit Tools und Kontext, und A2A koordiniert die Zusammenarbeit zwischen Agenten.
Das Model Context Protocol (MCP) ist ein Open-Source-Standard, der KI-Anwendungen mit externen Systemen wie Datenquellen, Tools und Workflows verbindet. A2A adressiert dagegen eine andere Ebene: die Kommunikation und Koordination zwischen unabhängigen Agenten. In der Ankündigung zu A2A Version 1.0 werden A2A und MCP ausdrücklich als komplementäre Technologien beschrieben.
Eine einfache Entscheidungsregel lautet:
Ein Beispiel: Ein Kundenservice-Agent delegiert die Klärung einer Rechnung über A2A an einen Billing-Agenten. Dieser nutzt intern MCP oder direkte APIs, um auf ERP-Daten und Rechnungsdokumente zuzugreifen. Für den Kundenservice-Agenten ist lediglich wichtig, dass er die Aufgabe zuverlässig übergeben, ihren Fortschritt verfolgen und das Ergebnis erhalten kann.
A2A sollte verwendet werden, wenn sich eine entfernte Fähigkeit wie ein eigenständiger Agent verhält – also Anfragen interpretiert, Aufgaben verwaltet, Rückfragen stellt oder Artefakte erstellt. Für einfache Datenbankabfragen, deterministische Funktionen oder kurze Tool-Aufrufe sind MCP oder eine direkte API meist die einfachere und effizientere Lösung.
Unternehmen sollten A2A in Betracht ziehen, wenn mehrere unabhängige Agenten über Team-, Plattform-, Hersteller- oder Sicherheitsgrenzen hinweg zusammenarbeiten müssen.
Einfach ausgedrückt: A2A wird dann sinnvoll, wenn die Zusammenarbeit zwischen Agenten selbst zu einer Architekturherausforderung wird.
In vielen Fällen ist A2A dagegen nicht erforderlich, beispielsweise wenn:
In solchen Szenarien sind ein Single-Agent-Ansatz, ein MCP-Tool-Call, eine direkte API oder eine bestehende Workflow-Engine häufig die bessere Wahl.
Unternehmen sollten mit einem konkreten Multi-Agenten-Prozess beginnen. Ein Eskalationsprozess im Kundenservice eignet sich besonders gut, da er geschäftlichen Mehrwert, spezialisierte Verantwortlichkeiten, bestehende Unternehmenssysteme und Anforderungen an Nachvollziehbarkeit miteinander verbindet.
A2A entfaltet seinen größten Nutzen bei Aufgaben, die Delegation, Fortschrittsverfolgung, Zwischenergebnisse und finale Artefakte erfordern.
Ein typisches Beispiel ist eine Eskalation im B2B-Kundenservice:
„Rechnung 4711 enthält eine Servicegebühr, die wir nicht vereinbart haben. Bitte prüfen Sie den Vertrag und korrigieren Sie die Rechnung.“
Ein möglicher A2A-Ablauf könnte folgendermaßen aussehen:
Dieser Ablauf ist weit mehr als ein einfacher Tool-Aufruf. Er umfasst mehrere spezialisierte Agenten, Zustände, Zwischenergebnisse, mögliche Rückfragen sowie menschliche Freigaben. Genau in solchen Szenarien entfalten die Aufgaben- und Statusmechanismen von A2A ihren Mehrwert.
A2A sollte in der Agent Collaboration Layer angesiedelt sein – zwischen den benutzerorientierten Assistenten und der Ebene für Tools, Daten und Workflows.
Abbildung 1: A2A bildet die Kollaborationsebene zwischen unabhängigen Agenten. MCP, APIs, Datenbanken und Workflow-Engines bleiben Bestandteil der Tool-, Workflow- und Datenintegrationsschicht.
A2A sollte die Grenzen einer Architektur nicht verwischen. Ein Agent kann seine Fähigkeiten über A2A bereitstellen, gleichzeitig MCP nutzen, um auf Werkzeuge zuzugreifen, APIs für Geschäftsdaten aufrufen und auf bestehende Enterprise-Monitoring-Lösungen für Observability zurückgreifen.
Für HMS-Kunden ist diese Trennung besonders wichtig, da viele KI-Initiativen mit einem vielversprechenden Prototypen beginnen und anschließend zu produktionsreifen Systemen weiterentwickelt werden müssen. Die entscheidende Architekturfrage lautet daher:
Lässt sich diese Agentenlandschaft langfristig betreiben, absichern, überwachen und weiterentwickeln?
A2A standardisiert die Kommunikation zwischen Agenten. Unternehmen benötigen jedoch weiterhin klare Regeln für Verantwortlichkeiten, Zugriffssteuerung, Protokollierung, Freigaben und Incident Management.
Die A2A-Spezifikation beschreibt verschiedene unternehmensrelevante Prinzipien, darunter Authentifizierung, Autorisierung, Sicherheit, Datenschutz, Tracing, Monitoring, Asynchrone Aufgaben, und Opaque Execution.
Opaque Execution bedeutet, dass Agenten zusammenarbeiten können, ohne ihre internen Überlegungen, Pläne oder Tool-Implementierungen offenzulegen.
Bevor Unternehmen Agenten für die Zusammenarbeit über A2A veröffentlichen, sollten sie unter anderem folgende Fragen beantworten:
Besonders wichtig ist die Observability. Sobald Agenten Aufgaben an andere Agenten delegieren, verteilt sich die Ausführung über mehrere Systeme. Fehleranalyse und Monitoring werden dadurch erheblich komplexer.
Deshalb sollte jeder A2A-Agent wie ein produktiver Unternehmensservice behandelt werden, mit einem klar definierten Verantwortlichen, einer Versionierung, kontinuierlichem Monitoring, Zugriffssteuerung, sowie vollständiger Auditierbarkeit.
Das größte Risiko bei A2A ist nicht das Protokoll selbst.
Das eigentliche Risiko besteht darin, eine unkontrollierte Agentenlandschaft ohne klare Verantwortlichkeiten, definierte Aufgabenmodelle und ausreichende Observability entstehen zu lassen.
Unternehmen sollten deshalb zunächst eine kleine Referenzimplementierung aufbauen, bevor sie A2A unternehmensweit standardisieren.
Bereits eine Kombination aus einem Kundenservice-Agenten, einem Billing-Agenten, sowie einem Vertrags-Agenten reicht aus, um wichtige Aspekte wie Qualität der Agent Cards, Authentifizierung, Logging, Aufgabenverwaltung, Artefaktformate und Verhalten bei Fehlern und Ausfällen zu validieren.
Ein erfolgreicher Pilot liefert wertvolle Erkenntnisse, bevor die Architektur auf weitere Geschäftsbereiche ausgeweitet wird.
A2A ist inzwischen ausgereift genug, um für Enterprise-Multi-Agenten-Architekturen ernsthaft evaluiert zu werden. Dennoch sollte die Einführung stets auf einem konkreten Bedarf an Zusammenarbeit zwischen Agenten basieren.
Die offizielle Spezifikation führt Version 1.0.0 als aktuell veröffentlichte Version auf. Die Ankündigung zu Version 1.0 beschreibt sie als erste stabile und produktionsreife Veröffentlichung und hebt Enterprise-Funktionen wie Multi-Protokoll-Bindings, Versionsverhandlung, Multi-Tenancy und signierte Agent Cards hervor.
Die Linux Foundation berichtete im April 2026, dass A2A bereits von mehr als 150 Organisationen unterstützt wird, darunter AWS, Google, IBM, Microsoft, Salesforce, SAP und ServiceNow.
Für Enterprise-Teams bedeutet dies: A2A ist heute reif genug, um Bestandteil von Architekturentscheidungen zu sein, wenn unabhängige Agenten einen gemeinsamen, standardisierten und steuerbaren Weg zur Zusammenarbeit benötigen.
Die entscheidende Frage lautet daher nicht:
„Sollten wir A2A einsetzen, weil es neu ist?“
Sondern vielmehr:
„Verfügen wir über unabhängige Agenten, die über Team-, Plattform-, Hersteller- oder Sicherheitsgrenzen hinweg zusammenarbeiten müssen?“
HMS unterstützt Unternehmen dabei, zu bewerten, wo A2A echten Mehrwert schafft, die passende Kollaborationsebene zu entwerfen und sichere Referenzimplementierungen für produktive Umgebungen zu entwickeln.
Die Einführung von A2A sollte nicht beim Protokoll beginnen, sondern beim Geschäftsprozess und der zugrunde liegenden Architekturherausforderung.
Typische Fragestellungen zu Beginn sind:
An dieser Stelle kommen die Kompetenzen von HMS in den Bereichen Software Engineering, Data Engineering und KI-Implementierung zum Tragen.
A2A entfaltet seinen Mehrwert nur dann, wenn es in eine belastbare Enterprise-Architektur eingebettet wird. Dazu gehören unter anderem Integrationsdesign, Sicherheitskonzepte, Observability, Teststrategien, Deployment und langfristige Wartbarkeit.
Für viele Unternehmen besteht der sinnvollste erste Schritt in einer fokussierten Architekturbewertung oder einer Referenzimplementierung. Ziel ist es, einen geschäftlich relevanten Multi-Agenten-Prozess zu identifizieren und nachzuweisen, dass dieser sicher, transparent und zuverlässig betrieben werden kann.
Das Agent2Agent-Protokoll unterstützt Unternehmen dabei, den Übergang von isolierten KI-Assistenten zu einer steuerbaren Zusammenarbeit mehrerer spezialisierter KI-Agenten zu vollziehen.Sein wesentlicher Mehrwert liegt in der Standardisierung von Agent Discovery, Delegation, Aufgabenverwaltung, Statusverfolgung und dem Austausch von Artefakten zwischen unabhängigen Agenten.Viele Unternehmen erkennen den Bedarf an A2A erst dann, wenn aus einem erfolgreichen KI-Prototyp eine wachsende Landschaft spezialisierter Agenten entsteht. In diesem Stadium werden individuelle Punkt-zu-Punkt-Integrationen schnell zum Engpass, während Monitoring und Governance zunehmend komplexer werden.
Die praktische Empfehlung lautet daher:
Beginnen Sie mit einem konkreten Multi-Agenten-Prozess. Definieren Sie die beteiligten Agenten, Aufgaben, Artefakte, Verantwortlichkeiten, Zugriffsregeln und Monitoring-Anforderungen. Erst anschließend sollte entschieden werden, ob A2A der geeignete Standard für die Zusammenarbeit zwischen den Agenten ist.
Planen Sie den Aufbau einer Multi-Agenten-Architektur oder möchten Sie bewerten, wie A2A und MCP in Ihre Enterprise-AI-Roadmap passen?
Vereinbaren Sie ein A2A-Architecture Assessment mit HMS.
Gemeinsam identifizieren wir einen geeigneten Pilotprozess, definieren die Verantwortlichkeiten von A2A, MCP und APIs und entwickeln eine sichere Referenzarchitektur für den produktiven Einsatz.
[1] Official Agent2Agent Protocol specification: latest released version, core concepts, task model and enterprise principles.
[2] A2A Protocol v1.0 announcement: production-ready release, enterprise requirements and relationship to MCP.
[3] Linux Foundation A2A adoption announcement: ecosystem scale, supporting organizations and cloud-platform adoption.
[4] Official Model Context Protocol introduction: MCP as a standard for connecting AI applications to tools, data sources and workflows.
