Agentic-Commerce-Architektur: Eine MCP-Capability-Schicht, vier KI-Kanäle

Kernaussagen

• Vier KI-Zugangskanäle – ein eigenes Portal, OpenAI ACP, Meta Muse und externe A2A-Agenten – können sich eine MCP-Capability-Schicht teilen, statt dieselbe Commerce-Logik viermal getrennt nachzubauen.
• Die Entscheidungsregel passt in eine Zeile: Ein Protokoll-Adapter ist nur nötig, wenn sich das externe Protokoll von MCP unterscheidet. OpenAIs Agentic Commerce Protocol benötigt einen ACP→MCP-Adapter; ein Connector, der bereits MCP spricht, braucht keinen.
• Magento / Adobe Commerce bleibt das maßgebliche führende System – ACP, MCP und A2A bilden Preis-, Bestands-, Steuer- oder Bestelllogik nie nach, sondern rufen sie auf.
• Schreibende Tools werden an der Tool-Grenze nach Auswirkung abgesichert – Lesezugriffe wie catalog.search_products laufen frei, kritische Schreibzugriffe wie order.submit und payment.authorize erfordern menschliche Freigabe und Idempotenz.

Wer seinen Commerce-Katalog mit ChatGPT, mit Meta Muse und mit den Agenten von Partnerunternehmen verbindet, implementiert im naiven Entwurf Preis-, Bestands- und Checkout-Logik viermal – einmal pro Plattform. Jede KI-Oberfläche spricht ein anderes Protokoll: OpenAI hat das Agentic Commerce Protocol (ACP, gemeinsam mit Stripe entwickelt) eingeführt, Agenten sprechen mit Tools über das Model Context Protocol (MCP), und Agenten delegieren untereinander über A2A. Der Reflex lautet, pro Plattform einen eigenen Integrations-Stack zu bauen. Dieser Reflex ist der teure Fehler.

Dieser Artikel skizziert eine anbieterneutrale Architektur für Agentic Commerce: eine unternehmensweite MCP-Capability-Schicht auf der Südseite, viele KI-Zugangskanäle auf der Nordseite. Als durchgängiges Beispiel für das führende Commerce-System dient Magento / Adobe Commerce, das Muster gilt jedoch für jedes ERP, OMS oder jeden Katalog. Das Kernergebnis ist eine einzige Entscheidungsregel – einen Adapter nur dann ergänzen, wenn das Protokoll der externen Plattform in MCP übersetzt werden muss –, die genau zeigt, wo Integrationscode hingehört und, noch nützlicher, wo nicht.

Die Falle: vier Plattformen, vier Neuimplementierungen

Jede KI-Commerce-Oberfläche verlangt dieselben zugrunde liegenden Operationen: Katalog durchsuchen, Bestand prüfen, einen Preis abrufen, einen Warenkorb aufbauen, eine Bestellung absenden. Die naive Architektur bindet jede Oberfläche mit eigener Logik direkt an die Commerce-Plattform an:

• die eigene Website → individuelle Magento-Aufrufe
• OpenAI / ChatGPT → andere Magento-Aufrufe
• Meta Muse → wieder andere Magento-Aufrufe
• Partner-Agenten → noch ein weiterer Satz

Nun muss eine Änderung der Preisregeln, eine neue Steuerjurisdiktion oder eine Korrektur der Bestandsreservierung an vier Stellen umgesetzt und getestet werden. Die Geschäftslogik wurde kopiert, und Kopien driften auseinander. Es ist dieselbe Connector-Wucherung, die Punkt-zu-Punkt-Integration in jeder Größenordnung teuer macht – hier auf KI-Kanäle statt auf SaaS-Endpunkte angewandt.

Die Lösung besteht darin, die vier südseitigen Implementierungen zu einer einzigen zusammenzuführen. Jeder Kanal erreicht dieselbe unternehmensweite Capability-Schicht, die über MCP bereitgestellt wird, auf kanonischen Commerce-Services aufsetzt und letztlich auf Magento als einziger Wahrheitsquelle für Produkte, Preise, Bestand, Warenkörbe, Steuern und Bestellungen. Magento besitzt weiterhin die Commerce-Logik; die KI-Kanäle rufen sie nur auf.

Die Entscheidungsregel: Adapter nur bei Protokoll-Abweichung

Die Kanäle unterscheiden sich in genau einem architektonisch relevanten Punkt: welches Protokoll sie sprechen. Diese eine Tatsache entscheidet, ob ein Kanal einen Übersetzungs-Adapter braucht oder direkt an MCP andocken kann. Die drei Protokolle konkurrieren nicht – sie beantworten unterschiedliche Fragen:

Technologie	Was es ist	Was es beantwortet
HTTP / REST / JSON	Transport, API-Stil, Datenformat	Wie Bytes übertragen werden
ACP	Interoperabilität für KI-Commerce (OpenAI + Stripe)	Wie eine KI-Commerce-Plattform und ein Händler Transaktionen abwickeln
MCP	Interoperabilität zwischen Agent/Anwendung und Tool	Welche Tools ein Agent oder eine Anwendung aufrufen kann
A2A	Interoperabilität zwischen Agenten	Wie ein Agent Arbeit an einen anderen delegiert

ACP und MCP lösen unterschiedliche Probleme, deshalb ist ein ACP-Adapter tatsächlich erforderlich – er übersetzt die Commerce-Semantik von ACP (Checkout-Sessions, Bestellstatus, Feed-Formate) in MCP-Tool-Aufrufe. Auch A2A ist eigenständig: Ein externer Agent delegiert eine Aufgabe über A2A, ein Gateway leitet sie in Ihren Agent Core, und dieser ruft dann MCP auf. Eine Plattform, deren Connector-Modell bereits MCP konsumiert, braucht dagegen überhaupt keinen Adapter – sie erreicht die Capability-Schicht direkt.

Das ist der konträre Teil. Der Instinkt lautet: „Eine neue KI-Plattform bedeutet einen neuen Adapter.“ Die Regel sagt das Gegenteil: Bauen Sie nur dann einen Adapter, wenn das Protokoll der Plattform nicht MCP ist. Die vier Kanäle lösen sich dann in vier Zugriffspfade auf, nicht in vier Integrationen:

• Eigenes Portal → Agent Core → MCP
• OpenAI / ChatGPT → ACP → ACP-Adapter → MCP
• Meta Muse → Muse Connector → MCP (kein Adapter – der Connector spricht MCP)
• Externer Agent → A2A → A2A-Gateway → Agent Core → MCP

Alles läuft bei MCP zusammen. Diese Konvergenz ist der gesamte Entwurf:

Die Architektur in einer Ansicht:

Der MCP Commerce Server ist die wiederverwendbare Grenze

Die Capability-Schicht ist ein MCP-Server, der einen kleinen, stabilen Satz von Commerce-Tools bereitstellt – catalog.search_products, pricing.get_price, inventory.check, cart.create, cart.add_item, order.submit, order.get_status. Jeder Kanal nutzt dieselben Tools. Der Agent Core des eigenen Portals, der ACP-Adapter, der Muse Connector und externe Agenten, die über A2A eintreffen, rufen alle catalog.search_products auf – sie implementieren nicht jeweils eine eigene Produktsuche.

Entscheidend: MCP ist die Capability-Schnittstelle, nicht das Geschäftsdatenmodell. Hinter den Tools liegen kanonische Commerce-Services – ein protokollunabhängiges Modell aus Product, Variant, Price, Inventory, Cart, Order – sowie ein Magento-Adapter, der dieses kanonische Modell auf die APIs von Adobe Commerce abbildet. Ändert sich das Produkt-Feed-Format von OpenAI oder das Checkout-Schema von ACP, ändert sich nur der ACP-Adapter. Ändert sich die API von Magento, ändert sich nur der Magento-Adapter. Die Tools in der Mitte bleiben stabil. Das ist dieselbe strukturelle Disziplin wie bei einem gesteuerten MCP-Modul: typisierte Tools, ein stabiler Vertrag und die Eigenheiten der Hersteller an den Rändern isoliert.

Tools werden nach Auswirkung klassifiziert, und in dieser Klassifizierung liegt die Governance. Lesezugriffe (catalog.search, pricing.get, inventory.check) sind risikoarm und laufen frei. Schreibzugriffe (cart.add_item) verändern den Zustand, sind aber umkehrbar. Kritische Schreibzugriffe (order.submit, payment.authorize, refund.create) bewegen Geld oder begründen Verpflichtungen – sie erfordern menschliche Freigabe, Idempotenzschlüssel zur Vermeidung doppelter Bestellungen und Audit-Protokollierung, durchgesetzt an der Tool-Grenze, unabhängig davon, welcher Kanal sie aufgerufen hat. Die eigene Governance-Schicht eines Connectors (Authentifizierung, Nutzerrechte, Freigabeschritte durch Menschen) sitzt vor dem MCP-Server, nicht an dessen Stelle.

Warum Meta Muse keinen Adapter braucht, ACP aber schon

Den Kontrast zwischen den beiden externen KI-Plattformen zeigt die Entscheidungsregel am deutlichsten. ACP von OpenAI und MCP sind verschiedene Protokolle, daher trägt der ACP-Pfad einen Adapter, der die Commerce-Semantik von ACP in MCP-Tool-Aufrufe übersetzt. Ein Connector-Modell, das seine Integration als MCP-Endpunkt einreicht, konsumiert die Capability-Schicht dagegen direkt – die Governance-Grenze bilden das Review- und Berechtigungsmodell des Connectors, aber es gibt keine zweite Übersetzungsschicht, die gebaut oder gepflegt werden müsste. Einen solchen Adapter hinzuzufügen, „weil Muse eine andere Plattform ist“, wäre Integrationsschuld ohne Funktion.

Derselbe Test gilt für jede künftige KI-Oberfläche. Stellen Sie eine einzige Frage: Kann diese Plattform MCP direkt konsumieren? Wenn ja, dockt sie am bestehenden Server an und nutzt jedes Tool weiter. Wenn nein, ergänzen Sie genau einen Protokoll-Adapter – und sonst nichts. So bleiben vier Kanäle (und der fünfte und der sechste) günstig.

Über Commerce hinaus: dieselbe Schicht wird zur Enterprise-Agentenplattform

Commerce ist nur eine MCP-Domäne. Derselbe Agent Core kann einen Commerce-MCP-Server, einen CRM-MCP-Server und einen ERP-MCP-Server aufrufen und eine Anfrage wie „Finde Produkte, die zu den bisherigen Käufen dieses Kunden passen, unter 500 $, lagernd, und bereite eine Empfehlung vor“ in einem einzigen Plan über Commerce und CRM hinweg zusammensetzen. Für die externe Delegation ermöglicht A2A – das im ersten Jahr mehr als 150 Organisationen erreichte –, dass der Einkaufsagent eines Partnerunternehmens an Ihren Vertriebsagenten delegiert, der wiederum Ihre MCP-Schicht aufruft, ohne dem Partner direkten Zugriff auf interne Systeme zu gewähren. Die Commerce-Architektur und der umfassendere MCP- + A2A-Enterprise-Stack sind dieselbe Architektur in unterschiedlichem Umfang.

Ein repräsentatives Projekt

Ein mittelständischer Händler auf Adobe Commerce wollte in ChatGPT und Meta Muse verkaufbar sein, ohne ein eigenes Plattformteam aufzubauen. Wir bauten zuerst die kanonischen Commerce-Services und den Magento-Adapter, stellten sechs MCP-Commerce-Tools bereit und setzten den Agent Core des eigenen Portals darauf. Als Nächstes folgte OpenAI: ein ACP-Adapter plus der Produkt-Feed-Transformer, die darunter exakt dieselben Tools wiederverwenden. Meta Muse war der günstigste Kanal von allen – der bestehende MCP Commerce Server wurde dokumentiert (Endpunkt, Authentifizierung, Tools, Lese-/Schreib-Klassifizierung, Freigaben für kritische Schreibzugriffe) und über das Connector-Review eingereicht, ohne dass ein proprietärer Adapter geschrieben wurde. Eine Capability-Schicht; jeder neue Kanal war ein Zugriffspfad, kein Neubau.

Weiterführende Lektüre

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together – die Protokolllandschaft, auf der diese Architektur aufsetzt, und welches Protokoll welchen Teil einer Transaktion verantwortet
• A2A vs MCP: Choosing the Right Protocol for Agent Communication – die Unterscheidung zwischen Agent-zu-Agent und Agent-zu-Tool, die A2A-Gateway und MCP-Schicht verortet
• MCP Module Code Standard – das Strukturmuster für die gesteuerten, typisierten MCP-Tools, die die Capability-Schicht wiederverwendbar machen

Wer eine Agentic-Commerce-Schicht auf dem eigenen Stack aufbauen will – Adobe Commerce, ERP, CRM –, beginnt damit, die kanonischen Capabilities einmal zu benennen, nicht pro Plattform.

Request a scoped build. Eine Woche Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang – unabhängig davon, ob Sie mit uns bauen.