Agentes compradores: ¿qué debe exponer tu software?

Exponer una oferta a agentes compradores no es abrir una API del producto: es publicar la oferta en la superficie comercial en un formato que la máquina lee sin abrir el navegador. El camino existe y tiene dirección: el Universal Commerce Protocol, publicado el 11 de enero de 2026, con especificación en ucp.dev. Lo que sigue abierto es el contenido del camino.

El 16 de octubre de 2026 Vercel publicó las piezas que hacen ejecutable ese camino: Vercel Shop en disponibilidad general, una plantilla open source de storefront en Next.js para Shopify y el SDK de Hydrogen reconstruido, también en GA. Eso resuelve la infraestructura de quien vende un producto físico, no el plan con vigencia, el límite por asiento ni la región de facturación. Publicar la oferta como dato y decidir quién responde por un pedido armado por una máquina sigue siendo trabajo del vendedor de software.

¿Qué cambió el 16 de octubre de 2026?

El 16 de octubre de 2026 Vercel puso Vercel Shop en disponibilidad general y el SDK de Hydrogen reconstruido en GA. Vercel Shop permite descubrir las capacidades del UCP en el dominio del comerciante, que es donde lee un agente comprador.

El UCP se publicó el 11 de enero de 2026, co-desarrollado por Shopify con Google, con especificación en ucp.dev. Cubre cinco capacidades: Catalog, Cart, Checkout, Identity Linking y Order Management. La vinculación de cuenta usa OAuth 2.0. El cierre autónomo depende de la extensión de mandatos de AP2; sin ella, la especificación manda terminar el checkout en una interfaz confiable, con el comprador presente. El estado requires_escalation, con continue_url obligatorio, devuelve la transacción a una persona cuando falta un dato o falta autorización. Los perfiles quedan en /.well-known/ucp, en el dominio del comerciante.

El UCP cambia el costo de integración por par. Un agente comprador que habla UCP no necesita un conector a medida para cada tienda. El UCP define las capacidades de catálogo, carrito y checkout y apoya la especificación en transporte REST y JSON-RPC, con soporte incorporado para AP2, A2A y MCP. MCP para e-commerce es la capa de llamada a herramienta: el agente llama una herramienta que habla UCP, sin navegar por el sitio.

El anuncio cita a AG1, Bombas y PAIGE como usuarias del stack. PAIGE, minorista, registró +22% de ingresos y +76% de conversión entre Black Friday y Cyber Monday, sin caídas, en el caso publicado por Vercel. Es dato de retail, del proveedor, dentro de una ventana promocional, y no mide software B2B.

El anuncio prueba que existe un camino estandarizado hasta el checkout. No prueba que el mercado compre por agente a escala.

¿Qué cambia cuando el producto es software y no una camiseta?

El inventario de software no es una estantería. Un plan por suscripción carga licencia, asiento, región de facturación, límite de uso, vigencia y condición de renovación, y cada elemento decide si el plan se puede vender a esa empresa, en ese país, por ese plazo.

Cuando un agente lee disponibilidad en un storefront de retail, lee cantidad. En tu caso la misma palabra cubre otra pregunta: ¿el plan del tier más alto se puede vender a una empresa en México, en dólares, con 400 asientos y renovación anual? La respuesta está en la política comercial, no en el inventario.

El fallo de lectura aparece rápido. El agente encuentra el precio público, arma el pedido, y el pedido llega a una entidad que no se puede facturar en esa moneda. Nadie se equivocó en el código. La página no decía lo que la empresa ya sabía.

La traducción del retail al B2B tiene un límite: el anuncio de Vercel trata de tiendas de producto físico. Leer licencia, asiento y vigencia como equivalentes de inventario es análisis de este texto, no un hecho de la fuente.

¿Qué necesitan encontrar los agentes compradores en tu superficie comercial?

Cinco respuestas, en el orden de la compra: cuál es la oferta, qué incluye, dónde y en qué volumen está disponible, qué opciones de plazo y tier existen, y dónde se cierra el pedido. En software, cada respuesta carga una condición comercial que el retail resuelve con un SKU.

La columna de la derecha es un requisito derivado. No es un recurso del protocolo.

En retail, el enlace de checkout es el final del camino. En software, abre una aprobación que vive en el comprador.

¿Cómo atiende la misma URL a la persona y al agente?

Una URL de producto sirve a los dos lectores: la persona ve la página con precio, disponibilidad y opciones, y el agente lee el mismo contenido en formato estructurado. Son dos contratos de lectura. Para un ISV, la página de plan deja de ser marketing y pasa a ser contrato de datos.

Un precio desactualizado no genera solo un lead confundido. Genera un pedido equivocado, con número y responsable.

El catálogo legible por máquina no nace de una página nueva. Nace de disciplina de actualización. Cambió el límite del plan, se abrió una región: el cambio llega al dato antes que al anuncio. La lectura ocurre en una capa intermedia, donde el registro de la consulta tiene que existir, como describe la capa que centraliza el acceso y el registro de los agentes.

La fuente no afirma que todo comerciante tenga que reescribir el sitio ni que la lectura por máquina sustituya la página visual.

¿Qué cambia en el checkout cuando quien compra es un agente?

En retail, carrito y enlace de checkout cierran la compra. En software B2B, el carrito carga intención y el cierre carga compromiso: vigencia, volumen, condición de pago y quién firma. El punto de diseño es dónde se detiene el enlace de checkout y dónde empieza la aprobación del comprador.

El UCP lleva el camino hasta el checkout y prevé escalamiento a una persona cuando la transacción sale de lo que el agente concluye. Una especificación que reserva ese estado ya dice que la automatización tiene un límite, y que el límite es parte del flujo.

El paso humano no desaparece, cambia de lugar: propuesta, revisión jurídica y firma se vuelven un pedido en espera de confirmación, y el esfuerzo aparece cuando alguien dice que sí.

Leer catálogo y cerrar pedido tienen radios de daño distintos, y tratarlos con la misma credencial y gasto por agente es el camino más corto a un pedido que nadie planeó pagar. En un servidor MCP que expone catálogo y checkout, la herramienta que consulta precio y la que cierra carrito deberían ser dos, con credencial y techo propios.

El protocolo no decide política comercial: precio ofertable, techo de compromiso, catálogo permitido, vigencia, excepciones y quién firma dentro del comprador. No firma eso.

¿Quién autoriza el pedido y qué queda registrado?

Dos decisiones, y son de la empresa, no del protocolo. La primera es la autoridad que recibe el agente: techo de valor, catálogo permitido, vigencia y excepciones. La segunda es lo que el vendedor registra para reconstruir la decisión después, cuando alguien pregunte el motivo.

La autoridad comercial se escribe en números y listas. Un agente que compromete hasta un techo por pedido, dentro de un catálogo nombrado, con vigencia de hasta doce meses y sin excepción para una región no homologada es un agente que un auditor describe. Un techo por pedido sin techo por período es un límite que el segundo pedido ya rompió.

El registro refleja eso. El vendedor necesita saber qué agente pidió, en nombre de qué empresa, con qué credencial, qué versión de precio se leyó y cuál se honró en el cierre, y con qué identificador de operación.

La discusión aquí es la autoridad comercial de quien vende y de quien compra, y el problema aparece cuando la credencial se comparte entre agentes, caso en el que la identidad del llamador separada de la credencial responde quién pidió. El control de acceso a la cuenta es otro tema.

Qué hacer en los próximos 90 días

Empezar por el inventario, no por la integración. La oferta que un ISV B2B mantiene en página, PDF y hoja de cálculo tiene que volverse un conjunto de campos verificables, y la autoridad de compra tiene que estar escrita, con techo y alcance, antes del primer pedido automático.

1. Inventariar la oferta repartida entre página, PDF y hoja de cálculo. El error que se evita es descubrir que el precio oficial y el practicado viven en archivos distintos.
2. Separar lo que es publicable como dato de lo que es negociación. Un descuento por volumen, publicado, crea un compromiso que nadie aprobó.
3. Definir techo por pedido, techo por período y alcance de autoridad antes de encender el checkout. Sin los tres, un fallo de configuración se vuelve un compromiso de presupuesto.
4. Decidir qué registrar antes del primer pedido. Agente, empresa, credencial, versión de precio y autorización son el mínimo de auditoría.
5. Probar la lectura con un agente real antes de anunciar soporte. Revela el campo que falta, el precio en dos monedas y la disponibilidad que vive en el CRM.

Ninguna de ellas promete retorno en un plazo.

Dónde entra Nexforce Agents en esta capa

El protocolo lleva al agente hasta el checkout; por defecto, el cierre queda con una persona en una interfaz confiable, con escalamiento explícito cuando el flujo exige aprobación humana. Lo que queda después del checkout es trabajo operativo, y no es del protocolo.

Nexforce Agents entra en ese trabajo: la unidad desarrolla e implementa agentes en operaciones B2B, con Nexforce Work y Nexforce Code, y la capa de aprobaciones y permisos en la que la empresa registra qué puede hacer cada agente.

Nexforce Work es un workspace de agente para equipos de negocio, con orquestación multi-workspace, ejecución en sandbox y conectores MCP. Nexforce Code es el runtime para desarrolladores, con ejecución headless para automatización y CI. Los dos atienden lo que la especificación deja abierto: el agente que consulta la superficie comercial y la capa de aprobaciones y permisos con la que la empresa limita lo que puede hacer.

La decisión sigue en la empresa.

En Nexforce Marketplace, la contratación de software es en BRL y con factura fiscal. Eso no define el alcance del agente, no autoriza la compra ni asume el pedido que armó.

Preguntas frecuentes

¿Qué es el UCP y qué cambia para quien vende software?

El Universal Commerce Protocol es una especificación publicada el 11 de enero de 2026, co-desarrollada por Shopify con Google, disponible en ucp.dev. Define un camino común para catálogo, carrito, checkout, vinculación de identidad y gestión de pedido. Para quien vende software, cambia el costo de ser leído: la oferta depende de plan, límite, región y vigencia publicados como dato.

¿Hay que reescribir el sitio para que un agente compre?

No. La misma URL que sirve a la página visual puede servir el contenido legible por máquina, con precio, disponibilidad y opciones. El trabajo no es reconstruir el sitio, es mantener el dato actualizado, y en software es más grande que el técnico: decidir qué campos son públicos, con qué frecuencia cambia cada uno y quién responde por cada uno.

¿Esto aplica a software B2B o solo al retail?

El camino estandarizado se anunció con tiendas de producto físico, y el caso divulgado es de una minorista. La estructura de lectura no es exclusiva del retail: el software también tiene catálogo y disponibilidad, aunque en software la disponibilidad sea licencia y región. Quien vende software traduce los campos, y esa traducción es una decisión de producto sobre qué entra en el catálogo.

¿Quién responde cuando un agente cierra un pedido equivocado?

La responsabilidad no cambia de dueño porque una máquina haya armado el pedido: la especificación mantiene al negocio como Merchant of Record, y la responsabilidad comercial es del vendedor frente al comprador, no un régimen jurídico del protocolo que reparta culpa entre agente, vendedor y comprador. El registro es lo que permite atribuir el pedido: agente, empresa, credencial, versión de precio leída y honrada, identificador de la operación.

Referencias

• Vercel, "Vercel and Shopify make agents first-class shoppers", 16 de octubre de 2026. https://vercel.com/blog/vercel-and-shopify-make-agents-first-class-shoppers (acceso el 2026-10-23)
• Universal Commerce Protocol, protocolo anunciado el 11 de enero de 2026; especificación consultada en la versión corriente (v2026-08-25). https://ucp.dev/latest/specification/overview/ (acceso el 2026-10-23)

La decisión que no se puede posponer

El protocolo ya existe. El catálogo legible todavía no. La pregunta que decide la inversión no es qué especificación adoptar, es quién firma el pedido que armó el agente.

Dos acciones, en este orden: exponer la oferta como dato verificable y definir la autoridad de compra antes de encender el checkout. Ningún dato público dice qué proporción de los ISV B2B ya publica una oferta que los agentes compradores leen, y quien espera el número llega después del primer error.