AI Frameworks · 9 Min.
A2A Agent2Agent Google: Was Enterprise-Teams jetzt verstehen muessen
A2A macht Agenten interoperabler. Fuer Unternehmen wird es aber erst wertvoll, wenn Delegation, Identitaet, Datenweitergabe und Freigaben sauber geregelt sind.
SYSTEMS Grafik zu A2A Agent2Agent Google: Data -> Agent -> Outcome. Fokus: Was Googles A2A-Protokoll fuer Enterprise-Agenten bedeutet und welche Architekturentscheidungen vor einem Rollout wichtig sind.
Kurzfassung
A2A ist ein offenes Protokoll fuer Agent-zu-Agent-Kommunikation, nicht einfach ein weiterer Tool-Connector. Fuer Unternehmen wird A2A relevant, wenn Agenten von verschiedenen Teams, Plattformen oder Partnern kontrolliert zusammenarbeiten sollen. Die groesste Architekturfrage ist nicht Verbindung, sondern Delegation: Welche Daten, Rechte, Aufgaben und Ergebnisse duerfen zwischen Agenten wandern?
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Warum A2A gerade wichtig wird Viele Unternehmen bauen gerade die zweite Generation ihrer AI-Agenten. Die erste Generation war meist ein einzelner Agent mit ein paar Tools. Die naechste Generation besteht aus mehreren spezialisierten Agenten: Research, Vertrieb, Support, Compliance, Operations, Engineering.
Sobald Agenten nicht mehr allein arbeiten, entsteht eine neue Frage. Wie findet ein Agent einen anderen Agenten? Wie beschreibt ein Agent seine Faehigkeiten? Wie wird ein Auftrag uebergeben? Wie kommt Status zurueck? Und wie bleibt klar, wer am Ende verantwortlich ist?
Genau hier setzt A2A an. Google hat das Agent2Agent Protocol als offenes Protokoll angekuendigt, damit Agenten ueber Plattform- und Anbietergrenzen hinweg zusammenarbeiten koennen. Fuer Enterprise-Teams ist das kein kleines Detail. Es ist ein Hinweis darauf, dass Agentenlandschaften modularer werden.
Was A2A leistet A2A beschreibt eine Kommunikationsschicht zwischen Agenten. Ein Agent kann sich auffindbar machen, seine Faehigkeiten beschreiben, Aufgaben annehmen, Status liefern und Ergebnisse zurueckgeben.
Das klingt technisch, ist aber organisatorisch wichtig.
Ein Unternehmen will vielleicht nicht einen riesigen Universal-Agenten bauen. Es will getrennte Agenten mit klarer Ownership:
A2A macht solche Grenzen sichtbarer. Agenten koennen miteinander arbeiten, ohne dass alle in dieselbe Codebase, dasselbe Framework oder denselben Anbieter gepresst werden muessen.
ein Sales-Research-Agent gehoert dem Revenue-Team ein Vertragspruefungs-Agent gehoert Legal oder Compliance ein Support-Agent gehoert Customer Operations ein Daten-Agent gehoert Data oder IT ein externer Partner-Agent gehoert einem Dienstleister A2A ist nicht MCP Der wichtigste Punkt fuer saubere Architektur: A2A und MCP loesen verschiedene Probleme.
MCP verbindet Agenten mit Tools, Datenquellen und Kontext. Ein MCP-Server kann Dateien, CRM-Daten, Tickets, Datenbanken oder interne APIs bereitstellen.
A2A verbindet Agenten mit anderen Agenten. Es geht um Delegation und Zusammenarbeit.
Ein guter Vergleich:
In echten Systemen kommen beide Schichten zusammen. Ein Orchestrator kann per A2A einen Research-Agenten beauftragen. Dieser Research-Agent nutzt ueber MCP interne Quellen. Danach geht das Ergebnis per A2A zurueck an den Orchestrator. Wenn der Orchestrator anschliessend einen Outreach-Entwurf erstellt, braucht vielleicht ein Compliance-Agent eine Freigabe.
Wer A2A und MCP vermischt, verliert schnell die Rechtekontrolle.
MCP fragt: Welches Tool darf dieser Agent nutzen? A2A fragt: Welchen anderen Agenten darf dieser Agent beauftragen? Gemini Enterprise als Plattform-Kontext Google positioniert A2A nicht nur als abstrakte Spezifikation. In Gemini Enterprise koennen Administratoren A2A-Agenten registrieren und verwalten. Die Google-Dokumentation beschreibt dabei auch Agenten, die von einer Organisation selbst gebaut und dann in Gemini Enterprise verfuegbar gemacht werden.
Das ist fuer Unternehmen interessant, weil der Agent nicht mehr nur ein isolierter Service ist. Er wird Teil eines verwalteten Agenten-Portfolios.
Wichtige Plattformfragen:
A2A ist damit auch ein Governance-Thema. Es reicht nicht, Agenten technisch erreichbar zu machen. Sie muessen als betriebliche Faehigkeiten verwaltet werden.
Wer darf einen A2A-Agenten registrieren? Welche Agenten sind fuer welche Nutzer sichtbar? Welche Agenten sind intern, welche extern? Wie wird ein Agent aktualisiert oder entfernt? Welche Verantwortlichkeit hat der registrierende Bereich? Welche Freigaben braucht ein Agent, bevor er produktiv genutzt wird? Die gefaehrliche Stelle: Delegation mit Rechten Agentenkommunikation wird riskant, wenn Rechte indirekt wandern.
Beispiel: Ein Vertriebs-Agent darf auf CRM-Daten zugreifen. Er delegiert eine Analyse an einen Research-Agenten. Darf der Research-Agent die CRM-Daten sehen? Darf er sie speichern? Darf er einen dritten Agenten beauftragen? Darf er das Ergebnis in ein anderes System schreiben?
Ohne klare Regeln entstehen transitive Rechte. Das ist einer der haertesten Punkte in Multi-Agent -Architekturen.
Ein A2A-Rollout braucht deshalb Regeln fuer:
Die technische Verbindung ist der leichte Teil. Die Rechtearchitektur ist der eigentliche Enterprise-Teil.
Datenweitergabe zwischen Agenten Zweckbindung pro Auftrag Ergebnisrueckgabe und Speicherung Schreibrechte nach Delegation menschliche Freigaben vor externen Aktionen Logs fuer Agentenaufrufe und Tool-Nutzung Stop-Regeln bei fehlender Berechtigung Wann A2A fuer Unternehmen Sinn ergibt A2A ist nicht fuer jedes Projekt der richtige erste Schritt. Viele Teams sollten zuerst einen einzelnen Agenten mit sauberem MCP-Zugriff, Evals und Monitoring bauen.
A2A wird sinnvoll, wenn:
Dann hilft A2A, Agentenlandschaften modular zu halten.
mehrere spezialisierte Agenten entstehen Agenten von verschiedenen Teams betrieben werden Partner- oder Vendor-Agenten angebunden werden sollen Plattformgrenzen bewusst offen bleiben sollen Aufgaben laenger laufen und Status brauchen Agenten ihre Faehigkeiten auffindbar machen sollen ein zentraler Orchestrator nicht alles selbst koennen soll Was vor einem A2A-Rollout stehen sollte Ein pragmatischer Rollout beginnt nicht mit Protokollen, sondern mit Prozesskarten.
Vor A2A sollten Unternehmen klaeren:
Erst danach ergibt eine A2A-Implementierung Sinn.
Welche Arbeit soll wirklich zwischen Agenten delegiert werden? Welche Agentenrollen sind klein genug, um kontrollierbar zu bleiben? Welche Daten duerfen pro Rolle genutzt werden? Welche Aufgaben duerfen automatisch abgeschlossen werden? Welche Aufgaben brauchen menschliche Freigabe? Welche Evals pruefen Ergebnisqualitaet? Welche Logs beweisen spaeter, was passiert ist? Welche Agenten duerfen extern oder plattformuebergreifend arbeiten? Der SYSTEMS-Blick auf A2A A2A ist ein starkes Signal: Agenten werden nicht nur einzelne Assistenten bleiben. Sie werden zu modularen Systemen, die ueber Grenzen hinweg Aufgaben austauschen.
Aber genau deshalb muss die Architektur sauber sein. A2A ohne Rechte, Logs, Freigaben und Evals erzeugt nur eine schnellere Form von Unklarheit. A2A mit klaren Agentenrollen, MCP-Toolgrenzen, Governance und Betriebslogik kann dagegen echte Arbeit verteilbar machen.
SYSTEMS betrachtet A2A deshalb als Kommunikationsschicht in einem groesseren AI-Operating-System. Erst Workflow, Rolle und Risiko. Dann Protokoll. Dann Betrieb.
