Der Agentic Commerce Protocol War ist eine Ablenkung

14 Minuten Lesezeit

Teams fragen immer wieder, welches Agentic Commerce Protokoll gewinnen wird. Es ist die falsche Architekturfrage.

ACP, UCP, AP2, A2A und MCP überschneiden sich an den Rändern, aber sie beschreiben keine austauschbare Sache. Eine hilft bei der Verbindung von Produkterkennung und Kaufreisen. Eine andere standardisiert einen breiteren Commerce-Lebenszyklus. Eine andere fügt Zahlungsabsicht und Mandatssemantik hinzu. A2A koordiniert unabhängige Agenten. MCP setzt Tools und Kontext einer KI-Anwendung aus.

Die Wahl eines solchen als internes Datenmodell würde den Katalog, die Aufträge und Richtlinien eines Händlers an eine sich schnell verändernde externe Schnittstelle koppeln. Auf einen Gewinner zu warten ist schlimmer. Die Verteilung ist bereits fragmentiert über Einkaufsassistenten, Entwicklerplattformen und Commerce-Ökosysteme.

Die dauerhafte Wahl ist weniger aufregend: Bauen Sie einen kanonischen Handels- und Vertrauenskern auf und behandeln Sie dann Protokolle als versionierte Adapter.

Beginnen Sie mit der Trennung von Protokollbereichen

Die Protokollnamen erscheinen zusammen in Ankündigungen, so dass man leicht davon ausgehen kann, dass sie Rivalen sind. Ihre offiziellen Beschreibungen zeigen einen geschichteten Stapel.

ACP verbindet Händler mit ChatGPT Commerce

OpenAI beschreibt das Agentic Commerce Protocol als Verbindungsschicht zwischen Händlern und Benutzern durch Produkterkennung. Händler können Produktfeeds und Werbeaktionen teilen, während aktuelle Konversionspfade den Käufer zum eigenen Checkout des Händlers zurückbringen können. OpenAIs März 2026 Update Tiefere native Erlebnisse bleiben auch über ChatGPT-Apps verfügbar.

ACP ist wichtig, weil ChatGPT eine Vertriebsfläche ist und nicht zum kanonischen Produkt oder Bestellmodell des Händlers werden sollte.

UCP beschreibt eine Commerce-Reise über Oberflächen

Google und Shopify beschreiben das Universal Commerce Protocol als einen offenen Standard für Interaktionen zwischen Verbraucheroberflächen, Unternehmen und Zahlungsanbietern. Sein Design umfasst die Erkennung von Fähigkeiten und Erweiterungspunkte mit Bindungen über APIs, A2A und MCP. Technische UCP-Übersicht von Google Shopify sagt, dass sein 2026-Tooling es Entwicklern ermöglicht, ein Agentenprofil zu registrieren und öffentliche MCP-Endpunkte zu verwenden, ohne UCP-Zugriff zu beantragen. Entwickler-Ankündigung von Shopify ist ein nützlicher Beweis dafür, dass sich der Protokollzugriff von Partnerschaftsprogrammen hin zu einer gewöhnlichen Entwicklerinfrastruktur bewegt.

UCP ist breiter als eine einzelne Assistentenoberfläche. Es muss immer noch auf die tatsächlichen Systeme, Richtlinien und Datenqualität jedes Händlers abgebildet werden.

AP2 adressiert Zahlungsabsicht und Rechenschaftspflicht

Google führte das Agent Payments Protocol als zahlungsunabhängiges Framework ein, das A2A und MCP erweitern kann. AP2 befasst sich explizit mit Autorisierung, Authentizität und Rechenschaftspflicht, einschließlich des Nachweises, dass ein Benutzer einem Agenten die Befugnis für einen Kauf gegeben hat. Google Cloud AP2-Ankündigung beschreibt Absichts-, Zahlungs- und Prüfungsbedenken, die ein allgemeiner Tool Call nicht abdecken kann.

Es wäre ungenau zu sagen, dass jedes Protokoll nur Nachrichten transportiert und keine Autorität ausdrückt. AP2 hat Mandatskonzepte. Die technische Frage ist, wie sich die AP2-Zahlungsbehörde mit der Unternehmensbehörde außerhalb der Zahlung verhält: Beschaffungspolitik, Lieferantenberechtigung, Datennutzung, Delegation, Rückerstattungen, Erfüllungsänderungen und Serviceaktionen.

A2A koordiniert unabhängige Agenten

Die offizielle A2A-Spezifikation konzentriert sich auf Entdeckung, Fähigkeitskommunikation, Aufgaben, Nachrichten und Artefakte über unabhängige Agentensysteme hinweg. Die Spezifikation A2A ist ein Koordinationsprotokoll, kein Händlerbuch oder Produktinformationsmodell.

MCP zeigt Tools und Kontext

MCP verwendet eine Client-Server-Architektur, in der sich KI-Anwendungen mit Servern verbinden, die Tools, Ressourcen und Eingabeaufforderungen freigeben. Der offizielle MCP Architektur Guide erklärt diese Grenze.

MCP ist eine gute Bindung für Aktionen wie catalog.search oder cart.createDas Werkzeugschema an sich beweist nicht, dass ein bestimmter Agent ein bestimmtes Budget für einen bestimmten Käufer ausgeben kann.

Modellieren Sie den Stack, nicht die Logowand

Eine Händlerarchitektur kann jedes Anliegen einer stabilen Schicht zuordnen:

Dies ist kein Argument dafür, jedes Protokoll hinzuzufügen, sondern ein Argument dafür, es abzulehnen, ein Protokoll dazu zu zwingen, Bedenken außerhalb seines Anwendungsbereichs zu äußern.

Verwenden Sie kanonische Aktionen innerhalb der Händlergrenze

Angenommen, drei Kanäle wollen einen Warenkorb erstellen. Einer sendet eine UCP-Checkout-Anfrage, einer ruft ein MCP-Tool auf und einer verwendet den vorhandenen REST-Endpunkt eines Händlers. Der Händler sollte alle drei in den gleichen internen Befehl abbilden:

type CreateCartCommand = {
  transactionId: string
  merchantId: string
  buyerContext: {
    subject?: string
    market: string
    currency: string
  }
  lines: Array<{
    variantId: string
    quantity: number
  }>
  promotionCodes: string[]
  deliveryCountry: string
  idempotencyKey: string
  source: {
    protocol: "ucp" | "acp" | "mcp" | "merchant_api"
    version: string
    requestDigest: string
  }
}

Der Warenkorbdienst muss nicht wissen, wie ein MCP-Tool beschrieben wurde oder wie ein UCP-Fähigkeitsdokument transportiert wurde.

Der Adapter hat strenge Verantwortlichkeiten:

1. Validieren Sie das externe Schema und die Version.
2. Authentifizierung des Anrufers unter dieser Bindung.
3. Übersetzen Sie externe Identifikatoren in kanonische Händler-IDs.
4. Protokollspezifische Evidenz und Erweiterungsfelder bewahren.
5. Produzieren Sie einen kanonischen Befehl und verdauen Sie.
6. Übersetzen Sie das Ergebnis und die Fehler zurück, ohne den Erfolg zu erfinden.

Ein UCP-Steckverbinder sollte kein Rabattlimit haben, während der REST-Steckverbinder ein anderes hat.

Capability-Verhandlung braucht Runtime-Verifizierung

Protokolle ermöglichen es Händlern zunehmend, Fähigkeiten zu bewerben, was nützlich ist, aber ein Kompetenzanspruch kann nach einem Einsatz, einer Marktänderung oder einem Verbindungsausfall veraltet sein.

Führen Sie ein internes Fähigkeitsregister:

{
  "capability": "checkout.create",
  "merchant": "merchant:example",
  "markets": ["DE", "FR"],
  "constraints": {
    "guest_checkout": true,
    "currencies": ["EUR"],
    "requires_customer_presence": false
  },
  "bindings": [
    { "protocol": "ucp", "version": "negotiated-version", "status": "active" },
    { "protocol": "mcp", "version": "negotiated-version", "status": "active" }
  ],
  "verified_at": "2026-08-11T08:00:00Z",
  "expires_at": "2026-08-11T09:00:00Z"
}

Testen Sie dann die Fähigkeit durch ihre Bindung. Validieren Sie Schemakonformität, Authentifizierung, erwartetes Verweigerungsverhalten, Idempotenz und eine sichere synthetische Transaktion. Discovery sollte nur Fähigkeiten einstufen, deren Beweise aktuell genug für den Anwendungsfall sind.

Ein Manifest ist eine Bereitstellungsbeschreibung, nicht die Erlaubnis für jeden Agenten, alles aufzurufen, was er auflistet.

Autorität muss Protokollübersetzung überleben

Ein Agent kann über A2A ankommen, ein Tool über MCP auswählen, eine Kasse über UCP erstellen und ein AP2-Zahlungsmandat anhängen. Die Transaktion überschreitet vier Protokollgrenzen. Die Autorität kann zwischen ihnen verschwinden, wenn jeder Adapter nur die Felder extrahiert, die für seinen sofortigen API-Aufruf benötigt werden.

Erstellen Sie einen protokollneutralen Transaktionsumschlag, der bindet:

• rechenschaftspflichtiger Vertreter und Organisation;
• Verweise auf Befugnisse oder Mandate;
• Zweck, Maßnahme und Ressourcen;
• Händler, Käufer und Gegenpartei;
• Betrag, Währung und Geschäftsprofil;
• Request Digest, Audience, Time und Nonce;
• Protokollquelle und Transformationskette.

{
  "transaction_id": "tx:purchase:0194",
  "agent_id": "agent:buyer:procurement-7",
  "organisation_id": "org:buyer",
  "action": "checkout.create",
  "resource": "merchant:acme/cart:cart-882",
  "purpose": "office-supplies-replenishment",
  "amount": { "value": "742.00", "currency": "EUR" },
  "authority": {
    "enterprise_mandate": "mandate:procurement:q3-17",
    "payment_mandate": "ap2:payment-mandate:991"
  },
  "source": { "protocol": "ucp", "version": "negotiated-version" },
  "request_digest": "sha256:...",
  "issued_at": "2026-08-11T09:14:02Z",
  "nonce": "01K2..."
}

Nehmen Sie nicht an, dass zwei Mandatsformate eine identische Semantik haben, weil sie ein Wort teilen. Schreiben Sie eine explizite Zuordnung. Wenn ein Format keine erforderliche Lieferantenbeschränkung, Genehmigungsbedingung oder Delegationsgrenze ausdrücken kann, bewahren Sie das ursprünglich signierte Objekt auf und erzwingen Sie die fehlende Bedingung in der lokalen Richtlinie.

Versionierung ist, wo Interoperabilität real wird

Protokolldemos zeigen normalerweise übereinstimmende Client- und Serverversionen. Merchant-Systeme leben länger als das.

Für jeden Adapter veröffentlichen:

• unterstützte Protokoll- und Erweiterungsversionen;
• erforderliche und optionale Felder;
• Downgrade-Verhalten;
• kanonische Aktionsmappings;
• Fehler- und Retry-Semantik;
• Unterschrifts- und Vertrauensanforderungen;
• Testvektoren und bekannte nicht unterstützte Merkmale.

Unbekannte obligatorische Erweiterungen ablehnen; unbekannte optionale Felder nur beibehalten, wenn dies die Geschäftsbedeutung nicht verändern kann; den ursprünglichen Anforderungsverdau neben dem kanonischen Befehlsverdau speichern, damit ein Ermittler die Transformation rekonstruieren kann.

Vermeiden Sie Versionsprüfungen, die über Handler verteilt sind:

interface CommerceBindingAdapter<Input, Output> {
  validate(input: unknown): Input
  authenticate(input: Input, transport: TransportContext): Promise<Caller>
  normalize(input: Input, caller: Caller): Promise<CanonicalCommand>
  render(result: CanonicalResult): Output
  conformance(): Promise<ConformanceReport>
}

Dies macht ein Protokoll-Upgrade zu einem Adapterwechsel, nicht zu einer Katalogmigration.

Fehlerfälle zum Testen

Kollision der Kennung. ACP- und UCP-Requests beziehen sich auf dieselbe Variante mit unterschiedlichen Kanal-IDs. Der Resolver muss eine kanonische Variante erreichen, ohne nicht zusammenhängende Datensätze zusammenzuführen.

Semantisches Downgrade. Ein eingehendes Zahlungsmandat enthält eine Einschränkung, die das interne Modell ignoriert.

Fähigkeitsdrift. Die Registry wirbt für die Erstellung von Rückgaben, aber der Händler-Connector unterstützt nur die Rückgabesuche nach einem Upgrade.

Fehlanpassungen wiederholen. MCP wiederholt einen zeitgesteuerten Tool-Aufruf mit einer neuen ID, während der UCP-Adapter den alten Warenkorb-Idempotenzschlüssel verwendet.

Teiltransaktion. Checkout ist erfolgreich, aber die Zahlungsberechtigung verfällt. Warenkorb, Zahlungs- und Bestellzustände trennen und abgleichen sich mit maßgeblichen Anbietern.

Authentifizierungsverwirrung. Eine A2A-Agentenkarte identifiziert einen Agenten, aber die Checkout-Anfrage kommt bei einem nicht verwandten OAuth-Client an.

Politische Fragmentierung. Eine Promotion wird durch einen Adapter erlaubt und durch einen anderen verweigert.

Protokollausfall. Eine Oberfläche ist nicht verfügbar, während die Händler-APIs funktionieren.

Checkliste der Durchführung

• Inventarprotokolle nach Funktion, Kanal und Gegenpartei.
• Definieren Sie kanonische Produkt-, Angebots-, Warenkorb-, Bestell- und Ergebnismodelle.
• Definieren Sie stabile Handelsaktionen unabhängig vom Transport.
• Implementieren Sie jedes Protokoll als versionierten Boundary Adapter.
• Bewahren Sie original signierte Objekte und Protokollanforderung verdaut.
• Kartenbezeichner durch eine kanonische Registrierung.
• Zentralisierung der Geschäftspolitik nach der Normalisierung.
• Halten Sie die Unternehmensbehörde und die Zahlungsbehörde explizit.
• Zurückweisen semantischer Herabstufungen und unbekannter obligatorischer Erweiterungen.
• Teilen Sie Idempotenzidentitäten über Protokollbindungen hinweg.
• Überprüfen Sie die angekündigten Fähigkeiten mit Konformitätstests.
• Abstimmung der Transaktionsergebnisse mit autoritativen Systemen.
• Überwachen Sie adapterspezifische Fehler, ohne Geschäftsmetriken zu fragmentieren.
• Planen Sie Protokollersatz als Adapteroperation.

Position und aktuelle Grenze von Intelliger

Die Ziel-Commerce-Architektur von Intelliger verwendet protokollneutrale Händlerkonnektoren, einen kanonischen Commerce Graph, stabile universelle Commerce-Aktionen, die Überprüfung der Fähigkeiten und einen Resolver. OATI bietet ein separates Vertrauens-Backbone für Agentenidentität, delegierte Autorität, deterministische Einschränkungen, Widerruf und Quittungen.

Die implementierte OATI-Entwicklervorschau bietet Schemata, SDKs, kanonische Signatur, deterministische Auswertung, Suche und Entdeckung, Referenz-HTTP-Middleware, MCP/A2A-Adapter und 73 gemeinsame Konformitätsfälle. v0.1 Profil und bezahlte API-Sandbox existieren, aber die Universal Connector Flotte, Commerce Graph, Merchant Agent Runtime und Commerce Resolver sind keine vollständigen Produktionsdienste.

Der Wettbewerb zwischen den Protokollen wird sich fortsetzen, und einige Standards werden sich stärker durchsetzen als andere. Die Händler müssen die endgültige Rangfolge nicht vorhersagen.

Protokoll-Normalisierung ist nur dann sicher, wenn AI Agent Identität bleibt getrennt von der delegierten Befugnis. Die breitere Agentische Commerce-Plattformarchitektur zeigt, wo diese Adapter relativ zu Händlersystemen, Beweisen und Ergebnissen sitzen.