Dein Lieferant schreibt dir, sein Agent spreche schon A2A und deiner könne sich morgen anschließen. Klingt nach Installation, nach einem Nachmittag Entwicklungsarbeit. Sobald aber zwei Agenten zweier verschiedener Organisationen eine Aufgabe aushandeln – eine Bestellung, einen Termin, eine Reklamation –, ist nicht mehr entscheidend, wie die Nachrichten reisen. Entscheidend ist, wer geradesteht, wenn die Nachricht stimmt und das Ergebnis nicht.
Die These in einem Satz: Das A2A-Protokoll für KI-Agenten zwischen Unternehmen löst den Transport und lässt das eigentliche Problem unberührt, nämlich das vertragliche. Für fast jeden Mittelständler ist die Entscheidung heute keine technische: Es geht darum, was du mit dem Betreiber des anderen Agenten unterschreibst, welche Rechte du deinem gibst und wie du ein Gespräch rekonstruierst, das keine der beiden Seiten vollständig sieht.
A2A-Protokoll und KI-Agenten zwischen Unternehmen: was es löst und was offen bleibt
A2A (Agent2Agent) ist ein offenes Protokoll, mit dem ein Agent Arbeit an einen anderen übergibt, ohne zu wissen, wie dieser innen gebaut ist. Es entstand bei Google, und die Linux Foundation hat am 9. April 2026 die Version 1.0 angekündigt, die erste stabile Spezifikation, mit mehr als 150 unterstützenden Organisationen – laut der Stiftung selbst. Vorsicht bei der Zahl: Sie stammt aus einer Pressemitteilung derer, die den Standard vorantreiben, und misst Unterstützung, nicht Produktivbetrieb.
Es hat zwei Hauptbausteine. Die „Agent Card“, ein Dokument, das sagt, wer der Agent ist, was er kann und wie man sich authentifiziert, und das in 1.0 signiert sein kann. Und einen Lebenszyklus für Aufgaben mit Standardzuständen: in Arbeit, abgeschlossen, fehlgeschlagen, abgelehnt, wartet auf Eingaben, wartet auf Autorisierung.
Was es nicht tut, wiegt so schwer wie das, was es tut. Laut Spezifikation arbeitet jeder Agent mit dem anderen zusammen, ohne Zugriff auf dessen internen Zustand, Speicher oder Werkzeuge. Das ist eine technische Tugend – jede Seite schützt ihre Implementierung – und zugleich das Governance-Problem: Der Agent deines Lieferanten ist für dich per Design eine Blackbox, und deiner ist es für ihn.
| Frage | Was A2A liefert | Was deinem Vertrag bleibt |
|---|---|---|
| Wer ist der andere Agent? | Agent Card, signierbar | Wer sie ausstellt und wer für ihre Richtigkeit einsteht |
| Wie wird Arbeit angefragt und geliefert? | Standardnachrichten und Aufgabenzustände | Was als „geliefert“ gilt und wie lange man das anfechten kann |
| Wer darf was anfordern? | Im Web übliche Authentifizierungs- und Autorisierungsverfahren | Welcher Umfang wem gewährt wird und wie er widerrufen wird |
| Was, wenn er sich irrt? | Zustände „fehlgeschlagen“ oder „abgelehnt“ | Wer den Fehler trägt, wenn die Aufgabe als „abgeschlossen“ gilt und falsch ist |
| Wie wird geprüft? | Nichts Spezifisches | Was jede Partei protokolliert und wie lange |
Die letzte Spalte ist nicht nur unsere Meinung. Die Spezifikation beschränkt sich auf das Protokoll und überlässt Vertrauen, Verantwortung und Nachvollziehbarkeit zwischen Organisationen dem, der es einsetzt, und unabhängige Branchenanalysen sind sich einig, dass Sicherheit zwischen Organisationen die ungelöste Frage ist.
Wie unterscheidet sich A2A von MCP?
Kurze Antwort: MCP verbindet deinen Agenten mit deinen Werkzeugen; A2A verbindet deinen Agenten mit dem Agenten einer anderen Organisation. Bei MCP entscheidest du, welche Werkzeuge es gibt, was sie tun und mit welchen Zugangsdaten; das erklären wir in was MCP ist und warum es Unternehmens-Agenten verändert. Bei A2A sitzt auf der anderen Seite jemand, der selbst entscheidet – mit eigenem Modell, eigenen Fehlern und eigenem Änderungskalender. Es ist der Unterschied zwischen ein Werkzeug kaufen und eine Werkstatt beauftragen.
Ein hypothetisches Beispiel, ohne Namen
Der Einkaufsagent eines Kunden bittet den Vertriebsagenten seines Händlers, „dieses Material zum besten Preis nachzubestellen“. Der zweite antwortet mit Preis und Lieferzeit, und die Aufgabe wird als abgeschlossen markiert. Ist dieser Preis bindend? Ist die Lieferzeit eine Zusage? Wer hat geprüft, ob der Agent des Händlers die richtige Preisliste benutzt hat? Nichts davon steckt in der Nachricht. All das ist Vertrag, und wenn es nicht aufgeschrieben ist, entscheidet, wer am lautesten reklamiert.
Vier Vertragsfragen, bevor du deinen Agenten mit dem eines Dritten verbindest
1. Wer steht für das Ergebnis ein?
Kommt die Aufgabe als abgeschlossen an und das Ergebnis ist falsch – ein falsch bestätigter Preis, ein doppelter Termin, eine Bestellung mit falscher Menge –, hat das Protokoll keine Meinung. Der Vertrag muss eine haben: was als Lieferung gilt, wer sie prüft und wie lange man sie anfechten kann.
2. Was passiert, wenn der Agent der anderen Seite sich irrt?
Dein Agent handelt nach dem, was der andere ihm sagt. Erfindet der andere eine Lieferzeit und deiner verspricht sie deinem Kunden, ist der Fehler in den Augen des Kunden schon deiner. Lege vorab fest, was dein Agent mit einer externen Antwort allein tun darf und was eine menschliche Bestätigung braucht: Das ist die Logik der Autonomiestufen eines Agenten, angewandt auf eine Quelle, die du nicht kontrollierst.
3. Wie prüft man ein Gespräch zwischen zwei Blackboxen?
Jede Partei sieht nur ihre Hälfte. Um zu rekonstruieren, was passiert ist, musst du speichern, was dein Agent gesendet und empfangen hat, unter welcher Identität und mit welchem Ergebnis, und vereinbaren, dass die andere Seite ihres eine bestimmte Zeit aufbewahrt. Ohne das wird der erste Streit mit zwei unvereinbaren Erzählungen entschieden. Die Grundlage ist die Nachvollziehbarkeit von KI-Entscheidungen; für die Frist: wie lange KI-Agenten-Logs aufbewahren.
4. Was darf jede Seite anfordern, und wie wird es widerrufen?
Ein Agent, der nach außen spricht, öffnet eine neue Angriffsfläche. Gib ihm eine eigene Identität, einen Umfang pro Aufgabe und einen getesteten Widerruf, wie es der Leitfaden zu den Berechtigungen eines KI-Agenten beschreibt, und verlange dasselbe vom anderen. Eine signierte Agent Card belegt, wer der Agent ist; sie belegt nicht, dass er den Umfang verdient, den er anfordert.
Wann du A2A NICHT brauchst (noch nicht)
Drei Situationen, in denen die Einführung einem Problem vorgreift, das du nicht hast:
- Die andere Seite bietet eine normale API. Stellt dein Kunde oder Lieferant einen Dienst mit definierten Ein- und Ausgaben bereit, ist eine klassische Integration günstiger, leichter prüfbar und hängt nicht davon ab, dass zwei Modelle sich verstehen. A2A lohnt sich, wenn die Arbeit offen ist und verhandelt wird, nicht bei einer Abfrage mit geschlossener Antwort.
- Alle deine Agenten leben in deinem Unternehmen. Interne Koordination löst man mit Orchestrierung, nicht mit einem Standard zwischen Organisationen. Beginne mit dem Orchestrieren mehrerer KI-Agenten und mit der Frage, ob du einen Agenten oder viele brauchst.
- Niemand hat verlangt, dass dein Agent mit einem anderen spricht. Ein Protokoll mit vielen Unterstützer-Logos ist nicht gleich viele Produktivfälle: Die Branchenanalyse selbst trennt, einen Standard zu unterstützen, davon, ihn nach dem ersten echten Vorfall im Betrieb zu halten.
Was du diese Woche tun solltest
- Frage deine wichtigsten Lieferanten, ob ihr Agent A2A anbietet und was er heute schon per API anbietet. Lautet die Antwort „wir prüfen das“, kennst du den Zeitplan.
- Schreibe für den ersten Kandidatenfall die vier Fragen oben mit Namen und Anschrift auf: wer prüft, wer den Fehler trägt, was protokolliert wird und welcher Umfang gewährt wird.
- Lege fest, welche Entscheidungen deines Agenten eine menschliche Bestätigung brauchen, wenn die Daten von außen kommen, und teste das mit einer absichtlich falschen Antwort.
- Prüfe, ob dein Log Gesendetes und Empfangenes mit der Identität des handelnden Agenten speichert. Wenn nicht, behebe das, bevor du eine Verbindung öffnest.