MCP vs A2A vs UCP vs AP2 vs A2UI: Der Agenten-Protokoll-Stack erklärt

KI-Agenten-Protokolle vermehren sich rasant: MCP, A2A, UCP, AP2, A2UI und angrenzende Standards tauchen zunehmend in denselben Architekturdiagrammen auf. Sie werden oft als konkurrierende Protokolle beschrieben. In der Praxis lösen die meisten von ihnen jedoch unterschiedliche Interoperabilitätsprobleme an verschiedenen Systemgrenzen. Die sinnvolle Frage lautet nicht: „Welches Protokoll gewinnt?“, sondern: „Welche Beziehung im System muss standardisiert werden?“

Der grundlegende Fehler: Protokolle vergleichen, die an unterschiedlichen Schnittstellen ansetzen

Ein Protokoll ist nützlich, weil zwei unabhängig implementierte Systeme einen stabilen Vertrag benötigen. Der Vertrag ergibt nur dann Sinn, wenn die Schnittstelle klar definiert ist. Ein Agent, der mit einer Datenbank kommuniziert, steht vor einem anderen Interoperabilitätsproblem als ein Agent, der Arbeit an einen anderen delegiert, ein Kunde, der einen Kauf autorisiert, oder ein entfernter Agent, der eine native Anwendung auffordert, ein Formular darzustellen.

Googles Entwicklerleitfaden von 2026 stellt MCP, A2A, UCP, AP2, A2UI und verwandte UI-Protokolle ausdrücklich als Stack komplementärer Standards dar. Derselbe Beispiel-Workflow kann mehrere davon gemeinsam nutzen: Tools für den Bestand, Remote-Agenten für Lieferanten, Commerce für Bestellungen, Zahlungsautorisierung für Ausgaben und UI-Protokolle für Interaktionen.

Der Protocol Responsibility Stack

1. MCP: Den Agenten mit Funktionen verbinden

Das Model Context Protocol ist ein offener Standard zur Anbindung von KI-Anwendungen an externe Systeme, in denen sich Tools, Daten und wiederverwendbare Ressourcen befinden. Ein Server stellt Fähigkeiten bereit; ein MCP-Host verbindet sich mit diesem Server und macht diese Fähigkeiten für das Modell oder die Anwendung verfügbar.

Die aktuelle TypeScript-v2-Dokumentation von MCP beschreibt das Protokoll genau in diesen Begriffen: Server stellen Tools, Ressourcen und Prompts bereit, während Hosts wie Entwicklungsumgebungen oder individuelle Anwendungen sich mit ihnen verbinden. Dies macht MCP in erster Linie zu einem Protokoll für die Integration von Fähigkeiten.

MCP verwenden, wenn

• Eine KI-Anwendung standardisierten Zugriff auf Tools oder APIs benötigt.
• Sie möchten, dass ein einziger Capability-Server mit mehreren kompatiblen KI-Hosts funktioniert.
• Sie strukturierten Zugriff auf Daten oder Ressourcen benötigen, ohne jede Integration fest in jedem Agenten zu verdrahten.
• Das externe System ein Anbieter von Fähigkeiten ist und kein autonomer Peer-Agent.

2. A2A: Unabhängige Agenten verbinden

Agent2Agent (A2A) ist für die Kommunikation zwischen unabhängigen, potenziell opaken Agentensystemen konzipiert. Die aktuelle v1.0-Spezifikation konzentriert sich auf die Erkennung von Fähigkeiten (Capability Discovery), Messaging, Aufgaben, Artefakte, multimodale Inhalte und langanhaltende Zusammenarbeit, ohne dass ein Agent seine internen Tools, seinen Speicher oder seine Implementierung gegenüber einem anderen offenlegen muss.

Diese Opazität ist die entscheidende Grenze. Der aufrufende Agent muss nicht wissen, ob der Remote-Agent intern MCP, benutzerdefinierte Tools, einen proprietären Planer, einen anderen Modellanbieter oder menschliche Eskalation nutzt. Er benötigt lediglich einen Vertrag zur Erkennung von Fähigkeiten und zur Delegierung von Aufgaben.

A2A v1.0 standardisiert zudem die Versionsaushandlung und unterstützt mehrere Bindings rund um ein gemeinsames Datenmodell. Der veröffentlichte Agent-Card-Mechanismus bietet Clients einen standardisierten Discovery-Punkt für die Fähigkeiten, unterstützten Protokolle, Authentifizierungsanforderungen und Skills eines Agenten.

Verwenden Sie A2A, wenn

• Ein autonomer Agent Arbeit an einen anderen autonomen Agenten delegieren muss.
• Das Remote-System hinter einem Fähigkeitsvertrag opak bleiben soll.
• Aufgaben langlebig oder asynchron sein können oder Human-in-the-Loop-Interaktionen erfordern.
• Agenten mit unterschiedlichen Frameworks, Sprachen, Anbietern oder organisatorischen Zuständigkeiten entwickelt wurden.

MCP vs. A2A: Vertikale Integration vs. horizontale Kollaboration

Das A2A-Projekt selbst beschreibt die Unterscheidung inzwischen als horizontal gegenüber vertikal: MCP verbindet Agenten mit internen Tools und Datenbanken, während A2A die Peer-to-Peer-Kollaboration zwischen verschiedenen Agentensystemen ermöglicht.

3. UCP: Standardisierung des agentenbasierten Handels

Das Universal Commerce Protocol ist kein generisches Agentenprotokoll. Es standardisiert Commerce Journeys zwischen Verbraucheroberflächen, Händlern und Zahlungsdienstleistern. Googles Implementierung unterstützt über versionierte Profile und APIs bereits Funktionen wie Warenkorberstellung, Checkout, Fulfillment und den Bestelllebenszyklus.

Ein Händler kann unter /.well-known/ucp ein UCP-Profil veröffentlichen, das Services, Protokollversionen und Fähigkeiten beschreibt. Dieses Discovery-Muster ist wichtig, da eine agentenbasierte Oberfläche nicht für jeden Händler einen maßgeschneiderten Checkout-Vertrag benötigt.

UCP ist zudem bewusst modular und kombinierbar aufgebaut. Laut Googles technischer Übersicht kann es über APIs, A2A und MCP integriert werden und ist mit AP2 für die agentenbasierte Zahlungsautorisierung kompatibel.

Verwenden Sie UCP, wenn

• Der Workflow Händlerprodukte, Warenkörbe, Checkout, Fulfillment oder den Bestelllebenszyklus umfasst.
• Sie eine Händleroberfläche entwickeln, die mit agentenbasierten Einkaufserlebnissen kompatibel sein soll.
• Die Integration handelsspezifische Semantik statt generischer Tool-Aufrufe benötigt.
• Sie einen interoperablen Handelsvertrag wünschen, der mit MCP, A2A und Zahlungsprotokollen koexistieren kann.

4. AP2: Nachweisen, dass der Agent ausgabeberechtigt war

Der agentenbasierte Handel wirft ein Problem auf, das herkömmliche Checkout-Abläufe nicht auf dieselbe Weise lösen mussten: Ein Agent kann Transaktionen durchführen, ohne dass der Mensch in Echtzeit auf die finale Schaltfläche klickt. Das Agent Payments Protocol (AP2) adressiert Autorisierung, Authentizität und Nachvollziehbarkeit für agentengesteuerte Zahlungen.

Googles Protokoll-Leitfaden für 2026 beschreibt AP2 anhand von typisierten Mandaten, die Benutzerabsichten, Ausgabenlimits und die spezifisch autorisierte Transaktion erfassen. AP2 kann als Erweiterung neben UCP fungieren: UCP beschreibt die Handelstransaktion, während AP2 den Nachweis liefert, dass der Agent zur Ausführung der Zahlung autorisiert war.

Diese Unterscheidung ist wichtig. Ein Checkout-Protokoll kann einem Händler mitteilen, was gekauft werden soll. Es beweist für sich genommen jedoch nicht, wer den Agenten zu welchen Beträgen, für welchen Händler, für wie lange autorisiert hat oder ob der finale Warenkorb innerhalb dieser Berechtigung lag.

UCP vs. AP2: Transaktionssemantik vs. Autorisierung

5. A2UI: Lassen Sie Agenten Schnittstellen beschreiben, ohne Ihr Frontend zu besitzen

Agent-to-User Interface (A2UI) adressiert eine weitere Grenze: wie ein entfernter oder lokaler Agent eine reichhaltige interaktive Schnittstelle an eine Host-Anwendung übermittelt. Anstatt beliebiges HTML, CSS und JavaScript zu senden, verwendet A2UI deklarative Daten, die der Host über seinen eigenen vertrauenswürdigen Komponentenkatalog rendert.

Dadurch bleiben das Designsystem und das Sicherheitsmodell der Host-Anwendung erhalten, während ein Agent dennoch dynamische Benutzeroberflächen anfordern kann. A2UI v0.9 betont insbesondere framework-agnostische UI-Absichten und Streaming-Updates über Web-, Mobil- und andere Clients hinweg.

Googles spätere Arbeit an A2UI + MCP Apps zeigt zudem, dass sich diese UI-Modelle nicht zwangsläufig gegenseitig ausschließen. Deklarative native Benutzeroberflächen und reichhaltigere eingebettete Anwendungserlebnisse können je nach Aufgabe koexistieren.

Verwenden Sie A2UI, wenn

• Ein entfernter Agent Formulare, Karten, Steuerelemente oder andere interaktive UI anfordern muss.
• Der Host seine nativen Komponenten, sein Styling und seine Sicherheitsgrenzen beibehalten soll.
• Sie nicht möchten, dass entfernte Agenten beliebigen ausführbaren Frontend-Code ausliefern.
• Dieselbe vom Agenten definierte UI-Absicht über verschiedene Client-Frameworks hinweg funktionieren soll.

Der Protokollauswahl-Test

Beginnen Sie nicht mit dem Akronym. Beginnen Sie mit der Beziehung, die Interoperabilität erfordert.

Ein realistischer Multi-Protokoll-Workflow

Warum ein universelles Agentenprotokoll wahrscheinlich nicht alle ersetzen wird

Ein universelles Protokoll klingt einfacher, bis es die Semantik jeder einzelnen Domäne abbilden muss. Tool-Discovery, langlebige Agenten-Kollaboration, Checkout, Zahlungsautorisierung und native Benutzeroberflächen haben jeweils unterschiedliche Anforderungen an Lebenszyklus, Sicherheit und Korrektheit.

Das Web selbst hat sich durch geschichtete Protokolle entwickelt und nicht durch ein einziges Nachrichtenformat für jedes Problem. Der entstehende agentische Stack scheint sich in dieselbe Richtung zu bewegen: gemeinsame horizontale Primitive, spezialisierte Domänenverträge sowie explizite Discovery und Versionierung.

Die architektonische Herausforderung verschiebt sich daher von „Welches Protokoll gewinnt?“ zu der Frage, wie sauber sich Protokolle zusammenstellen lassen, ohne Identitäts-, Autorisierungs-, Zustands- und Audit-Semantiken zu duplizieren.

Protokollkomposition schafft neue Fehlerarten

Die Protokollwahl ersetzt keine Anwendungsarchitektur

Offene Standards verringern die Integrationskopplung, entscheiden jedoch nicht über Ihr Domänenmodell, Autorisierungsrichtlinien, die Source of Truth, Wiederholungsstrategien oder Akzeptanzkriterien. Ein MCP-Tool kann immer noch die falsche Funktion bereitstellen. Ein A2A-Agent kann immer noch ein fehlerhaftes Artefakt zurückgeben. Ein UCP-Checkout kann immer noch veraltete Händlerdaten enthalten. Ein AP2-Mandat kann durch die Anwendungslogik immer noch falsch angewendet werden.

Betrachten Sie Protokolle als Verträge zwischen Komponenten, die sich unabhängig voneinander entwickeln. Behalten Sie die Domänenwahrheit und maßgebliche Richtlinien in der Anwendungsschicht, die dafür zuständig ist, und nutzen Sie Protokolle, um die Schnittstellen interoperabel zu machen.

Was würde diese Einschätzung ändern?

Der Stack ändert sich, wenn Protokolle konvergieren, ein Standard einen anderen formell absorbiert oder Anbieter eine gemeinsame Identitäts- und Autorisierungsschicht über mehrere Grenzen hinweg standardisieren. UCP demonstriert bereits Komposition, indem es APIs, A2A und MCP unterstützt und in AP2 integriert wird, anstatt diese zu ersetzen.

Die Antwort ändert sich auch je nach Anwendungsumfang. Ein kleiner interner Agent benötigt möglicherweise nur MCP. Ein unternehmensübergreifender Workflow erfordert möglicherweise A2A. Ein Händler benötigt möglicherweise UCP ohne A2UI. Ein delegierter Einkaufsagent benötigt möglicherweise alle. Verwenden Sie das kleinste Protokollset, das die tatsächlichen Grenzen abbildet, ohne die Domänensemantik zu verflachen.

Einschränkungen

Die hier behandelten Protokolle befinden sich auf unterschiedlichen Reifegraden und haben unterschiedliche Governance-Modelle. A2A hat eine stabile v1.0-Spezifikation erreicht, während sich andere Standards weiterhin rasant weiterentwickeln. Auch die Akzeptanz im Ökosystem ist bei Anbietern und Frameworks uneinheitlich.

Dieser Artikel konzentriert sich auf Architekturverantwortung statt auf Implementierungsvollständigkeit. Spezifische Authentifizierungsmethoden, Transport-Bindings, Schemata und Erweiterungsmechanismen müssen den aktuellen Spezifikationen des jeweiligen Protokolls entnommen werden.

Fazit

MCP, A2A, UCP, AP2 und A2UI ergeben mehr Sinn, wenn man sie als Protokolle für unterschiedliche Beziehungen betrachtet und nicht als fünf konkurrierende Versuche, „Agenten“ zu standardisieren.

MCP legt Fähigkeiten offen. A2A koordiniert unabhängige Agenten. UCP verleiht dem E-Commerce einen eigenen maschinenlesbaren Vertrag. AP2 fügt eine überprüfbare Zahlungsautorisierung hinzu. A2UI bietet Agenten einen sicheren, deklarativen Weg in Benutzeroberflächen. Das aufstrebende agentische Web ersetzt Protokolle daher nicht durch KI – es schafft einen neuen Protokoll-Stack rund um KI.

FAQ

Glossar

Primärquellen und weiterführende Literatur