Agentes compradores: o que seu software precisa expor?

Expor, para agentes compradores, não é abrir uma API do produto: é publicar a oferta na superfície comercial em formato que a máquina lê sem abrir o navegador. O caminho existe e tem endereço: o Universal Commerce Protocol, publicado em 11 de janeiro de 2026, com especificação em ucp.dev. O que continua em aberto é o conteúdo do caminho.

A Vercel publicou em 16 de outubro de 2026 as peças que tornam o caminho executável: o Vercel Shop em disponibilidade geral, um template open source de storefront em Next.js para Shopify e o Hydrogen SDK reconstruído, também em GA. Isso resolve a infraestrutura de quem vende produto físico, não o plano com vigência, o limite por assento nem a região da cobrança. Publicar a oferta como dado e decidir quem responde por um pedido montado por uma máquina continua sendo trabalho do vendedor de software.

O que mudou em 16 de outubro de 2026?

Em 16 de outubro de 2026 a Vercel colocou o Vercel Shop em disponibilidade geral e o Hydrogen SDK reconstruído em GA. O Vercel Shop torna as capacidades do UCP descobríveis no domínio do lojista, de onde um agente comprador lê.

O UCP foi publicado em 11 de janeiro de 2026, co-desenvolvido pela Shopify com o Google, com especificação em ucp.dev. Ele cobre cinco capacidades: Catalog, Cart, Checkout, Identity Linking e Order Management. A vinculação de conta usa OAuth 2.0. O fechamento autônomo depende da extensão de mandatos do AP2; sem ela, a especificação manda finalizar o checkout numa interface confiável, com o comprador presente. O estado requires_escalation, com continue_url obrigatório, devolve a transação a uma pessoa quando falta dado ou falta autorização. Os perfis ficam em /.well-known/ucp, no domínio do lojista.

O UCP muda o custo de integração por par. Um agente comprador que fala UCP não precisa de conector sob medida para cada loja. O UCP define as capacidades de catálogo, carrinho e checkout e assenta a especificação em transporte REST e JSON-RPC, com suporte embutido a AP2, A2A e MCP. MCP para e-commerce é a camada da chamada de ferramenta: o agente chama uma ferramenta, que fala UCP, sem navegar pelo site.

O anúncio cita AG1, Bombas e PAIGE como usuárias do stack. A PAIGE, varejista, registrou +22% de receita e +76% de conversão entre Black Friday e Cyber Monday, sem downtime, no case publicado pela Vercel. É dado de varejo, do fornecedor, numa janela de promoção, e não mede software B2B.

O anúncio prova que existe caminho padronizado até o checkout. Não prova que o mercado compra por agente em escala.

O que muda quando o produto é software, não uma camiseta?

Estoque de software não é prateleira. Um plano por assinatura carrega licença, assento, região de cobrança, limite de uso, vigência e condição de renovação, e cada item decide se o plano pode ser vendido para aquela empresa, naquele país, por aquele prazo.

Quando um agente lê disponibilidade num storefront de varejo, ele lê quantidade. No seu caso, a mesma palavra cobre outra pergunta: o plano de maior tier pode ser vendido para uma empresa no México, em dólar, com 400 assentos e renovação anual? A resposta está na política comercial, não no estoque.

A falha de leitura aparece rápido. O agente acha o preço público, monta o pedido, e o pedido chega em uma entidade que não pode ser faturada naquela moeda. Ninguém errou no código. A página não dizia o que a empresa já sabia.

A tradução de varejo para B2B tem limite: o anúncio da Vercel trata de lojas de produto físico. Ler licença, assento e vigência como equivalentes de estoque é análise desta peça, não fato da fonte.

O que os agentes compradores precisam encontrar na sua superfície comercial?

Cinco respostas, na ordem da compra: qual é a oferta, o que está incluso, onde e em que volume está disponível, quais opções de prazo e tier existem, e onde o pedido fecha. Em software, cada resposta carrega uma condição comercial que o varejo resolve com um SKU.

A coluna da direita é requisito derivado. Não é recurso do protocolo.

No varejo, o link de checkout é o fim do caminho. Em software, ele abre uma aprovação que mora no comprador.

Como a mesma URL atende a pessoa e o agente?

Uma URL de produto serve os dois leitores: a pessoa vê a página com preço, disponibilidade e opções, e o agente lê o mesmo conteúdo em formato estruturado. São dois contratos de leitura. Para um ISV, a página de plano deixa de ser marketing e passa a ser contrato de dados.

Um preço desatualizado não gera só um lead confuso. Gera um pedido errado, com número e responsável.

O catálogo legível por máquina não nasce de página nova. Nasce de disciplina de atualização. Mudou o limite do plano, abriu uma região: a alteração chega ao dado antes do anúncio. A leitura acontece em uma camada intermediária, onde o registro da consulta precisa existir, como descreve a camada que centraliza acesso e registro dos agentes.

A fonte não afirma que todo lojista precise reescrever o site nem que a leitura por máquina substitua a página visual.

O que muda no checkout quando quem compra é um agente?

No varejo, carrinho e link de checkout encerram a compra. Em software B2B, o carrinho carrega intenção e o fechamento carrega compromisso: vigência, volume, condição de pagamento e quem assina. O ponto de projeto é onde o link de checkout para e onde começa a aprovação do comprador.

O UCP leva o caminho até o checkout e prevê escalonamento para uma pessoa quando a transação sai do que o agente conclui. Uma especificação que reserva esse estado já diz que a automação tem limite, e que o limite faz parte do fluxo.

A etapa humana não desaparece, ela muda de lugar: proposta, revisão jurídica e assinatura viram um pedido à espera de confirmação, e o esforço aparece quando alguém diz sim.

Ler catálogo e fechar pedido têm raios de dano diferentes, e tratá-los com a mesma credencial e gasto por agente é o caminho mais curto para um pedido que ninguém planejou pagar. Num servidor MCP que expõe catálogo e checkout, a ferramenta que consulta preço e a que fecha carrinho deveriam ser duas, com credencial e teto próprios.

O protocolo não decide política comercial: preço ofertável, teto de compromisso, catálogo permitido, vigência, exceções e quem assina dentro do comprador. Ele não assina isso.

Quem autoriza o pedido e o que fica registrado?

Duas decisões, e elas são da empresa, não do protocolo. A primeira é a autoridade que o agente recebe: teto de valor, catálogo permitido, vigência e exceções. A segunda é o que o vendedor registra para reconstruir a decisão depois, quando alguém perguntar o motivo.

Autoridade comercial se escreve em números e listas. Um agente que compromete até um teto por pedido, dentro de um catálogo nomeado, com vigência de até doze meses e sem exceção para região não homologada é um agente que um auditor descreve. Teto por pedido sem teto por período é um limite que o segundo pedido já furou.

O registro espelha isso. O vendedor precisa saber qual agente pediu, em nome de qual empresa, com qual credencial, qual versão de preço foi lida e qual foi honrada no fechamento, e com qual identificador de operação.

A discussão aqui é autoridade comercial de quem vende e de quem compra, e o problema aparece quando a credencial é compartilhada entre agentes, caso em que a identidade do chamador separada da credencial responde quem pediu. Controle de acesso a conta é outra pauta.

O que fazer nos próximos 90 dias

Começar pelo inventário, não pela integração. A oferta que um ISV B2B mantém em página, PDF e planilha precisa virar um conjunto de campos conferíveis, e a autoridade de compra precisa estar escrita, com teto e escopo, antes do primeiro pedido automático.

1. Inventariar a oferta espalhada em página, PDF e planilha. O erro evitado é descobrir que o preço oficial e o praticado moram em arquivos diferentes.
2. Separar o que é publicável como dado do que é negociação. Desconto por volume, publicado, cria compromisso que ninguém aprovou.
3. Definir teto por pedido, teto por período e escopo de autoridade antes de ligar o checkout. Sem os três, uma falha de configuração vira compromisso de orçamento.
4. Decidir o que registrar antes do primeiro pedido. Agente, empresa, credencial, versão de preço e autorização são o mínimo de auditoria.
5. Testar a leitura com um agente real antes de anunciar suporte. Ele revela o campo que falta, o preço em duas moedas e a disponibilidade que mora no CRM.

Nenhuma delas promete retorno em prazo.

Onde o Nexforce Agents entra nessa camada

O protocolo leva o agente ao checkout; por padrão, a finalização fica com uma pessoa em interface confiável, com escalonamento explícito quando o fluxo exige aprovação humana. O que resta depois do checkout é trabalho operacional, e ele não é do protocolo.

O Nexforce Agents entra nesse trabalho: a unidade desenvolve e implementa agentes em operações B2B, com Nexforce Work e Nexforce Code, e a camada de aprovações e permissões em que a empresa registra o que cada agente pode fazer.

O Nexforce Work é um workspace de agente para times de negócio, com orquestração multi-workspace, execução em sandbox e conectores MCP. O Nexforce Code é o runtime para desenvolvedores, com execução headless para automação e CI. Os dois endereçam o que a especificação deixa em aberto: o agente que consulta a superfície comercial e a camada de aprovações e permissões com que a empresa limita o que ele pode fazer.

A decisão continua na empresa.

No Nexforce Marketplace, a contratação de software é em BRL e com nota fiscal. Isso não define o escopo do agente, não autoriza a compra nem assume o pedido que ele montou.

Perguntas frequentes

O que é o UCP e o que ele muda para quem vende software?

O Universal Commerce Protocol é uma especificação publicada em 11 de janeiro de 2026, co-desenvolvida pela Shopify com o Google, disponível em ucp.dev. Ele define um caminho comum para catálogo, carrinho, checkout, vinculação de identidade e gestão de pedido. Para quem vende software, muda o custo de ser lido: a oferta depende de plano, limite, região e vigência publicados como dado.

É preciso reescrever o site para um agente comprar?

Não. A mesma URL que serve a página visual pode servir o conteúdo legível por máquina, com preço, disponibilidade e opções. O trabalho não é reconstruir o site, é manter o dado atualizado, e em software ele é maior do que o técnico: decidir quais campos são públicos, com que frequência cada um muda e quem responde por cada um.

Isso vale para software B2B ou só para varejo?

O caminho padronizado foi anunciado com lojas de produto físico, e o case divulgado é de uma varejista. A estrutura de leitura não é exclusiva de varejo: software também tem catálogo e disponibilidade, ainda que no software a disponibilidade seja licença e região. Quem vende software traduz os campos, e essa tradução é decisão de produto sobre o que entra no catálogo.

Quem responde quando um agente fecha um pedido errado?

A responsabilidade não muda de dono porque o pedido foi montado por uma máquina: a especificação mantém o negócio como Merchant of Record, e a responsabilidade comercial é do vendedor perante o comprador, não um regime jurídico do protocolo que reparta culpa entre agente, vendedor e comprador. O registro é o que permite atribuir o pedido: agente, empresa, credencial, versão de preço lida e honrada, identificador da operação.

Referências

• Vercel, "Vercel and Shopify make agents first-class shoppers", 16 de outubro de 2026. https://vercel.com/blog/vercel-and-shopify-make-agents-first-class-shoppers (acesso em 2026-10-23)
• Universal Commerce Protocol, protocolo anunciado em 11 de janeiro de 2026; especificação consultada na versão corrente (v2026-08-25). https://ucp.dev/latest/specification/overview/ (acesso em 2026-10-23)

A decisão que não dá para adiar

O protocolo já existe. O catálogo legível ainda não. A pergunta que decide o investimento não é qual especificação adotar, é quem assina o pedido que o agente montou.

Duas ações, nesta ordem: expor a oferta como dado conferível e definir a autoridade de compra antes de ligar o checkout. Nenhum dado público diz qual parcela dos ISVs B2B já publica oferta que agentes compradores leem, e quem espera o número chega depois do primeiro erro.