AI Frameworks · 9 Min.
Agent2Agent Protocol: Warum A2A für Enterprise-Agenten wichtig wird
A2A adressiert ein Problem, das in Enterprise-AI jetzt sichtbar wird: Agenten müssen nicht nur Tools nutzen, sondern miteinander arbeiten können.
SYSTEMS Grafik zu Agent2Agent Protocol: Data -> Agent -> Outcome. Fokus: Warum A2A für Unternehmen relevant wird, sobald mehrere Agenten, Frameworks und Anbieter zusammenarbeiten sollen.
Kurzfassung
Das Agent2Agent Protocol standardisiert Kommunikation zwischen Agenten, die mit unterschiedlichen Frameworks, Plattformen oder Anbietern gebaut wurden. A2A ersetzt MCP nicht: MCP verbindet Agenten mit Tools und Ressourcen, A2A verbindet Agenten miteinander. Für Unternehmen wird A2A relevant, wenn einzelne Agenten zu einer Agentenlandschaft mit Delegation, Discovery, Governance und Observability werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum A2A jetzt auf die Architektur-Roadmap gehört Die erste AI-Welle in Unternehmen war Modellzugriff. Die zweite war Tool-Zugriff. Die dritte wird Agenten-Zusammenarbeit.
Ein einzelner Agent kann schon viel leisten: recherchieren, klassifizieren, Texte vorbereiten, Tickets analysieren, Daten lesen. Aber Unternehmensprozesse sind selten Ein-Agent-Probleme. Vertrieb, Support, Finance, Legal, Operations und Produkt arbeiten über Systemgrenzen hinweg.
Wenn jeder Bereich seinen eigenen Agenten baut, entsteht schnell ein neues Silo. Genau hier wird das Agent2Agent Protocol interessant. A2A soll Agenten ermöglichen, Aufgaben, Kontext und Ergebnisse standardisiert auszutauschen, auch wenn sie auf unterschiedlichen Plattformen laufen.
Für Entscheider ist das kein Protokoll-Detail. Es ist die Frage, wie eine Firma verhindert, dass AI wieder in getrennten Inseln endet.
Stand Mai 2026: A2A reift Richtung Enterprise-Standard A2A sollte nicht als eingefrorenes Endbild verstanden werden. Die offizielle Dokumentation zeigt einen bewegten Standard mit wachsender Enterprise-Formalisierung: Linux-Foundation-Kontext, Version Negotiation, mehrere Protokollbindungen, Agent-Card-Signaturen, Multi-Tenancy und klarere Sicherheitsmodelle.
Das macht A2A interessanter, aber auch anspruchsvoller. Wer heute A2A evaluiert, sollte nicht nur einen Demo-Agenten verbinden. Er sollte prüfen:
Der Punkt ist nicht, jeden neuen Protokollstand sofort einzubauen. Der Punkt ist, eine Agentenarchitektur so zu schneiden, dass Versionierung und Governance nicht später alles blockieren.
Welche A2A-Versionen müssen parallel unterstützt werden? Wie werden Agent Cards verifiziert? Welche Agenten laufen mandantenfähig auf einem Endpoint? Welche Transport-Bindings passen zur vorhandenen Plattform? Wie werden Breaking Changes und Migrationen getestet? Welche Delegationen brauchen Trace, Eval oder menschliche Freigabe? Was A2A von MCP unterscheidet MCP und A2A werden oft zusammen genannt, lösen aber unterschiedliche Probleme.
MCP ist agent-to-tool. Ein Agent nutzt Datenquellen, APIs, Ressourcen und Werkzeuge. Beispiel: Ein Sales-Agent liest CRM-Daten, ein Support-Agent sucht Tickets, ein Research-Agent ruft Dokumente ab.
A2A ist agent-to-agent. Ein Agent kann einen anderen Agenten finden, eine Aufgabe delegieren, Status austauschen oder Ergebnisse entgegennehmen. Beispiel: Ein Sales-Agent bittet einen Research-Agenten um Firmenanalyse. Danach fragt er einen Compliance-Agenten, ob bestimmte Outreach-Inhalte erlaubt sind.
Der wichtige Punkt:
Erst zusammen entsteht eine brauchbare Enterprise-Agentenarchitektur.
MCP macht Agenten handlungsfähig. A2A macht Agenten kooperationsfähig. Wofür Unternehmen A2A realistisch brauchen A2A wird nicht gebraucht, wenn ein Team nur einen kleinen Chatbot baut. Spannend wird es, sobald mehrere spezialisierte Agenten beteiligt sind.
Typische Szenarien:
In allen Fällen geht es nicht darum, möglichst viele Agenten zu bauen. Es geht darum, klare Verantwortungen zu schneiden.
Sales: Research-Agent, CRM-Agent, Outreach-Agent und Review-Agent arbeiten zusammen Support: Intake-Agent, Wissens-Agent, Ticket-Agent und Eskalations-Agent koordinieren Fälle Finance: Rechnungs-Agent, Vertrags-Agent und Freigabe-Agent prüfen Abweichungen Legal Operations: Mandatsaufnahme, Dokumentenanalyse und Fristenprüfung laufen verteilt Software Teams: Planungs-Agent, Code-Agent, Test-Agent und Review-Agent bilden eine Umsetzungskette Konzernumfeld: interne Agenten müssen mit Partner- oder Anbieter-Agenten kommunizieren Discovery und Agent Cards: Wer kann was? Ein Kernproblem bei Multi-Agent -Systemen ist Discovery. Wenn ein Agent eine Aufgabe nicht selbst erledigen soll, muss er wissen, welcher andere Agent passend ist.
A2A arbeitet mit Konzepten wie Agent Cards, Skills und Aufgabenkommunikation. Für Unternehmen ist daran besonders relevant, dass Agenten ihre Fähigkeiten beschreiben können, ohne interne Implementierungsdetails offenzulegen.
Das ist wichtig, weil Enterprise-Agenten nicht ihre ganze interne Logik, ihren Tool-Zugriff oder ihre proprietären Prompts teilen sollten. Sie sollten beschreiben:
Gute Agentenkommunikation ist nicht "alles miteinander verbinden". Gute Agentenkommunikation ist kontrollierte Delegation.
welche Aufgaben sie annehmen welche Eingaben sie brauchen welche Ausgaben sie liefern welche Authentifizierung oder Rollen nötig sind ob sie streamen, länger laufen oder Freigaben brauchen welche Grenzen sie haben Die A2A-Entscheidungsmatrix Ein Unternehmen sollte A2A erst dann einführen, wenn mindestens eine der folgenden Bedingungen echt ist:
Wenn diese Bedingungen nicht gelten, ist A2A oft noch Overhead. Dann reicht zuerst ein sauberer einzelner Agent mit MCP, API-Zugriff, Evals und Freigaben.
Agenten kommen aus mehreren Frameworks oder Anbieterplattformen. Ein Agent muss Aufgaben an entfernte Agenten delegieren. Partner-, Konzern- oder Abteilungsgrenzen spielen eine Rolle. Ergebnisse laufen länger und brauchen Status, Streaming oder Webhooks. Agentenfähigkeiten sollen auffindbar sein, ohne interne Prompts oder Tools offenzulegen. Governance verlangt ein Audit-Log für Delegation, nicht nur für Tool Calls. Die Gefahr: Multi-Agent-Chaos statt Produktivität Mehr Agenten bedeuten nicht automatisch bessere Arbeit. Ohne Architektur wird ein Multi-Agent-System schnell langsam, teuer und schwer nachvollziehbar.
Typische Fehler:
A2A kann Kommunikation standardisieren. Es ersetzt aber keine Prozesslogik. Ein Unternehmen braucht trotzdem Routing-Regeln, Abbruchbedingungen, Eskalationslogik, Kostenlimits und Trace-Auswertung.
Agenten delegieren Aufgaben im Kreis niemand besitzt das Endergebnis verschiedene Agenten nutzen widersprüchliche Daten Tool-Rechte werden indirekt weitergereicht Fehler verschwinden in Zwischenantworten Kosten steigen, weil jeder Agent erneut Kontext aufbaut Menschen sehen nur das Endergebnis, aber nicht die Entscheidungskette A2A mit Google ADK und Enterprise-Betrieb Google ADK zeigt, wie A2A praktisch in Multi-Agent-Systeme eingebettet werden kann. Die Dokumentation beschreibt, wie ADK-Agenten A2A nutzen können, um lokale und entfernte Agenten einzubinden. Google Cloud positioniert A2A ausserdem im Kontext von Build, Deploy, Evaluate und Marketplace.
Das zeigt die Entwicklung: Agenten werden nicht nur lokal gebaut. Sie werden deployed, beobachtet, bewertet und über Plattformgrenzen hinweg nutzbar gemacht.
Für Enterprise-Teams ergeben sich daraus klare Betriebsfragen:
Wer diese Fragen ignoriert, baut ein verteiltes System ohne SRE-Denken. Das ist riskant, auch wenn es nach KI klingt.
Wo laufen die Agenten? Welche Agenten dürfen miteinander sprechen? Wer autorisiert Delegation? Welche Daten werden übergeben? Welche Ergebnisse werden gespeichert? Welche Evals prüfen Agent-zu-Agent-Kommunikation? Wie werden Latenz, Kosten und Fehler pro Agent sichtbar? A2A-Governance: Rechte dürfen nicht durchgereicht werden Eine zentrale Sicherheitsfrage lautet: Darf ein Agent Rechte weiterreichen?
Beispiel: Ein Nutzer darf CRM-Daten lesen. Agent A bekommt diese Daten. Agent A bittet Agent B um Analyse. Darf Agent B dieselben Daten sehen? Darf Agent B ein weiteres Tool nutzen? Darf Agent B ein Ergebnis an einen dritten Agenten weitergeben?
Ohne klares Modell entstehen versteckte Datenflüsse.
Ein robustes A2A-Setup sollte festlegen:
In guter Architektur wird A2A-Kommunikation wie API-Kommunikation behandelt: authentifiziert, begrenzt, beobachtet und testbar.
welche Daten ein Agent an andere Agenten weitergeben darf welche Rollen bei Delegation erhalten bleiben welche Tools nicht transitiv genutzt werden dürfen welche Ergebnisse menschliche Freigabe brauchen welche Agenten nur interne, kundenfähige oder externe Daten verarbeiten dürfen wie jede Delegation im Audit-Log erscheint Wann A2A noch zu früh ist A2A ist nicht der erste Schritt für jedes Unternehmen.
Noch zu früh ist A2A, wenn:
In diesem Zustand ist ein Multi-Agent-Protokoll eher Beschleuniger für Unordnung. Der bessere Pfad ist: erst einen wichtigen Agenten sauber bauen, dann Tools kontrollieren, dann evaluieren, dann weitere Agenten modular anbinden.
es noch keine stabilen Einzel-Agenten gibt die Workflows fachlich unklar sind keine Tool-Governance existiert MCP- oder API-Zugriffe noch ungeprüft sind es keine Evals für Einzelagenten gibt niemand die Agentenlandschaft betreibt Der SYSTEMS-Blick auf A2A A2A ist ein starkes Signal für die Richtung des Marktes: AI-Systeme werden nicht nur bessere Chatfenster, sondern verteilte Arbeitsnetzwerke. Genau deshalb müssen Unternehmen jetzt lernen, Agenten wie Infrastruktur zu betrachten.
Die zentrale Architekturfrage lautet nicht: "Welches Protokoll gewinnt?" Die bessere Frage lautet: "Wie schneiden wir Aufgaben, Rechte, Daten und Verantwortung so, dass Agenten zusammenarbeiten können, ohne Kontrolle zu verlieren?"
SYSTEMS baut solche Zielarchitekturen pragmatisch: erst Workflow und Rollen, dann MCP für Tool-Zugriff, dann A2A für Agentenkommunikation, dann Evals, Observability und Rollout.
Wer A2A so betrachtet, baut keine Agenten-Spielerei. Er baut eine Grundlage für echte, kontrollierte AI-Arbeit im Unternehmen.
