A2A Protocol: So arbeiten KI-Agenten im Unternehmen zusammen
Laut Gartner werden bis 2028 ein Drittel aller Enterprise-Anwendungen agentenbasierte KI enthalten. Bereits Ende 2026 werden laut IDC 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten einbetten. Das Problem: Diese Agenten stammen von anderen Anbietern, sprechen andere Sprachen und arbeiten in isolierten Silos.
Wenn Ihr Salesforce-Agent nicht mit Ihrem SAP-Agent kommunizieren kann, haben Sie keine Multi-Agent-Architektur. Sie haben mehrere Einzelagenten.
Das A2A Protocol löst genau dieses Problem. Bei IJONIS sehen wir es als das fehlende Puzzlestück für den Übergang von einzelnen KI-Agenten zu echten Teams aus Agenten.
„Die meisten Unternehmen scheitern nicht am einzelnen Agenten. Sie scheitern daran, zehn Agenten mehrerer Anbieter dazu zu bringen, als Team zu arbeiten. A2A ist der Standard, der das erstmals möglich macht." — Jamin Mahmood-Wiebe, Gründer von IJONIS
Was ist das A2A Protocol?
Das A2A Protocol ist ein offener Standard. Er legt fest, wie KI-Agenten mehrerer Anbieter miteinander reden. Google stellte A2A im April 2025 vor und übergab das Protokoll anschließend an die Linux Foundation — ein bewusster Schritt, um Neutralität und langfristige Governance sicherzustellen.
„Wir stellen uns eine Zukunft vor, in der KI-Agenten — unabhängig vom Framework oder Anbieter — nahtlos zusammenarbeiten können. A2A macht das möglich." — Sundar Pichai, CEO von Google (zur A2A-Ankündigung, April 2025)
Über 100 Unternehmen unterstützen A2A, darunter Salesforce, SAP, Microsoft, PayPal, ServiceNow, Workday, Accenture, Deloitte und McKinsey. Die Breite der Unterstützung zeigt: A2A ist kein Nischen-Standard. Es ist der neue Branchenstandard für die Zusammenarbeit von KI-Agenten.
Technische Grundlagen des A2A Protocol
A2A baut auf etablierten Webtechnologien auf. Es gibt keine proprietären Formate und keine neue Infrastruktur. Unternehmen können ihre vorhandenen HTTP-Server, JSON-Parser und OAuth-Systeme nutzen, um A2A sofort zu implementieren. Das senkt die Einstiegshürde erheblich:
Der Vorteil: Jedes Unternehmen, das heute REST-APIs betreibt, hat die Infrastruktur für A2A bereits im Haus. Es gibt keine neue Middleware, keinen neuen Server-Typ und keine neue Programmiersprache zu lernen.
Wie funktioniert A2A in der Praxis?
A2A baut auf drei Bausteinen auf. Zusammen machen sie es möglich, dass Agenten Aufgaben austauschen, Ergebnisse liefern und den Fortschritt verfolgen — ganz ohne eigene Schnittstelle pro Agent-Paar. So funktioniert der Ablauf:
- Agent Card veröffentlichen — Jeder A2A-fähige Agent stellt ein maschinenlesbares Profil bereit, das seine Fähigkeiten, Eingabeformate und Endpunkte beschreibt.
- Task delegieren — Ein Agent sucht über die Agent Cards den passenden Spezialisten, erstellt eine strukturierte Aufgabe (Task) und sendet sie ab.
- Artifact empfangen — Der beauftragte Agent bearbeitet die Task, durchläuft definierte Zustände (submitted → working → completed/failed) und liefert das Ergebnis als Artifact zurück.
1. Agent Card — Das digitale Profil
Jeder A2A-fähige Agent veröffentlicht eine Agent Card: ein maschinenlesbares JSON-Dokument, das beschreibt, was der Agent kann. Die Agent Card ist vergleichbar mit einem Lebenslauf für Software-Agenten — sie macht Fähigkeiten, Schnittstellen und Zugangswege transparent und maschinenlesbar. Die Agent Card enthält:
- Fähigkeiten: Welche Aufgaben kann der Agent erledigen?
- Eingabeformate: Welche Daten akzeptiert der Agent?
- Authentifizierung: Wie wird der Zugang gesichert?
- Endpunkt: Wo ist der Agent erreichbar?
Agent Cards funktionieren wie ein Verzeichnis: Ein Agent, der eine Aufgabe delegieren will, durchsucht die verfügbaren Agent Cards und findet den spezialisierten Agenten für die Aufgabe.
2. Task — Die strukturierte Aufgabe
Jede Interaktion zwischen Agenten ist eine Task mit klar definierten Zuständen. Eine Task bildet den gesamten Lebenszyklus einer Agentenaufgabe ab — von der Einreichung über die Bearbeitung bis zum Ergebnis oder Abbruch. Das macht jeden Schritt nachvollziehbar:
submitted → working → completed
→ failed
→ canceled
Jede Task hat eine eindeutige ID, Eingabedaten und Ergebnisse. Der aufrufende Agent kann den Status jederzeit abfragen. Das macht Multi-Agent-Workflows nachvollziehbar und auditierbar — eine zentrale Anforderung des EU AI Act.
3. Artifact — Das Ergebnis
Wenn ein Agent eine Task abschließt, liefert er ein Artifact zurück. Artifacts sind die konkreten Arbeitsergebnisse: strukturierte Daten, Dokumente, Berichte oder andere Resultate. Sie haben definierte MIME-Types und können von jedem A2A-kompatiblen Agenten weiterverarbeitet werden. So entsteht eine durchgängige Wertschöpfungskette zwischen Agenten verschiedener Anbieter.
Laut Google Blog unterstützen über 100 Unternehmen den Standard. Gartner erwartet, dass bis 2028 ein Drittel aller Unternehmenssoftware KI-Agenten enthält. IDC schätzt, dass Ende 2026 bereits 40 % der Enterprise-Apps Agenten einbetten werden.
A2A vs. MCP — Kein Entweder-oder
Die Frage, die wir bei IJONIS am häufigsten hören: „Brauche ich A2A oder MCP?" Die Antwort ist klar: Sie brauchen beides. Die beiden Standards lösen unterschiedliche Probleme auf unterschiedlichen Ebenen der KI-Architektur. Wer sie verwechselt oder nur einen davon einsetzt, baut sich unnötige Grenzen ein.
Das Model Context Protocol (MCP) definiert, wie ein Agent auf Daten und Werkzeuge zugreift. A2A definiert, wie Agenten miteinander kommunizieren. Die Analogie: MCP ist die Hand des Agenten (greift nach Werkzeugen). A2A ist die Sprache des Agenten (spricht mit anderen Agenten).
| App | Geltungsbereich | Problem | Kommunikationsrichtung | Beispiel |
|---|---|---|---|---|
| MCP | Agent ↔ Werkzeug | Zugriff auf Daten und Tools | Agent → System | Agent liest Kundendaten aus CRM |
| A2A | Agent ↔ Agent | Kommunikation zwischen Agenten | Agent → Agent | Beschaffungsagent beauftragt Compliance-Agent |
Zusammenspiel in der Enterprise-Architektur
In einem realistischen Unternehmensszenario arbeiten A2A und MCP zusammen. Kein Agent existiert isoliert: Er braucht Daten (MCP) und muss mit anderen Agenten kommunizieren (A2A). Das folgende Beispiel zeigt, wie beide Protokolle in einem typischen Vertriebsprozess ineinandergreifen:
- Ein Vertriebsagent empfängt eine Kundenanfrage
- Er nutzt MCP, um Kundendaten aus dem CRM zu lesen
- Er delegiert die Bonitätsprüfung per A2A an einen spezialisierten Compliance-Agenten
- Der Compliance-Agent nutzt MCP, um Finanzdaten aus dem ERP abzurufen
- Er liefert das Ergebnis per A2A an den Vertriebsagenten zurück
Ohne MCP können Agenten nicht auf Unternehmensdaten zugreifen. Ohne A2A können sie nicht miteinander arbeiten. Wer Multi-Agent-Systeme im Unternehmen plant, braucht beides.
IJONIS-Praxisbericht
Bei IJONIS setzen wir MCP bereits produktiv ein — für Datenbankzugriffe, Browser-Automatisierung und Code-Operationen. A2A wird die nächste Schicht: die Koordination zwischen spezialisierten Agenten in unseren Client-Projekten. Die Kombination beider Protokolle ist der Schlüssel zu skalierbaren Multi-Agent-Architekturen.
Drei Praxisbeispiele mit A2A
Die Theorie ist klar — doch wie sieht A2A in der Praxis aus? Die folgenden drei Szenarien zeigen, wie Unternehmen das Protokoll konkret einsetzen können, um bestehende Prozesse zu beschleunigen und Silos zwischen Abteilungen aufzulösen.
Szenario 1: Beschaffung und Compliance
Ein Beschaffungsagent findet das günstigste Angebot für Büromaterial. Bevor er die Bestellung auslöst, muss ein Compliance-Agent prüfen, ob der Lieferant die Unternehmensrichtlinien erfüllt. Heute passiert das per E-Mail oder Ticket-System — mit Tagen Verzögerung.
Mit A2A: Der Beschaffungsagent sendet eine Task an den Compliance-Agenten. Der Compliance-Agent prüft den Lieferanten gegen die Richtlinien-Datenbank (via MCP) und liefert ein Artifact mit der Freigabe oder Ablehnung zurück. Gesamtdauer: Minuten statt Tage. Vollständig auditierbar.
Szenario 2: HR-Onboarding über Systemgrenzen
Neue Mitarbeitende brauchen Zugänge in fünf Systemen: Active Directory, E-Mail, CRM, Projektmanagement, Zeiterfassung. Heute koordiniert HR das manuell — mit Checklisten und Erinnerungen.
Mit A2A: Ein HR-Orchestrator-Agent delegiert die einzelnen Aufgaben per A2A an spezialisierte Agenten: ein IT-Agent legt den AD-Account an, ein CRM-Agent erstellt den Nutzerzugang, ein Projektmanagement-Agent richtet die Zugänge ein. Jeder Agent meldet den Abschluss per A2A zurück. Der Orchestrator überwacht den Gesamtfortschritt.
Szenario 3: Kundenservice über Abteilungsgrenzen
Eine Kundenanfrage betrifft gleichzeitig eine Rechnung (Buchhaltung), eine Lieferverzögerung (Logistik) und eine Produktreklamation (Qualität). Heute wird die Anfrage dreimal weitergeleitet.
Mit A2A: Der Kundenservice-Agent zerlegt die Anfrage und delegiert die Teilfragen per A2A an den Buchhaltungsagenten, den Logistikagenten und den Qualitätsagenten. Jeder bearbeitet seinen Teil parallel. Der Kundenservice-Agent fasst die Ergebnisse zusammen und antwortet dem Kunden — alles in einem Durchgang.
„Die strategische Dimension von A2A ist nicht die Technik. Es ist die Organisationsveränderung: Wenn Agenten über Abteilungsgrenzen hinweg zusammenarbeiten können, lösen sich Silos auf — nicht durch Reorganisation, sondern durch Infrastruktur." — Jamin Mahmood-Wiebe, Gründer von IJONIS
Was bedeutet die Governance durch die Linux Foundation?
Google hätte A2A als eigenen Standard behalten können — so wie viele Tech-Konzerne ihre Protokolle kontrollieren. Die bewusste Entscheidung, A2A an die Linux Foundation zu übergeben, sendet ein klares Signal an den Markt: Dieser Standard gehört der Branche, nicht einem einzelnen Unternehmen.
- Neutralität: Kein einzelnes Unternehmen kontrolliert die Weiterentwicklung
- Offenheit: Jedes Unternehmen kann A2A implementieren, ohne Lizenzgebühren
- Langlebigkeit: Die Linux Foundation verwaltet auch Linux, Kubernetes und Node.js — Projekte mit Jahrzehnten an Stabilität
- Vertrauen: Enterprise-Entscheidende vertrauen Linux-Foundation-Projekten, weil die Governance transparent ist
Für Unternehmen bedeutet das: A2A ist kein Vendor-Experiment. Es ist ein Infrastrukturstandard mit institutioneller Absicherung.
So starten Sie mit A2A: Drei Phasen
Eine erfolgreiche A2A-Einführung folgt drei Phasen: Bestandsaufnahme, Pilotprojekt und Skalierung. Die meisten Unternehmen können den ersten Pilot in sechs Wochen abschließen. Der Schlüssel ist, klein zu starten — zwei Agenten in einem Workflow verbinden — und dann schrittweise zu erweitern.
Phase 1: Bestandsaufnahme (Woche 1-2)
Bevor Sie A2A implementieren, brauchen Sie Klarheit über Ihre bestehende Agentenlandschaft. Welche Agenten sind im Einsatz, wo kommunizieren sie bereits miteinander, und welche MCP-Grundlagen sind vorhanden? Diese Analyse bildet das Fundament für alle weiteren Schritte:
- Agenten-Inventar: Welche KI-Agenten sind im Einsatz? Wer betreibt sie? Welche Frameworks nutzen sie?
- Kommunikationsmuster: Welche Agenten müssen heute schon zusammenarbeiten? Wo passiert das manuell?
- MCP-Status: Haben Sie bereits MCP-Server im Einsatz? A2A baut auf dieser Grundlage auf.
Phase 2: Pilotprojekt (Woche 3-6)
Wählen Sie einen konkreten Workflow, der zwei Agenten verbindet. Der ideale Pilot ist ein Prozess, der heute manuell koordiniert wird und bei dem zwei Agenten klar abgrenzbare Aufgaben haben. Beschaffung und Compliance oder HR und IT sind bewährte Startpunkte:
- Agent Cards definieren: Beschreiben Sie die Fähigkeiten beider Agenten als Agent Cards
- Task-Flows modellieren: Definieren Sie die Aufgaben, die ein Agent an den anderen delegiert
- Sicherheit konfigurieren: OAuth 2.0 oder API Keys für die Agent-zu-Agent-Authentifizierung einrichten
- Monitoring aufsetzen: Jede Task-Interaktion protokollieren — für Debugging und Compliance
Phase 3: Skalierung (ab Woche 7)
Nach dem erfolgreichen Pilot erweitern Sie schrittweise. Ziel ist eine unternehmensweite Agentenlandschaft, in der jeder Agent per Agent Card auffindbar ist und Aufgaben standardisiert delegieren kann. Die Skalierung umfasst drei Kernbereiche:
- Weitere Agenten mit Agent Cards ausstatten
- Ein zentrales Agent-Verzeichnis aufbauen (Agent Registry)
- Governance-Regeln definieren: Welche Agenten dürfen welche Tasks an wen delegieren?
- Die Agentenlandschaft in Ihr Agent OS integrieren
Sicherheit und Compliance bei A2A
A2A wurde von Anfang an für den Einsatz in Unternehmen gebaut. Sicherheit ist kein Nachgedanke, sondern fester Teil des Standards. Unternehmen können auf bewährte Verfahren zurückgreifen, die sie bereits aus der API-Welt kennen: OAuth, TLS und strukturiertes Logging. Ein neuer Sicherheitsstack ist für die A2A-Einführung nicht nötig.
Authentifizierung und Autorisierung
A2A unterstützt mehrere Sicherheitsschichten, die Unternehmen flexibel kombinieren können. Je nach Sensitivität der Daten und Kommunikation wählen Teams das passende Verfahren — von einfachen API Keys bis hin zu beidseitiger Zertifikatsauthentifizierung:
- OAuth 2.0: Standardisierte Token-basierte Authentifizierung zwischen Agenten
- API Keys: Für einfachere Integrationen mit begrenztem Funktionsumfang
- mTLS (Mutual TLS): Beidseitige Zertifikatsauthentifizierung für hochsensible Kommunikation
- Scope-basierte Berechtigungen: Nicht jeder Agent darf jede Task-Art delegieren
EU AI Act und Nachvollziehbarkeit
Die Task-basierte Architektur von A2A unterstützt die Anforderungen des EU AI Act direkt. Jede Interaktion zwischen Agenten wird strukturiert protokolliert, sodass Unternehmen jederzeit nachweisen können, welcher Agent welche Entscheidung getroffen hat und auf welcher Datenbasis:
- Jede Task hat eine eindeutige ID, einen definierten Lebenszyklus und protokollierbare Ein-/Ausgaben
- Die Agent Card dokumentiert, welcher Agent welche Entscheidung getroffen hat
- Artifacts sind nachvollziehbare Arbeitsergebnisse mit klarem Ursprung
Für Unternehmen im DACH-Raum, die bereits DSGVO-konforme KI-Systeme betreiben, ist A2A eine natürliche Erweiterung der bestehenden Compliance-Architektur.
A2A-Entwicklung als Standard ab 2026
Die Geschwindigkeit ist beeindruckend. Von Googles erster Ankündigung im April 2025 bis zur Übergabe an die Linux Foundation und der Unterstützung durch über 100 Firmen vergingen nur wenige Monate. Das zeigt: Der Markt wartet auf diesen Standard. Drei zentrale Entwicklungen werden die nächsten zwei Jahre der A2A-Evolution in der Unternehmenslandschaft prägen.
Drei Entwicklungen, die 2026 und 2027 prägen werden:
1. Vendor-native A2A-Support: SAP, Salesforce und ServiceNow werden A2A-Endpunkte direkt in ihre Produkte integrieren. Das bedeutet: Ihre bestehenden Unternehmensanwendungen werden A2A-fähig, ohne Custom-Entwicklung.
2. Agent Marketplaces: Wenn Agenten standardisierte Agent Cards veröffentlichen, entstehen Marktplätze für spezialisierte Agenten. Ein Unternehmen kann einen Compliance-Agenten „buchen", der per A2A mit den eigenen Agenten zusammenarbeitet — ohne individuelle Integration. Schon heute bieten wir vorkonfigurierte KI-Agenten mit transparenten Preisen ab 1.500 EUR Setup, die sich später in eine A2A-Landschaft einfügen lassen.
3. Multi-Vendor-Orchestrierung: Die Orchestrierungsschicht wird zum zentralen Kontrollpunkt für Agenten mehrerer Anbieter. A2A macht das technisch möglich; die Governance macht es organisatorisch beherrschbar.
FAQ: Agent2Agent Protocol im Unternehmen
Im Folgenden beantworten wir die häufigsten Fragen, die uns Enterprise-Teams bei der Evaluierung von A2A stellen. Jede Antwort liefert die wichtigsten Fakten, die Sie für eine fundierte Entscheidung über die Einführung des Protokolls in Ihrer Organisation benötigen.
Was unterscheidet A2A von einer normalen API-Integration?
Eine API-Integration verbindet ein System mit einem anderen — fest verdrahtet und für einen spezifischen Zweck. A2A definiert ein universelles Kommunikationsprotokoll: Jeder A2A-fähige Agent kann mit jedem anderen A2A-fähigen Agenten kommunizieren, ohne individuelle Integration. Der Unterschied ist vergleichbar mit dem zwischen einem Punkt-zu-Punkt-Telefon und dem Internet.
Brauche ich A2A, wenn ich nur einen KI-Anbieter nutze?
Wenn alle Ihre Agenten von einem Anbieter stammen, bietet der Anbieter oft eigene Koordinationsmechanismen. A2A wird relevant, sobald Sie Agenten mehrerer Anbieter einsetzen — oder wenn Sie sich die Flexibilität bewahren wollen, den Anbieter zu wechseln, ohne Ihre Agenten-Architektur neu zu bauen. Selbst bei einem Einzelanbieter kann A2A sinnvoll sein: Es schützt vor Vendor Lock-in und macht Ihre Architektur zukunftssicher für den Moment, in dem Sie einen zweiten Anbieter ergänzen.
Wie sicher ist die Agent-zu-Agent-Kommunikation mit A2A?
A2A unterstützt OAuth 2.0, API Keys und mTLS — dieselben Sicherheitsmechanismen, die auch für REST-APIs und Microservices gelten. Die Sicherheit liegt in der Implementierung: verschlüsselte Verbindungen, Berechtigungsmanagement pro Agent und lückenlose Protokollierung aller Task-Interaktionen.
Kann A2A auch im eigenen Rechenzentrum betrieben werden?
Ja, das ist ohne Einschränkung möglich. A2A basiert auf HTTP/HTTPS und JSON-RPC — das sind Technologien, die in jeder Firmen-IT bereits im Einsatz sind. Lokale Betriebsmodelle werden vollständig unterstützt. Für Unternehmen mit strengen Vorgaben zur Datenhaltung in Deutschland oder der EU ist das besonders wichtig.
Wie verhält sich A2A zu bestehenden Agentic Workflows?
A2A erweitert bestehende Agentic Workflows. Wenn Sie heute einen Orchestrator-Agenten haben, der Teilaufgaben an spezialisierte Agenten delegiert, kann A2A diese Delegation standardisieren — insbesondere über Systemgrenzen und Anbieter hinweg. Die Workflow-Logik bleibt dieselbe; nur die Kommunikationsschicht wird standardisiert.
Fazit: A2A + MCP = Die Infrastruktur für Enterprise AI
Das Agent2Agent Protocol schließt die letzte große Lücke in der KI-Agenten-Infrastruktur. MCP löst den Zugriff auf Daten und Werkzeuge. A2A löst die Kommunikation zwischen Agenten. Zusammen bilden sie das Fundament, auf dem Multi-Agent-Systeme im Unternehmen realistisch werden. Die Standards sind offen, anbieterneutral und bauen auf Web-Technologien auf, die jedes IT-Team bereits kennt.
Für Entscheidende im Mittelstand bedeutet das: Die Bausteine für eine unternehmensweite KI-Agenten-Architektur sind da. Die Standards sind offen, die großen Anbieter haben sich committed, und die Implementierung baut auf vertrauter Web-Infrastruktur auf.
Der richtige Zeitpunkt zum Einstieg ist jetzt — nicht weil der Markt es verlangt, sondern weil die Architekturentscheidungen von heute bestimmen, wie flexibel Ihre KI-Infrastruktur in drei Jahren sein wird.
Sie wollen A2A und MCP in Ihrer IT-Landschaft evaluieren? Sprechen Sie mit unseren Architekturexperten in Hamburg — wir analysieren Ihre Agentenlandschaft und identifizieren die Zusammenarbeitslösung, die den größten Hebel für Ihre KI-Strategie bietet.
Wie bereit ist Ihr Unternehmen für KI? Finden Sie es in 3 Minuten heraus — mit unserem kostenlosen, KI-gestützten Readiness-Check. Jetzt Check starten →

