Skeleton- & Loading-States: Der Hebel gefühlter SpeedEuer LCP liegt unter zwei Sekunden. Euer IN…
Drei Commerce-Protokolle, kein Standard: Der CMO-Hedge
Drei Commerce-Protokolle, kein Standard: Der CMO-Hedge
Innerhalb weniger Wochen sind Anfang 2026 gleich drei konkurrierende Frameworks dafür aufgetaucht, wie KI-Agenten auf Produktdaten zugreifen. Shopware hat das Agentic Experience Protocol (AXP) eingeführt, aufgesetzt auf dem Universal Commerce Protocol (UCP) und getragen von einer neu gegründeten Agentic Commerce Alliance. Die UCP-Basis selbst existiert als offener Standard für den Datenaustausch zwischen Agents und Commerce-Systemen. Und OpenAIs Instant-Checkout-Pfad, der es ChatGPT ermöglicht, Käufe direkt abzuschließen, bleibt ein frühes Signal: Zum Zeitpunkt dieses Beitrags ist er mit etwa 30 Merchants dokumentiert, eine Zahl, die sich nicht auf das Mass-Market-Niveau skaliert hat, das erste Ankündigungen andeuteten.
Mein Take: Das ist kein Standardskrieg, auf den es sich zu wetten lohnt. Es ist eine Commitment-Frage, die es richtig zu stellen gilt.
Was du gerade entscheiden sollst
Wenn ein Technologieanbieter, eine Alliance oder ein Analyst-Report dir sagt, "Protokoll X zu adoptieren", steckt dahinter meist eine von zwei Forderungen: Restrukturiere deinen Produktdaten-Feed, damit Agents ihn lesen können - oder bau dedizierte Integrationslogik für diesen spezifischen Protokoll-Stack. Beides kostet. Beides trägt das Risiko, auf den falschen Standard zu setzen.
Bevor du diese Entscheidung triffst, lohnt es sich, präzise zu klären, was diese Protokolle tatsächlich standardisieren - und was nicht.
Protokolle wie AXP und UCP standardisieren die Datenaustausch-Schicht zwischen einem Commerce-Backend und einem KI-Agenten. Sie definieren, wie Produktdaten, Preise, Verfügbarkeiten und (im Fall von AXP) reichhaltigere Signale wie 3D-Assets und Qualitätsindikatoren von deinem System in den Kontext eines Agents gelangen. Das ist genuiner Mehrwert. Ein strukturierter, maschinenlesbarer Produkt-Feed ist besser als ein unstrukturierter.
Was diese Protokolle nicht definieren, ist das Aussehen der kundenseitigen Experience. Sie transportieren Daten. Sie rendern sie nicht. Das Rendering, was ein Käufer tatsächlich sieht, egal ob es sich um einen Menschen handelt, der deinen Storefront durchstöbert, oder einen KI-Agent, der einen Produktvergleich zusammenstellt, bleibt ein Frontend-Problem.
Das Fragmentierungs-Risiko ist real, aber nicht dort, wo die meisten Teams hinschauen
Die übliche Rahmung des Protokoll-Fragmentierungs-Problems lautet: "Wir integrieren vielleicht AXP, dann gewinnt UCP, und wir haben sechs Monate investiert." Das ist ein reales Risiko. Aber es ist das sekundäre.
Das primäre Risiko ist subtiler: die Bindung an einen protokollspezifischen Integrations-Stack auf der Frontend-Schicht. Eine Rendering-Logik aufzubauen, die eng an das Datenformat eines bestimmten Protokolls gekoppelt ist. Frontend-Komponenten zu schreiben, die das Rich-Experience-Format von AXP oder die Feldnamen von UCP voraussetzen. Das ist die Schicht, auf der Fragmentierung teuer wird, nicht weil das Protokoll verliert, sondern weil deine Rendering-Logik nicht flexibel genug ist, wenn das Protokoll sich weiterentwickelt, ein zweites Protokoll hinzukommt oder dein Backend wechselt.
Genau hier muss der Hedge ansetzen.
Der rationale Hedge: ein protokoll-agnostischer Render-Layer
Die CMO-Rahmung, zu der ich in Gesprächen mit Mid-Market- und Enterprise-Brands immer wieder zurückkomme, lautet: Du musst nicht auf ein Protokoll wetten. Du brauchst einen Frontend-Layer, der rendern kann, welches Protokoll auch immer gewinnt.
Drei Protokolle wollen deine Produkte. Das ist eine Datenfeed-Frage für dein Commerce-Backend. Dein Backend-Team kann evaluieren, welche Feeds es in welchem Rhythmus bereitstellt. Diese Arbeit ist kalkulierbar.
Die Experience-Frage dagegen, wie deine Marke aussieht, wenn ein Agent dein Produkt an die Oberfläche bringt, was ein Mensch sieht, der auf deinen Storefront gelangt, wie diese zwei Surfaces konsistent bleiben, ist eine Frontend-Frage. Und sie hat dieselbe Antwort, unabhängig davon, welches Protokoll die Daten trägt.
Ein Frontend-Layer, der das Rendering von den Protokoll-Spezifika entkoppelt, kann einen UCP-Feed, ein AXP-Rich-Experience-Payload oder eine OpenAI-kompatible Produktstruktur konsumieren und aus allen drei dieselbe Brand-Experience rendern. Das ist keine theoretische Architektur. Es ist der konkrete Vorteil, auf einem composable headless Frontend aufzubauen, statt auf einem protokollnativen Integrationspfad.
Die Agentic Frontend Management Platform von Laioutr ist genau nach diesem Modell gebaut: ein Render-Layer, mehrere Protokoll-Feeds, ein Brand-Output.
Budget-Implikation: wo du nicht ausgeben solltest
Wenn dein Budget-Gespräch in diesem Quartal eine Zeile "Protokoll-X-Integrations-Stack" enthält, also dedizierte Engineering-Kapazität, um das spezifische Datenformat eines Protokolls über deinen Storefront zu parsen und zu rendern, würde ich pausieren, bevor ich das abnicke.
Die Frage, die du stellen solltest: Ist dieser Integrations-Stack protokollspezifisch oder protokoll-agnostisch?
Protokollspezifisch: Du baust Komponenten, die die Feldnamen von AXP erwarten. Wenn AXP ein Update liefert oder ein zweites Protokoll für einen wichtigen Distributionskanal verpflichtend wird, baust du neu.
Protokoll-agnostisch: Du baust eine Normalisierungs-Schicht, die jedes eingehende Feed-Format auf das erwartete Schema deiner Komponenten-Bibliothek abbildet. Protokolländerungen werden im Adapter behandelt, nicht auf Komponenten-Ebene.
Der zweite Weg kostet mehr im Design-Upfront. Er kostet weniger über 24 Monate, weil du das Frontend nicht jedes Mal neu aufbaust, wenn sich die Protokoll-Landschaft verschiebt - und sie wird sich verschieben. Keiner der drei Standards, die ich zu Beginn dieses Beitrags genannt habe, hat gewonnen. OpenAIs Pfad stagniert skalierungsmäßig. AXP ist alliance-getragen, aber früh. UCP ist eine offene Basis, die mehrere Anbieter in unterschiedliche Richtungen erweitern. Auf eine von ihnen das Frontend zu wetten, ist der teure Zug.
Für einen detaillierten Blick darauf, warum die Backend-zu-Agent-Schicht und die Frontend-Rendering-Schicht als separate Budget-Entscheidungen behandelt werden müssen, arbeitet der Beitrag Every Backend Ships Agents das CFO-Framing durch.
Die Stack-Audit-Frage für euren nächsten CMO-CFO-Sync
Eines, das du konkret in deine nächste Stack-Review-Runde einbringen kannst:
"Welche unserer aktuellen Frontend-Komponenten setzen das Datenformat eines bestimmten Protokolls voraus - und welche sind gegen eine Abstraktionsschicht normalisiert?"
Wenn die Antwort lautet "die meisten Komponenten sind eng an das API-Shape unseres aktuellen Backends gekoppelt", ist das kein sofortiges Problem. Es wird zu einem, wenn die zweite oder dritte Protokoll-Integrationsanfrage beim Engineering-Team auftaucht. Den Abstraktions-Layer zu bauen, ist dann günstiger, wenn der zweite Feed noch nicht angeklopft hat.
Ein Visual Page Builder, der über der Datenschicht liegt und Marketing-Teams erlaubt, die Experience unabhängig von Backend-Änderungen zu iterieren, ist ein Teil der Antwort. Der andere Teil ist die Normalisierungs-Schicht an der Datenfeed-Grenze, das Stück, das bedeutet, dass deine Komponenten nicht wissen müssen, ob der heutige Feed AXP oder UCP ist oder etwas, das es noch nicht gibt.
Das ist auch die Architektur, die dir Multi-Brand-Konsistenz in der Skalierung ermöglicht. Eine Komponenten-Bibliothek, die über drei Protokoll-Feeds rendert, folgt demselben Prinzip wie eine Komponenten-Bibliothek, die über drei regionale Storefronts rendert. Die Abstraktion ist das Asset. Weiterführend: MarTech-Konsolidierung und Stack-Sprawl.
Sebastians Architektur-Notiz: Auf Implementierungsebene funktioniert ein protokoll-agnostischer Render-Layer über ein Feed-Adapter-Muster. Jedes Protokoll, AXP, UCP oder eine eigene Backend-API, hat einen schlanken Adapter, der eingehende Daten auf ein geteiltes Produkt-Schema normalisiert (Titel, Preis, Medien-Refs, strukturierte Attribute). Die Frontend-Komponenten-Bibliothek konsumiert nur dieses normalisierte Schema. Ein Protokollwechsel oder ein neues Protokoll bedeutet: neuen Adapter schreiben, keine Komponenten anfassen. In einem composable Frontend ist das ein zusätzlicher Integrations-Service, kein Frontend-Rebuild. Der Komponenten-Tree bleibt stabil, während die Datenquellen wachsen.
Was die Fragmentierung über 2026 und 2027 aussagt
Die Tatsache, dass drei konkurrierende Protokoll-Stacks gleichzeitig existieren, ist selbst ein nützliches Signal. Es zeigt, dass die Commerce-zu-Agent-Datenschicht nicht settled ist. Standards-Gremien, große Plattform-Anbieter und Hyperscaler versuchen jeweils, diese Schicht zu besitzen - genau das Muster, das man in den Jahren vor dem Entstehen eines De-facto-Standards sieht. MACH-Architektur hatte eine ähnliche Phase, in der die Frage lautete "Welcher composable Anbieter setzt den Standard?", bevor sich Stack-Patterns auf gemeinsame Formen eingespielt hatten.
Die Aufgabe des CMOs in diesem Umfeld ist nicht, den Gewinner früh zu wählen. Es ist, die Infrastruktur-Wette so zu strukturieren, dass du jeden Gewinner übernehmen kannst, ohne einen vollständigen Rebuild. Das ist der Hedge. Und der Platz, an dem du den Hedge baust, ist die Frontend-Render-Schicht, der Teil deines Stacks, der jedes Protokoll gleich behandelt und dazu gebracht werden kann, spezifisch für keines von ihnen zu sein.
Das erfordert kein Warten. Die protokoll-agnostische Architektur ist heute verfügbar, weil sie eigentlich nicht über die Protokolle geht. Es geht darum, wie du deine Frontend-Komponenten baust.
Weiterführende Links:
CTA: Wenn du deine aktuelle Frontend-Architektur gegen die Protokoll-Fragmentierungs-Frage auditieren willst, mache ich gerne ein 30-minütiges Stack-Audit mit dir. Konkrete Overlap-Map, keine Demo-Folie.