AI Frameworks · 9 Min.
Agent2Agent Protocol: Warum A2A fuer Enterprise-Agenten wichtig wird
A2A adressiert ein Problem, das in Enterprise-AI jetzt sichtbar wird: Agenten muessen nicht nur Tools nutzen, sondern miteinander arbeiten koennen.
SYSTEMS Grafik zu Agent2Agent Protocol: Data -> Agent -> Outcome. Fokus: Warum A2A fuer 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. Fuer 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 gehoert 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 ueber Systemgrenzen hinweg.
Wenn jeder Bereich seinen eigenen Agenten baut, entsteht schnell ein neues Silo. Genau hier wird das Agent2Agent Protocol interessant. A2A soll Agenten ermoeglichen, Aufgaben, Kontext und Ergebnisse standardisiert auszutauschen, auch wenn sie auf unterschiedlichen Plattformen laufen.
Fuer 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 pruefen:
Der Punkt ist nicht, jeden neuen Protokollstand sofort einzubauen. Der Punkt ist, eine Agentenarchitektur so zu schneiden, dass Versionierung und Governance nicht spaeter alles blockieren.
Welche A2A-Versionen muessen parallel unterstuetzt werden? Wie werden Agent Cards verifiziert? Welche Agenten laufen mandantenfaehig 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, loesen 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 handlungsfaehig. A2A macht Agenten kooperationsfaehig. Wofuer 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 Faellen geht es nicht darum, moeglichst 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 Faelle Finance: Rechnungs-Agent, Vertrags-Agent und Freigabe-Agent pruefen Abweichungen Legal Operations: Mandatsaufnahme, Dokumentenanalyse und Fristenpruefung laufen verteilt Software Teams: Planungs-Agent, Code-Agent, Test-Agent und Review-Agent bilden eine Umsetzungskette Konzernumfeld: interne Agenten muessen 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. Fuer Unternehmen ist daran besonders relevant, dass Agenten ihre Faehigkeiten beschreiben koennen, ohne interne Implementierungsdetails offenzulegen.
Das ist wichtig, weil Enterprise-Agenten nicht ihre ganze interne Logik, ihren Tool-Zugriff oder ihre proprietaeren 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 noetig sind ob sie streamen, laenger laufen oder Freigaben brauchen welche Grenzen sie haben Die A2A-Entscheidungsmatrix Ein Unternehmen sollte A2A erst dann einfuehren, 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 laenger und brauchen Status, Streaming oder Webhooks. Agentenfaehigkeiten sollen auffindbar sein, ohne interne Prompts oder Tools offenzulegen. Governance verlangt ein Audit-Log fuer Delegation, nicht nur fuer Tool Calls. Die Gefahr: Multi-Agent-Chaos statt Produktivitaet 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 widerspruechliche 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 koennen, 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 ueber Plattformgrenzen hinweg nutzbar gemacht.
Fuer 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 duerfen miteinander sprechen? Wer autorisiert Delegation? Welche Daten werden uebergeben? Welche Ergebnisse werden gespeichert? Welche Evals pruefen Agent-zu-Agent-Kommunikation? Wie werden Latenz, Kosten und Fehler pro Agent sichtbar? A2A-Governance: Rechte duerfen 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 Datenfluesse.
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 duerfen welche Ergebnisse menschliche Freigabe brauchen welche Agenten nur interne, kundenfaehige oder externe Daten verarbeiten duerfen wie jede Delegation im Audit-Log erscheint Wann A2A noch zu frueh ist A2A ist nicht der erste Schritt fuer jedes Unternehmen.
Noch zu frueh ist A2A, wenn:
In diesem Zustand ist ein Multi-Agent-Protokoll eher Beschleuniger fuer 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 ungeprueft sind es keine Evals fuer Einzelagenten gibt niemand die Agentenlandschaft betreibt Der SYSTEMS-Blick auf A2A A2A ist ein starkes Signal fuer die Richtung des Marktes: AI-Systeme werden nicht nur bessere Chatfenster, sondern verteilte Arbeitsnetzwerke. Genau deshalb muessen 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 koennen, ohne Kontrolle zu verlieren?"
SYSTEMS baut solche Zielarchitekturen pragmatisch: erst Workflow und Rollen, dann MCP fuer Tool-Zugriff, dann A2A fuer Agentenkommunikation, dann Evals, Observability und Rollout.
Wer A2A so betrachtet, baut keine Agenten-Spielerei. Er baut eine Grundlage fuer echte, kontrollierte AI-Arbeit im Unternehmen.
