At the eCommerce BBQ 2026, one line captured the mood of the whole evening: yesterday we did what wa…
Three Commerce Protocols, No Standard: A CMO's Hedge
Three Commerce Protocols, No Standard: A CMO's Hedge
Within the span of a few weeks in early 2026, three competing frameworks for how AI agents access product data have landed on CMOs' desks. Shopware launched its Agentic Experience Protocol (AXP), built on top of the Universal Commerce Protocol (UCP) and backed by a newly formed Agentic Commerce Alliance. The UCP base specification itself exists as an open standard for agent-to-commerce data exchange. And OpenAI's Instant Checkout path - an approach that lets ChatGPT complete purchases directly - remains an early signal: as of the time of writing, it is documented as active with roughly 30 merchants, a number that has not scaled to the mass-market level its initial announcements implied.
My take: this is not a standards war worth betting on. It is a commitment question worth getting right.
What you are actually being asked to decide
When a technology vendor, an alliance, or an analyst report tells you to "adopt Protocol X", the implicit ask is usually one of two things: re-architect your product data feed so agents can read it, or build dedicated integration logic for that specific protocol stack. Both carry costs. Both carry the risk of backing the wrong standard.
Before you make that call, it is worth being precise about what these protocols actually standardize - and what they do not.
Protocols like AXP and UCP standardize the data exchange layer between a commerce backend and an AI agent. They specify how product data, pricing, availability, and (in AXP's case) richer signals like 3D assets and quality indicators travel from your system to an agent's context. That is genuinely useful. A structured, machine-readable product feed is better than an unstructured one.
What these protocols do not specify is how the customer-facing experience looks. They carry data. They do not render it. The rendering - what a shopper actually sees, whether that shopper is a human browsing your storefront or an AI agent composing a product comparison - is still a frontend problem.
The fragmentation risk is real, but it is not where most teams are looking
The standard framing of protocol fragmentation goes like this: "We might integrate AXP, then UCP wins, and we have wasted six months." That is a real risk. But it is the secondary risk.
The primary risk is subtler: committing to a protocol-specific integration stack at the frontend layer. Building a rendering path that is tightly coupled to one protocol's data shape. Writing frontend components that assume AXP's Rich Experience format or UCP's field names. That is the layer where fragmentation becomes expensive - not because the protocol loses, but because your rendering logic cannot flex when the protocol evolves, a second protocol emerges, or your backend changes.
This is where the hedge needs to sit.
The rational hedge: a protocol-agnostic render layer
The CMO-level framing I keep coming back to in conversations with mid-market and enterprise brands is this: you do not need to bet on a protocol. You need a frontend layer that can render whichever protocol wins.
Three protocols want your products. That is a data-feed question for your commerce backend. Your backend team can evaluate which feeds to expose and in what cadence. That work is tractable.
The experience question - what your brand looks like when an agent surfaces your product, what a human sees when they land on your storefront, how those two surfaces stay consistent - is a frontend question. And it is one that has the same answer regardless of which protocol carries the data.
A frontend layer that decouples rendering from protocol specifics can consume a UCP feed, an AXP Rich Experience payload, or an OpenAI-compatible product structure and render the same brand experience from all three. That is not a theoretical architecture. It is the concrete advantage of building on a composable headless frontend rather than on a protocol-native integration path.
The Laioutr Agentic Frontend Management Platform is built around exactly this model: one render layer, multiple protocol feeds, one brand output.
Budget implication: where not to spend
If your budget conversation this quarter involves a line item for "Protocol X integration stack" - dedicated engineering to parse and render one protocol's specific data format across your storefront - I would pause before approving it.
The question to ask is: is this integration stack protocol-specific, or is it protocol-agnostic?
Protocol-specific: you build components that expect AXP's field names. When AXP updates or a second protocol becomes mandatory for a key distribution channel, you rebuild.
Protocol-agnostic: you build a data normalization layer that maps any incoming feed format to your component library's expected shape. Protocol changes are handled at the adapter, not at the component level.
The second path costs more to design upfront. It costs less over 24 months, because you are not rebuilding the frontend each time the protocol landscape shifts - and the protocol landscape is going to shift. None of the three standards I named at the start of this post has won. OpenAI's path has stalled at scale. AXP is alliance-backed but early. UCP is an open base that multiple vendors are extending in different directions. Betting the frontend on any single one of them is the expensive move.
For a deeper look at why the backend-to-agent layer and the frontend rendering layer need to be treated as separate budget decisions, the post Every Backend Ships Agents works through the CFO framing in detail.
The stack audit question for your next CMO-CFO sync
One concrete thing you can bring to your next stack review:
"Which of our current frontend components assume a specific protocol's data format - and which are normalized against an abstraction layer?"
If the answer is "most components are tightly coupled to our current backend's API shape", that is not immediately a crisis. It becomes one when the second or third protocol integration request lands on the engineering team. The time to build the abstraction layer is before the second protocol arrives, not after.
A visual page builder that sits above the data layer and lets marketing teams iterate the experience independently of backend changes is one part of the answer. The other part is the normalization layer at the data-feed boundary - the piece that means your components do not care whether today's feed is AXP or UCP or something that does not exist yet.
This is also the architecture that gives you multi-brand consistency at scale. One component library rendering across three protocol feeds is the same principle as one component library rendering across three regional storefronts. The abstraction is the asset. See also: MarTech consolidation and stack sprawl.
Sebastian's architecture note: At the implementation level, a protocol-agnostic render layer works through a feed adapter pattern. Each protocol - AXP, UCP, or a custom backend API - maps to a thin adapter that normalizes incoming data to a shared product schema (title, price, media refs, structured attributes). The frontend component library consumes only that normalized schema. Changing or adding a protocol means writing a new adapter, not touching components. In a composable frontend, this is one additional integration service, not a frontend rebuild. The component tree stays stable while the data sources multiply.
What the fragmentation signals about 2026 and 2027
The fact that three competing protocol stacks exist simultaneously is itself a useful signal. It tells you that the commerce-to-agent data layer is not settled. Standards bodies, major platform vendors, and hyperscalers are each trying to own this layer - which is exactly the pattern you see in the years before a de facto standard emerges. MACH architecture had a similar period of "which composable vendor will set the standard" before the stack patterns settled into common shapes.
The CMO's job in that environment is not to pick the winner early. It is to structure the infrastructure bet so that you can adopt any winner without a full rebuild. That is the hedge. And the place to build the hedge is at the frontend render layer - the part of your stack that touches every protocol equally and can be made to care about none of them specifically.
None of this requires waiting. The protocol-agnostic architecture is available now, because it is not actually about the protocols. It is about how you build your frontend components.
Further reading:
CTA: If you want to audit your current frontend architecture against the protocol fragmentation question, I'm happy to run a 30-minute stack audit with you. Concrete overlap map, not a demo slide.