A2A und MCP erklärt: Wann KI-Agenten im Mittelstand miteinander sprechen sollten

Veröffentlicht am

MCP gibt einem Agenten Werkzeuge, A2A lässt Agenten zusammenarbeiten. Was das Agent2Agent-Protokoll in Version 1.0 regelt, wann es für Deinen Betrieb relevant wird und was Du bei der Sicherheit klären solltest.

Wer sich mit KI-Agenten beschäftigt, stolpert inzwischen über zwei Abkürzungen: MCP und A2A. Beide sind offene Protokolle, beide klingen nach Infrastruktur für Fachleute, und beide werden in Präsentationen gern in einem Atemzug genannt. Für einen mittelständischen Betrieb ist die eigentliche Frage aber eine andere: Brauchen wir das überhaupt, und wenn ja, wofür genau?

Dieser Beitrag erklärt ohne Hype, was das Agent2Agent-Protokoll (A2A) regelt, wie es sich vom Model Context Protocol (MCP) unterscheidet und in welchen Situationen es für Dich relevant wird. Kurz vorweg: Die meisten Betriebe kommen am Anfang mit einem gut gebauten Agenten und ein paar sauber angebundenen Werkzeugen sehr weit.

Was A2A ist und wer dahintersteht

A2A ist ein offener Standard für die Kommunikation zwischen eigenständigen KI-Agenten. Google hat das Protokoll im April 2025 vorgestellt, im Juni 2025 wurde es an die Linux Foundation übergeben. Laut der Ankündigung der Linux Foundation gehören unter anderem AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow zu den Gründungsmitgliedern des Projekts. Seit März 2026 liegt die Spezifikation in Version 1.0 vor.

Das Ziel laut Spezifikation: Agenten, die mit unterschiedlichen Frameworks, in unterschiedlichen Sprachen oder von unterschiedlichen Anbietern gebaut wurden, sollen sich gegenseitig finden, Fähigkeiten aushandeln, gemeinsam an Aufgaben arbeiten und Informationen austauschen, ohne Zugriff auf das Innenleben des anderen Agenten zu bekommen. Der andere Agent bleibt eine Blackbox. Du siehst, was er kann und was er liefert, aber nicht seine Werkzeuge, seinen Speicher oder seine Daten.

MCP und A2A: vertikal und horizontal

Die offizielle Dokumentation beschreibt den Unterschied mit einem einfachen Bild, nachzulesen im Vergleich A2A and MCP:

  • MCP ist vertikal. Es macht einen einzelnen Agenten fähiger. Jede MCP-Verbindung gibt dem Agenten ein weiteres Werkzeug oder eine weitere Datenquelle, etwa eine Datenbankabfrage, ein Ticketsystem oder eine Suche in Google Drive.
  • A2A ist horizontal. Es verbindet Agenten über Grenzen hinweg, zum Beispiel zwischen Abteilungen, Teams oder Partnerunternehmen. Ein Agent fragt einen anderen Agenten um Hilfe, statt selbst alles zu können.

Werkzeuge haben klar definierte Eingaben und Ausgaben und erledigen meist eine einzelne, oft zustandslose Aufgabe. Agenten dagegen planen, nutzen mehrere Werkzeuge, führen Rückfragen und behalten den Stand einer Aufgabe über längere Zeit. Genau diese längeren, mehrstufigen Abläufe zwischen Agenten deckt A2A ab. Wie Du MCP-Server sicher anbindest, haben wir in MCP-Server sicher anbinden ausführlich beschrieben.

Die wichtigsten Bausteine von A2A

Für Entscheider reicht es, fünf Begriffe zu kennen. Sie stammen aus den Kernkonzepten der A2A-Dokumentation:

  • Agent Card: eine Art digitale Visitenkarte im JSON-Format. Sie beschreibt Name, Endpunkt, Fähigkeiten (Skills) und die geforderte Authentifizierung eines Agenten. Öffentliche Agenten legen sie üblicherweise unter /.well-known/agent-card.json ab, in Unternehmen sind auch interne Verzeichnisse oder feste Konfiguration üblich.
  • Task: eine Aufgabe mit eigener ID und Lebenszyklus. Ein Task kann Minuten oder Stunden laufen, Rückfragen stellen und Zwischenstände melden.
  • Message: eine einzelne Nachricht im Austausch, zum Beispiel eine Anweisung oder eine Rückfrage.
  • Part: der eigentliche Inhalt, also Text, eine Datei oder strukturierte Daten.
  • Artifact: das Ergebnis, das ein Agent abliefert, etwa ein Dokument oder ein Datensatz.

Für lange Aufgaben sieht A2A drei Wege vor: regelmäßiges Abfragen des Status, Streaming über Server-Sent Events und Push-Benachrichtigungen an einen Webhook. Technisch läuft alles über HTTPS, die Spezifikation definiert Bindungen für JSON-RPC, gRPC und HTTP/REST.

Ein Beispiel aus dem Betriebsalltag

Stell Dir einen Vertriebsagenten vor, der in Gmail Kundenanfragen vorsortiert und Antwortentwürfe vorbereitet. Fragt ein Kunde nach einem Liefertermin, braucht der Agent Informationen, die er selbst nicht hat. Es gibt zwei Wege:

  1. Mit MCP: Der Vertriebsagent bekommt ein Werkzeug, das direkt im Warenwirtschaftssystem nach Bestand und Terminen sucht. Das ist der richtige Weg, wenn die Abfrage klar umrissen ist und Ihr das Werkzeug selbst kontrolliert.
  2. Mit A2A: Der Vertriebsagent fragt einen Disponenten-Agenten, den ein anderes Team oder ein Dienstleister betreibt. Dieser Agent prüft Kapazitäten, stellt bei Bedarf eine Rückfrage und liefert eine begründete Terminaussage zurück. Das passt, wenn die Aufgabe Urteilsvermögen, mehrere Schritte oder Wissen einer anderen Einheit braucht.

In der Praxis landen viele Betriebe bei einer Mischung: Jeder Agent nutzt über MCP seine eigenen Werkzeuge, und dort, wo Agenten verschiedener Teams oder Firmen zusammenarbeiten, kommt A2A ins Spiel. Der Kundenentwurf geht trotzdem erst nach Freigabe durch einen Menschen raus.

Wann A2A für den Mittelstand relevant wird

A2A lohnt sich vor allem in drei Situationen:

  • Mehrere Agenten, verschiedene Plattformen: Wenn ein Agent mit dem Agent Development Kit von Google gebaut ist und ein anderer mit dem Microsoft Agent Framework, brauchst Du einen gemeinsamen Standard. Beide unterstützen A2A, siehe die Dokumentation zu ADK mit A2A und zur A2A-Integration im Microsoft Agent Framework.
  • Agenten von Anbietern: Immer mehr Softwareanbieter liefern eigene Agenten mit. Statt für jeden eine eigene Schnittstelle zu bauen, kann Euer Agent über A2A mit ihnen sprechen, sofern der Anbieter A2A unterstützt.
  • Zusammenarbeit über Firmengrenzen: Lieferanten, Logistiker oder Kunden betreiben eigene Agenten. A2A erlaubt den Austausch, ohne dass jemand seine internen Systeme offenlegen muss.

Wenn Du dagegen gerade erst mit einem einzelnen Assistenten für Mails, Angebote oder Wissenssuche startest, brauchst Du A2A noch nicht. Ein Multi-Agent-System lohnt sich erst, wenn ein einzelner Agent an seine Grenzen stößt. Wie Du solche Systeme mit menschlicher Freigabe aufbaust, zeigt unser Beitrag Multi-Agent-Systeme mit Human in the Loop.

Sicherheit: Was Du vor dem ersten A2A-Agenten klären solltest

Ein Agent, der mit fremden Agenten spricht, öffnet eine neue Tür. Die Spezifikation setzt auf bewährte Websicherheit: Die Agent Card nennt die nötige Authentifizierung, Zugangsdaten wie OAuth-Token laufen über HTTP-Header. Die Dokumentation zur Agent Discovery empfiehlt außerdem, Agent Cards mit sensiblen Angaben nur authentifiziert auszuliefern und keine festen Geheimnisse in die Karte zu schreiben. Für Deinen Betrieb heißt das:

  • Nur bekannte Partner: Lege fest, mit welchen Agenten Eure Agenten sprechen dürfen. Eine offene Suche nach beliebigen Agenten im Internet ist für Geschäftsprozesse keine gute Idee.
  • Antworten sind Eingaben von außen: Was ein fremder Agent liefert, kann falsch oder manipuliert sein. Behandle es wie eine Mail von außen und prüfe es, bevor es Aktionen auslöst. Mehr dazu in Guardrails gegen Prompt Injection.
  • Minimale Rechte: Ein Agent, der Anfragen von anderen Agenten annimmt, darf nur genau die Skills anbieten, die er anbieten soll, mit möglichst wenig Zugriff auf Eure Daten.
  • Protokollieren: Jeder Task zwischen Agenten sollte nachvollziehbar sein, wer was wann angefragt und geliefert hat. Wie Du das technisch aufsetzt, steht in Observability für KI-Agenten.
  • Datenschutz klären: Sobald personenbezogene Daten zwischen Agenten verschiedener Firmen fließen, braucht es die passenden Verträge, genau wie bei jeder anderen Schnittstelle.

So gehst Du pragmatisch vor

  1. Inventur: Welche Agenten oder KI-Assistenten nutzt Ihr schon, welche bringen Eure Softwareanbieter mit?
  2. Ein Agent zuerst: Baue einen Agenten für einen klaren Ablauf, mit Werkzeugen über MCP oder direkte Schnittstellen und mit menschlicher Freigabe.
  3. Übergaben erkennen: Notiere, an welchen Stellen der Agent auf Wissen oder Entscheidungen einer anderen Einheit angewiesen ist. Das sind die Kandidaten für A2A.
  4. Pilot mit einem Partner: Teste A2A zuerst zwischen zwei Euch bekannten Agenten, mit festen Agent Cards, Authentifizierung und Protokollierung.
  5. Erst dann skalieren: Weitere Agenten oder externe Partner kommen dazu, wenn der Pilot stabil und nachvollziehbar läuft.

Fazit

MCP gibt einem Agenten Werkzeuge, A2A lässt Agenten zusammenarbeiten. Beide Protokolle ergänzen sich, und mit der Version 1.0 unter dem Dach der Linux Foundation ist A2A ein ernstzunehmender Standard. Für die meisten Betriebe ist A2A aber kein erster Schritt, sondern ein zweiter oder dritter: Erst ein Agent, der zuverlässig arbeitet, dann die Verbindung zu anderen.

Ob Dein Betrieb für Agenten bereit ist, zeigt Dir unser AI-Readiness-Check, Hintergründe liefert das AI-Readiness-Whitepaper. Wenn Du einen konkreten Ablauf mit einem oder mehreren Agenten planen willst: Kostenloses Erstgespräch vereinbaren.