Arquitectura

Arquitectura de comercio agéntico: una capa de capacidades MCP, cuatro canales de IA

Por IdeaBosqueÚltima actualización: 3 de octubre de 2026

Key takeaways

Cuatro canales de acceso de IA (un portal propio, OpenAI ACP, Meta Muse y agentes externos A2A) pueden compartir una sola capa de capacidades MCP en lugar de cuatro reimplementaciones separadas de la misma lógica de comercio.
La regla de decisión cabe en una línea: añada un adaptador de protocolo solo cuando el protocolo externo difiera de MCP. El Agentic Commerce Protocol de OpenAI necesita un adaptador ACP→MCP; un conector que ya habla MCP no necesita ninguno.
Magento / Adobe Commerce sigue siendo el sistema de registro autoritativo: ACP, MCP y A2A nunca reproducen su lógica de precios, inventario, impuestos o pedidos; la invocan.
Las herramientas de escritura se controlan según su impacto en el límite de la herramienta: las lecturas como catalog.search_products fluyen libremente, mientras que las escrituras sensibles como order.submit y payment.authorize exigen aprobación humana e idempotencia.

Conecte su catálogo de comercio a ChatGPT, a Meta Muse y a los agentes de empresas socias, y el diseño ingenuo reimplementa su lógica de precios, inventario y pago cuatro veces, una por plataforma. Cada superficie de IA habla un protocolo distinto: OpenAI presentó el Agentic Commerce Protocol (ACP, desarrollado junto con Stripe), los agentes se comunican con las herramientas mediante el Model Context Protocol (MCP) y se delegan trabajo entre sí mediante A2A. El reflejo es construir una pila de integración por plataforma. Ese reflejo es el error costoso.

Este artículo describe una arquitectura de comercio agéntico independiente del proveedor: una capa de capacidades MCP empresarial en el lado sur y múltiples canales de acceso de IA en el lado norte. Usa Magento / Adobe Commerce como ejemplo práctico del sistema de registro de comercio, pero el patrón se aplica a cualquier ERP, OMS o catálogo. El resultado central es una única regla de decisión, añada un adaptador solo cuando el protocolo de la plataforma externa deba traducirse a MCP, que indica con exactitud dónde debe ir el código de integración y, lo que es más útil, dónde no.

La trampa: cuatro plataformas, cuatro reimplementaciones

Toda superficie de comercio con IA quiere las mismas operaciones de fondo: buscar en el catálogo, consultar el inventario, obtener un precio, armar un carrito y enviar un pedido. La arquitectura ingenua conecta cada superficie directamente con la plataforma de comercio, con su propia lógica:

el sitio web propio → llamadas a medida a Magento
OpenAI / ChatGPT → otras llamadas a Magento
Meta Muse → de nuevo otras llamadas a Magento
agentes de socios → otro conjunto más

Ahora un cambio en una regla de precios, una nueva jurisdicción fiscal o una corrección en la reserva de inventario debe hacerse, y probarse, en cuatro lugares. La lógica de negocio se ha copiado, y las copias divergen. Es la misma proliferación de conectores que encarece la integración punto a punto a cualquier escala, aplicada a canales de IA en lugar de endpoints SaaS.

La solución es reducir las cuatro implementaciones del lado sur a una sola. Todos los canales llegan a la misma capa de capacidades empresarial, expuesta mediante MCP, respaldada por servicios de comercio canónicos y, en última instancia, por Magento como fuente única de verdad de productos, precios, inventario, carritos, impuestos y pedidos. Magento sigue siendo dueño de la lógica de comercio; los canales de IA solo la invocan.

La regla de decisión: adaptador solo ante un desajuste de protocolo

Los canales difieren en un único aspecto relevante para la arquitectura: qué protocolo hablan. Ese solo hecho decide si un canal necesita un adaptador de traducción o puede conectarse directamente a MCP. Los tres protocolos no compiten: responden a preguntas distintas:

Tecnología	Qué es	Qué responde
HTTP / REST / JSON	Transporte, estilo de API y formato de datos	Cómo se mueven los bytes
ACP	Interoperabilidad del comercio con IA (OpenAI + Stripe)	Cómo transaccionan una plataforma de comercio con IA y un comerciante
MCP	Interoperabilidad entre agente/aplicación y herramienta	Qué herramientas puede invocar un agente o una aplicación
A2A	Interoperabilidad entre agentes	Cómo un agente delega trabajo en otro

ACP y MCP resuelven problemas distintos, por lo que un adaptador ACP es realmente necesario: traduce la semántica de comercio de ACP (sesiones de pago, estado del pedido, formatos de feed) a llamadas de herramientas MCP. A2A también es distinto: un agente externo delega una tarea mediante A2A, que un gateway enruta a su Agent Core, el cual a su vez llama a MCP. Pero una plataforma cuyo modelo de conector ya consume MCP no necesita ningún adaptador: llega directamente a la capa de capacidades.

Esta es la parte contraintuitiva. El instinto dice "una plataforma de IA nueva significa un adaptador nuevo". La regla dice lo contrario: construya un adaptador solo cuando el protocolo de la plataforma no sea MCP. Los cuatro canales se resuelven entonces en cuatro rutas de acceso, no en cuatro integraciones:

Portal propio → Agent Core → MCP
OpenAI / ChatGPT → ACP → adaptador ACP → MCP
Meta Muse → conector Muse → MCP (sin adaptador: el conector habla MCP)
Agente externo → A2A → gateway A2A → Agent Core → MCP

Todo converge en MCP. Esa convergencia es el diseño completo:

La arquitectura en una sola vista:

El MCP Commerce Server es el límite reutilizable

La capa de capacidades es un servidor MCP que expone un conjunto pequeño y estable de herramientas de comercio: catalog.search_products, pricing.get_price, inventory.check, cart.create, cart.add_item, order.submit, order.get_status. Todos los canales usan las mismas herramientas. El Agent Core del portal propio, el adaptador ACP, el conector Muse y los agentes externos que llegan por A2A llaman todos a catalog.search_products; ninguno implementa por su cuenta la búsqueda de productos.

Es fundamental entender que MCP es la interfaz de capacidades, no el modelo de datos de negocio. Detrás de las herramientas hay servicios de comercio canónicos (un modelo independiente del protocolo de Producto, Variante, Precio, Inventario, Carrito y Pedido) y un adaptador de Magento que traduce ese modelo canónico a las API de Adobe Commerce. Cuando cambia el formato de feed de productos de OpenAI o el esquema de pago de ACP, solo cambia el adaptador ACP. Cuando cambia la API de Magento, solo cambia el adaptador de Magento. Las herramientas intermedias permanecen estables. Es la misma disciplina estructural de un módulo MCP gobernado: herramientas tipadas, un contrato estable y las peculiaridades del proveedor aisladas en los bordes.

Las herramientas se clasifican por impacto, y en esa clasificación reside la gobernanza. Las lecturas (catalog.search, pricing.get, inventory.check) son de bajo riesgo y fluyen libremente. Las escrituras (cart.add_item) modifican el estado pero son reversibles. Las escrituras sensibles (order.submit, payment.authorize, refund.create) mueven dinero o crean obligaciones: requieren aprobación humana, claves de idempotencia para evitar pedidos duplicados y registro de auditoría, aplicados en el límite de la herramienta sin importar qué canal las invoque. La capa de gobernanza propia de un conector (autenticación, permisos de usuario, puertas de aprobación humana) se sitúa delante del servidor MCP, no en su lugar.

Por qué Meta Muse no necesita adaptador y ACP sí

La ilustración más clara de la regla de decisión es el contraste entre las dos plataformas de IA externas. ACP de OpenAI y MCP son protocolos distintos, así que la ruta ACP incorpora un adaptador que traduce la semántica de comercio de ACP a llamadas de herramientas MCP. En cambio, un modelo de conector que presenta su integración como un endpoint MCP consume la capa de capacidades directamente: el límite de gobernanza es el proceso de revisión y el modelo de permisos del conector, pero no hay una segunda capa de traducción que construir ni mantener. Añadir una "porque Muse es otra plataforma" sería deuda de integración sin función alguna.

La misma prueba se extiende a toda futura superficie de IA. Haga una sola pregunta: ¿puede esta plataforma consumir MCP directamente? Si es así, se conecta al servidor existente y reutiliza todas las herramientas. Si no, añade exactamente un adaptador de protocolo, y nada más. Así se mantienen baratos cuatro canales (y el quinto, y el sexto).

Más allá del comercio: la misma capa se convierte en una plataforma de agentes empresarial

El comercio es solo un dominio MCP. El mismo Agent Core puede llamar a un servidor MCP de Commerce, a uno de CRM y a uno de ERP, componiendo una petición como "encuentra productos compatibles con las compras previas de este cliente, por menos de 500 USD, con existencias, y prepara una recomendación" entre Commerce y CRM en un solo plan. Para la delegación externa, A2A, que superó las 150 organizaciones en su primer año, permite que el agente de compras de una empresa socia delegue en su agente de ventas, que llama a su capa MCP, sin conceder al socio acceso directo a los sistemas internos. La arquitectura de comercio y la pila empresarial MCP + A2A más amplia son la misma arquitectura con alcances distintos.

Una implementación representativa

Un comerciante mediano en Adobe Commerce quería poder vender dentro de ChatGPT y Meta Muse sin contar con un equipo de plataforma. Construimos primero los servicios de comercio canónicos y el adaptador de Magento, expusimos seis herramientas de comercio MCP y apoyamos en ellas el Agent Core del portal propio. Luego vino OpenAI: un adaptador ACP más el transformador de feed de productos, reutilizando exactamente las mismas herramientas por debajo. Meta Muse fue el canal más barato de todos: se documentó el MCP Commerce Server existente (endpoint, autenticación, herramientas, clasificación de lectura/escritura, aprobaciones de escrituras sensibles) y se envió a la revisión del conector, sin escribir ningún adaptador propietario. Una sola capa de capacidades; cada canal nuevo fue una ruta de acceso, no una reconstrucción.