AI Frameworks · 9 Min.
A2A Agent2Agent Google: Was Enterprise-Teams jetzt verstehen müssen
A2A macht Agenten interoperabler. Für Unternehmen wird es aber erst wertvoll, wenn Delegation, Identität, Datenweitergabe und Freigaben sauber geregelt sind.
SYSTEMS Grafik zu A2A Agent2Agent Google: Data -> Agent -> Outcome. Fokus: Was Googles A2A-Protokoll für Enterprise-Agenten bedeutet und welche Architekturentscheidungen vor einem Rollout wichtig sind.
Kurzfassung
A2A ist ein offenes Protokoll für Agent-zu-Agent-Kommunikation, nicht einfach ein weiterer Tool-Connector. Für Unternehmen wird A2A relevant, wenn Agenten von verschiedenen Teams, Plattformen oder Partnern kontrolliert zusammenarbeiten sollen. Die größte Architekturfrage ist nicht Verbindung, sondern Delegation: Welche Daten, Rechte, Aufgaben und Ergebnisse dürfen zwischen Agenten wandern?
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten 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 nächste 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 Fähigkeiten? Wie wird ein Auftrag übergeben? Wie kommt Status zurück? Und wie bleibt klar, wer am Ende verantwortlich ist?
Genau hier setzt A2A an. Google hat das Agent2Agent Protocol als offenes Protokoll angekündigt, damit Agenten über Plattform- und Anbietergrenzen hinweg zusammenarbeiten können. Für 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 Fähigkeiten beschreiben, Aufgaben annehmen, Status liefern und Ergebnisse zurückgeben.
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 können miteinander arbeiten, ohne dass alle in dieselbe Codebase, dasselbe Framework oder denselben Anbieter gepresst werden müssen.
ein Sales-Research-Agent gehört dem Revenue-Team ein Vertragsprüfungs-Agent gehört Legal oder Compliance ein Support-Agent gehört Customer Operations ein Daten-Agent gehört Data oder IT ein externer Partner-Agent gehört einem Dienstleister A2A ist nicht MCP Der wichtigste Punkt für saubere Architektur: A2A und MCP lösen 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 über MCP interne Quellen. Danach geht das Ergebnis per A2A zurück 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 können Administratoren A2A-Agenten registrieren und verwalten. Die Google-Dokumentation beschreibt dabei auch Agenten, die von einer Organisation selbst gebaut und dann in Gemini Enterprise verfügbar gemacht werden.
Das ist für 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 müssen als betriebliche Fähigkeiten verwaltet werden.
Wer darf einen A2A-Agenten registrieren? Welche Agenten sind für 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 gefährliche 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 härtesten Punkte in Multi-Agent -Architekturen.
Ein A2A-Rollout braucht deshalb Regeln für:
Die technische Verbindung ist der leichte Teil. Die Rechtearchitektur ist der eigentliche Enterprise-Teil.
Datenweitergabe zwischen Agenten Zweckbindung pro Auftrag Ergebnisrückgabe und Speicherung Schreibrechte nach Delegation menschliche Freigaben vor externen Aktionen Logs für Agentenaufrufe und Tool-Nutzung Stop-Regeln bei fehlender Berechtigung Wann A2A für Unternehmen Sinn ergibt A2A ist nicht für 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 länger laufen und Status brauchen Agenten ihre Fähigkeiten auffindbar machen sollen ein zentraler Orchestrator nicht alles selbst können soll Was vor einem A2A-Rollout stehen sollte Ein pragmatischer Rollout beginnt nicht mit Protokollen, sondern mit Prozesskarten.
Vor A2A sollten Unternehmen klären:
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 dürfen pro Rolle genutzt werden? Welche Aufgaben dürfen automatisch abgeschlossen werden? Welche Aufgaben brauchen menschliche Freigabe? Welche Evals prüfen Ergebnisqualität? Welche Logs beweisen später, was passiert ist? Welche Agenten dürfen extern oder plattformübergreifend arbeiten? Der SYSTEMS-Blick auf A2A A2A ist ein starkes Signal: Agenten werden nicht nur einzelne Assistenten bleiben. Sie werden zu modularen Systemen, die über 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 größeren AI-Operating-System. Erst Workflow, Rolle und Risiko. Dann Protokoll. Dann Betrieb.
