Cuando un agente de IA vende en tu nombre: conectando Shopify al stack B2B

El problema: los agentes pueden comprar, pero tu stack B2B no puede cotizar de vuelta

Un consumidor que compra a través de ChatGPT o Gemini de Google ahora puede descubrir productos, añadirlos a un carrito y finalizar la compra sin abrir una pestaña del navegador. El artículo de agentic commerce de Shopify reporta que en Q1 2026, el tráfico impulsado por IA a las tiendas Shopify creció 8 veces interanual y los pedidos de búsquedas impulsadas por IA aumentaron casi 13 veces. Los nuevos compradores realizan pedidos a través de canales de IA a casi el doble de la tasa de otros canales. Los datos empresariales de Shopify van más allá: los compradores referidos por IA convierten a tasas casi 50% más altas y llevan valores de pedido promedio 14% más altos que el tráfico de búsqueda orgánica.

Para una marca de consumo, eso es un viento a favor. Para un distribuidor B2B de mid-market que opera Shopify o BigCommerce en el front-end y NetSuite o Brightpearl en el back-end, es un problema diferente. El comprador al otro lado del agente de IA no es un consumidor — es un coordinador de aprovisionamiento en una empresa que ha negociado niveles de precio, términos de crédito y descuentos por volumen que no existen en el catálogo de Shopify. El agente de IA ve el precio público. El cliente tiene derecho contractual a un precio diferente. Cuando el agente finaliza la compra al precio público, el distribuidor absorbe el margen o cancela el pedido y pierde la venta.

El segundo problema es el inventario. Una cotización B2B no es una compra impulsiva — avanza a través de aprobaciones, a veces por días. El inventario en tiempo real de Shopify es preciso, pero no es reservable. Un agente que cotiza 200 unidades contra un conteo en vivo de 240 puede estar equivocado para cuando la orden de compra llega, porque tres cotizaciones más consumieron el mismo stock en el intermedio. El patrón del motor RFQ que maneja esto — reservas de disponibilidad atómicas con un TTL, instantáneas de políticas de cancelación, bloqueos de tipo de cambio FX — vive en el ERP y la capa de cotización, no en el storefront de ecommerce.

El tercer problema es la atribución. La revisión de Shopify AI 2026 de Polar Analytics lo nombra directamente: "cada herramienta califica su propia tarea, por lo que los ingresos atribuidos suman más de lo que la tienda generó." Cuando ChatGPT, Google AI Mode, Copilot y el propio storefront del comerciante reclaman el mismo pedido, la línea de ingresos deja de ser confiable. Para un equipo de finanzas que necesita reportar el mix de canales a un directorio, los ingresos no atribuibles son un problema de reporte, no un problema de vanidad de marketing.

Lo que la superficie de primera parte cubre, y lo que no cubre

Shopify ha hecho más trabajo de primera parte con agentes de IA que cualquier otra plataforma de commerce. El Storefront MCP server expone descubrimiento de productos, gestión de carrito, información de tienda y gestión de pedidos a través de Model Context Protocol. El Customer Accounts MCP server maneja seguimiento de pedidos y devoluciones. El Universal Commerce Protocol (UCP), co-desarrollado con Google y respaldado por Amazon, American Express, Etsy, Mastercard, Meta, Microsoft, Salesforce, Stripe, Target, Walmart y Visa, define cómo los agentes de IA transaccionan con comerciantes a través de cualquier plataforma y cualquier procesador de pagos. Google introdujo el Universal Cart en Google I/O 2026 (19 de mayo de 2026), construido sobre un Shopping Graph de más de 60 mil millones de listados de productos, con un Agent Payments Protocol (AP2) que permite a los agentes pagar dentro de límites de gasto y de marca especificados por el usuario.

La superficie de primera parte resuelve el camino de consumo: un comprador pide un producto a un agente de IA, el agente lo encuentra en Shopify Catalog, lo añade a un carrito y finaliza la compra a través de Shopify Checkout. El comerciante permanece como comerciante de registro. No se requiere integración personalizada para productos elegibles — Shopify Catalog auto-sindica datos estructurados a plataformas de IA.

Lo que la superficie de primera parte no resuelve es el camino B2B. El Storefront MCP server expone datos de catálogo público. No expone precios por segmento de cliente, tasas contractuales negociadas, niveles de cantidad por volumen ni términos de crédito específicos de cuenta. No reserva inventario — reporta disponibilidad. No escribe el pedido aceptado de vuelta a NetSuite con la codificación GL correcta, subsidiaria y nexus fiscal. No genera un documento de cotización que un equipo de aprovisionamiento pueda adjuntar a una orden de compra. No produce una pista de auditoría que mapee qué canal de IA originó el pedido y qué llamadas a herramienta ejecutaron el checkout.

Este es el mismo patrón estructural que aparece en el análisis del módulo MCP de NetSuite: el conector de primera parte del proveedor resuelve el problema de conexión. No resuelve el problema de la capa semántica — la brecha entre lo que dicen los datos y lo que significa el negocio. Para NetSuite, la brecha semántica es qué cuentas del libro mayor constituyen ingresos. Para Shopify B2B, la brecha semántica es qué precio aplica a qué cliente para qué cantidad bajo qué términos.

La solución B2B orquestada por el agente

El patrón de producción es un módulo MCP personalizado que se sitúa entre el agente de IA y el stack B2B completo — Shopify en el front-end, NetSuite o Brightpearl en el back-end, el grafo de catálogo de proveedores en el medio, y el motor RFQ manejando cotización y reservas. El Storefront MCP de primera parte maneja el descubrimiento de productos y la mecánica del carrito. El módulo personalizado maneja la lógica comercial que el storefront no conoce.

Considera un distribuidor que vende componentes industriales a tres segmentos de cliente: cuentas enterprise con precios contractuales negociados, cuentas mid-market con niveles por volumen y compradores transaccionales al precio público de catálogo. Un agente de IA que representa al coordinador de aprovisionamiento de un comprador enterprise envía una solicitud de 500 unidades de un componente. El agente no ve un precio público — ve un punto de partida. El módulo personalizado intercepta la solicitud y hace cuatro cosas que la superficie de primera parte no puede:

Primero, resuelve la identidad y el segmento del cliente. El agente porta un identificador de cuenta (no una tarjeta de crédito), y el módulo busca el nivel de precio negociado para esa cuenta y producto. El precio que el agente cotiza es el precio de contrato, no el precio de catálogo. La arquitectura del motor RFQ maneja esto a través de niveles de precio basados en segmento cargados desde el lote de artículo de proveedor y filtrados por umbrales de cantidad.

Segundo, adquiere una reserva de disponibilidad. El módulo llama a la operación acquire_availability_hold del motor RFQ contra el conteo de inventario de NetSuite, decrementando la capacidad disponible atómicamente y retornando un token de reserva con un TTL. La cotización ahora está respaldada por stock real reservado — no un conteo en vivo que puede desaparecer antes de que el comprador apruebe. Si el comprador acepta dentro de la ventana, la reserva se confirma sin un segundo decremento. Si el TTL expira, la capacidad se restaura y la siguiente cotización puede usarla.

Tercero, toma una instantánea de los términos comerciales. La política de cancelación, el tipo de cambio FX (si la moneda del comprador difiere de la del proveedor) y cualquier promoción temporal se congelan al momento de la cotización. Si el proveedor endurece los términos de cancelación a mitad de la negociación, la cotización lleva los términos que estaban vigentes cuando se emitió. La disputa que de otro modo seguiría no ocurre.

Cuarto, escribe el pedido aceptado de vuelta a NetSuite a través de la superficie de API correcta — SuiteTalk REST para el registro de pedido, un RESTlet para validación personalizada, SuiteQL para cualquier lectura que necesite joins — con el límite de concurrencia respetado, la firma OAuth computada internamente y una entrada de log de auditoría para cada llamada a herramienta. El agente nunca construye una firma OAuth ni elige una superficie de API. Llama a create_order y el módulo hace el resto.

Dónde permanece el humano en el bucle: el módulo enruta las resoluciones de precio de baja confianza, los pedidos por debajo de los límites de margen y cualquier solicitud de una cuenta nueva a un revisor humano antes de enviar la cotización. El campo guardrail_price_per_uom marca cualquier cotización donde un descuento baja el precio por debajo del costo del lote. El agente propone, el humano aprueba las excepciones, y el log de auditoría muestra quién aprobó qué y cuándo.

El resultado

Las mejoras medibles son concretas. El tiempo de cotización cae de días a minutos porque el agente resuelve producto, precio y disponibilidad en una sola pasada en lugar de tres búsquedas manuales entre Shopify, la hoja de cálculo de precios y NetSuite. La reserva de disponibilidad elimina el problema de sobre-promesa — una cotización está respaldada por stock reservado o no se emite. Los precios basados en segmento eliminan la erosión de margen que ocurre cuando un cliente de contrato es cotizado al precio público porque el agente no sabía que el contrato existía. El log de auditoría produce un registro de atribución de canal que vincula el pedido con la plataforma de IA originaria, las llamadas a herramienta que lo ejecutaron y las aprobaciones humanas que lo modificaron — el problema de atribución que Polar Analytics identifica como "cada herramienta califica su propia tarea" se resuelve en la capa del módulo, no confiando en el crédito auto-reportado de una sola plataforma.

El crecimiento interanual de pedidos del 13x desde canales de IA que Shopify reporta no es una ola que los distribuidores B2B puedan ignorar. Los distribuidores que lo capturan son aquellos cuya capa de agente sabe la diferencia entre un checkout de consumo y una cotización B2B — y tiene el patrón de módulo que hace posible la segunda.

Un distribuidor que opera Shopify en el storefront, NetSuite para ERP y tres catálogos de proveedores obtiene un agente que recibe una solicitud de un canal de compras de IA, resuelve el nivel de precio negociado del cliente, adquiere una reserva de disponibilidad atómica contra el inventario de NetSuite, toma instantáneas de los términos de cancelación y FX, y escribe el pedido aceptado de vuelta a NetSuite a través de la superficie de API correcta — con cada llamada a herramienta registrada y cada excepción enviada a un revisor humano. Ese build es la Fase 2-3 del método de cuatro pasos y está típicamente en vivo en 5-8 semanas.

Solicita un build con alcance definido. Discovery de una semana. Obtienes un inventario de sistemas, mapa de flujo de trabajo y alcance fijo — independientemente de si construyes con nosotros.