Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
Tres protocolos de comercio, ningún estándar: la cobertura del CMO
En apenas unas semanas de principios de 2026, tres marcos rivales sobre cómo los agentes de IA acceden a los datos de producto han aterrizado en las mesas de los CMO. Shopware lanzó su Agentic Experience Protocol (AXP), construido sobre el Universal Commerce Protocol (UCP) y respaldado por una recién creada Agentic Commerce Alliance. La propia especificación base de UCP existe como estándar abierto para el intercambio de datos entre agentes y comercio. Y el camino Instant Checkout de OpenAI, un enfoque que permite a ChatGPT completar compras directamente, sigue siendo una señal temprana: en el momento de escribir esto está documentado como activo con unos 30 comercios, una cifra que no ha escalado al nivel de mercado masivo que sugerían sus anuncios iniciales.
Mi opinión: esto no es una guerra de estándares en la que merezca la pena apostar. Es una cuestión de compromiso que conviene resolver bien.
Qué se te está pidiendo decidir en realidad
Cuando un proveedor tecnológico, una alianza o un informe de analistas te dice que «adoptes el Protocolo X», la petición implícita suele ser una de dos cosas: rediseñar la arquitectura de tu feed de datos de producto para que los agentes puedan leerlo, o construir lógica de integración dedicada para ese stack de protocolo concreto. Ambas tienen coste. Ambas conllevan el riesgo de apostar por el estándar equivocado.
Antes de tomar esa decisión, conviene ser preciso sobre qué estandarizan realmente estos protocolos y qué no.
Protocolos como AXP y UCP estandarizan la capa de intercambio de datos entre un backend de comercio y un agente de IA. Especifican cómo los datos de producto, los precios, la disponibilidad y (en el caso de AXP) señales más ricas como activos 3D e indicadores de calidad viajan desde tu sistema al contexto de un agente. Eso es genuinamente útil. Un feed de producto estructurado y legible por máquinas es mejor que uno sin estructura.
Lo que estos protocolos no especifican es qué aspecto tiene la experiencia de cara al cliente. Transportan datos. No los renderizan. El renderizado, es decir, lo que un comprador ve realmente, ya sea una persona navegando por tu tienda o un agente de IA componiendo una comparativa de productos, sigue siendo un problema de frontend.
El riesgo de fragmentación es real, pero no está donde mira la mayoría de los equipos
El planteamiento habitual sobre la fragmentación de protocolos suena así: «Puede que integremos AXP, luego gane UCP y hayamos perdido seis meses». Es un riesgo real. Pero es el riesgo secundario.
El riesgo principal es más sutil: comprometerse con un stack de integración específico de un protocolo en la capa de frontend. Construir una ruta de renderizado fuertemente acoplada a la forma de los datos de un único protocolo. Escribir componentes de frontend que asumen el formato Rich Experience de AXP o los nombres de campo de UCP. Esa es la capa donde la fragmentación se vuelve cara, no porque el protocolo pierda, sino porque tu lógica de renderizado no puede adaptarse cuando el protocolo evoluciona, aparece un segundo protocolo o cambia tu backend.
Ahí es donde debe situarse la cobertura.
La cobertura racional: una capa de renderizado agnóstica al protocolo
El planteamiento a nivel de CMO al que vuelvo una y otra vez en conversaciones con marcas de mid-market y enterprise es este: no necesitas apostar por un protocolo. Necesitas una capa de frontend capaz de renderizar cualquiera que acabe imponiéndose.
Tres protocolos quieren tus productos. Esa es una cuestión de feed de datos para tu backend de comercio. Tu equipo de backend puede evaluar qué feeds exponer y con qué cadencia. Ese trabajo es abordable.
La cuestión de la experiencia, qué aspecto tiene tu marca cuando un agente muestra tu producto, qué ve una persona cuando llega a tu tienda, cómo se mantienen coherentes ambas superficies, es una cuestión de frontend. Y la respuesta es la misma con independencia de qué protocolo transporte los datos.
Una capa de frontend que desacopla el renderizado de las particularidades del protocolo puede consumir un feed UCP, un payload Rich Experience de AXP o una estructura de producto compatible con OpenAI y renderizar la misma experiencia de marca a partir de las tres. No es una arquitectura teórica. Es la ventaja concreta de construir sobre un frontend Composable Headless en lugar de sobre una ruta de integración nativa de un protocolo.
La Agentic Frontend Management Platform de Laioutr está construida exactamente en torno a este modelo: una capa de renderizado, múltiples feeds de protocolo, una única salida de marca.
Implicación presupuestaria: dónde no gastar
Si tu conversación presupuestaria de este trimestre incluye una partida para un «stack de integración del Protocolo X», ingeniería dedicada a parsear y renderizar el formato de datos concreto de un protocolo en toda tu tienda, yo me lo pensaría antes de aprobarla.
La pregunta que hay que hacerse es: ¿este stack de integración es específico de un protocolo o es agnóstico al protocolo?
Específico de un protocolo: construyes componentes que esperan los nombres de campo de AXP. Cuando AXP se actualice o un segundo protocolo se vuelva obligatorio para un canal de distribución clave, toca reconstruir.
Agnóstico al protocolo: construyes una capa de normalización de datos que mapea cualquier formato de feed entrante a la forma que espera tu librería de componentes. Los cambios de protocolo se gestionan en el adaptador, no en los componentes.
El segundo camino cuesta más de diseñar al principio. Cuesta menos a 24 meses vista, porque no reconstruyes el frontend cada vez que cambia el panorama de protocolos, y ese panorama va a cambiar. Ninguno de los tres estándares que he citado al principio de este post ha ganado. El camino de OpenAI se ha estancado en escala. AXP está respaldado por una alianza, pero es incipiente. UCP es una base abierta que varios proveedores están extendiendo en direcciones distintas. Apostar el frontend a uno solo de ellos es la jugada cara.
Para profundizar en por qué la capa backend a agente y la capa de renderizado de frontend deben tratarse como decisiones presupuestarias separadas, el post Every Backend Ships Agents desarrolla en detalle el planteamiento desde la óptica del CFO.
La pregunta de auditoría de stack para tu próxima sesión CMO y CFO
Una cosa concreta que puedes llevar a tu próxima revisión de stack:
«¿Cuáles de nuestros componentes de frontend actuales asumen el formato de datos de un protocolo concreto y cuáles están normalizados contra una capa de abstracción?»
Si la respuesta es «la mayoría de los componentes están fuertemente acoplados a la forma de la API de nuestro backend actual», eso no es una crisis inmediata. Lo será cuando la segunda o tercera petición de integración de un protocolo llegue al equipo de ingeniería. El momento de construir la capa de abstracción es antes de que llegue el segundo protocolo, no después.
Un visual page builder que se sitúa por encima de la capa de datos y permite a los equipos de marketing iterar la experiencia con independencia de los cambios de backend es una parte de la respuesta. La otra parte es la capa de normalización en la frontera del feed de datos, la pieza que hace que a tus componentes les dé igual si el feed de hoy es AXP, UCP o algo que aún no existe.
Esta es también la arquitectura que te da coherencia multimarca a escala. Una librería de componentes renderizando sobre tres feeds de protocolo responde al mismo principio que una librería de componentes renderizando sobre tres tiendas regionales. La abstracción es el activo. Véase también: consolidación MarTech y dispersión del stack.
Nota de arquitectura de Sebastian: A nivel de implementación, una capa de renderizado agnóstica al protocolo funciona mediante un patrón de adaptador de feeds. Cada protocolo, AXP, UCP o una API de backend propia, se mapea a un adaptador ligero que normaliza los datos entrantes a un esquema de producto compartido (título, precio, referencias de medios, atributos estructurados). La librería de componentes de frontend consume únicamente ese esquema normalizado. Cambiar o añadir un protocolo significa escribir un nuevo adaptador, no tocar los componentes. En un frontend Composable, esto es un servicio de integración adicional, no una reconstrucción del frontend. El árbol de componentes se mantiene estable mientras se multiplican las fuentes de datos.
Qué señala la fragmentación sobre 2026 y 2027
El hecho de que existan tres stacks de protocolo rivales al mismo tiempo es en sí mismo una señal útil. Te dice que la capa de datos entre comercio y agente no está asentada. Organismos de estandarización, grandes proveedores de plataforma e hiperescalares intentan cada uno adueñarse de esta capa, que es exactamente el patrón que se ve en los años previos a que emerja un estándar de facto. La arquitectura MACH vivió un periodo similar de «qué proveedor Composable fijará el estándar» antes de que los patrones del stack se asentaran en formas comunes.
El trabajo del CMO en ese entorno no es elegir pronto al ganador. Es estructurar la apuesta de infraestructura de modo que puedas adoptar a cualquier ganador sin una reconstrucción completa. Esa es la cobertura. Y el lugar donde construirla es la capa de renderizado del frontend, la parte de tu stack que toca todos los protocolos por igual y que puede diseñarse para no depender específicamente de ninguno.
Nada de esto exige esperar. La arquitectura agnóstica al protocolo está disponible hoy, porque en realidad no va de los protocolos. Va de cómo construyes tus componentes de frontend.
Lecturas adicionales:
CTA: Si quieres auditar tu arquitectura de frontend actual frente a la cuestión de la fragmentación de protocolos, estaré encantado de hacer contigo una auditoría de stack de 30 minutos. Un mapa de solapamientos concreto, no una diapositiva de demo.
Más sobre Laioutr: Personalization.