Comércio agêntico (agentic commerce) além do checkout

O que é comércio agêntico?

Comércio agêntico é a compra em que um agente de IA executa as etapas que a pessoa faria, de achar e comparar o item a montar o carrinho, preencher os dados e pagar. O termo em inglês, agentic commerce, virou nome de produto e de protocolo em 2025 e 2026, e cada empresa recortou um pedaço diferente do caminho. Para quem trabalha com SEO e GEO, a pergunta útil é o que o site precisa deixar legível e chamável para entrar nessa compra.

A definição de agente de IA no glossário da agência cobre o conceito geral. Aqui o recorte é técnico. Separo o comércio agêntico em três camadas, porque cada protocolo cuida de uma delas.

• Descoberta: o agente acha a oferta em catálogo, feed ou página, e decide se ela atende ao pedido;
• Checkout: o agente monta o carrinho e fecha o pedido com o lojista, com identidade e status do pedido;
• Pagamento: o agente prova que a pessoa autorizou aquela compra, com aquele valor, sem expor o cartão.

UCP ACP e AP2 lado a lado

Três protocolos abertos dividem o comércio agêntico em novembro de 2026, e cada um pega um pedaço diferente das três camadas.

O UCP é o mais amplo. O repositório oficial lista como capacidades iniciais checkout, vinculação de identidade por OAuth 2.0, pedido com webhooks e troca de token de pagamento, e o site do protocolo já põe busca no catálogo e montagem de carrinho na especificação. A última versão publicada é a 2026-08-25. O UCP declara compatibilidade com o AP2 como camada de confiança do pagamento.

O AP2 trata só do pagamento. O anúncio de 2025 descrevia mandatos como contratos digitais assinados por credenciais verificáveis, com mandato de intenção e mandato de carrinho. A especificação na versão 0.2 define dois tipos, o mandato de checkout e o mandato de pagamento, e acrescentou pagamento com o humano ausente. O anúncio diz que o AP2 pode ser usado como extensão do A2A e do MCP.

O ACP nasceu com o Instant Checkout do ChatGPT. Em 24 de março de 2026, a OpenAI escreveu que a primeira versão do Instant Checkout não deu a flexibilidade que ela queria. Desde então, o lojista pode usar o próprio checkout, e o foco da OpenAI passou para a descoberta de produto. A diretriz de plugins da OpenAI descreve o Instant Checkout hoje como beta, restrito a parceiros de marketplace selecionados.

UCP, ACP e AP2 padronizam a compra de item com preço e, nas especificações lidas em novembro de 2026, não têm capacidade publicada de pedido de orçamento nem de agendamento.

Lucas Ferraz, especialista em SEO

O que o lojista expõe em cada protocolo?

No UCP, o lojista publica um perfil JSON em /.well-known/ucp com a versão, os serviços e os transportes que aceita. A especificação mostra o mesmo serviço de compras oferecido em REST, MCP e A2A, cada um com endpoint e esquema próprios. O trecho abaixo reduz o exemplo oficial.

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [
        { "transport": "rest", "endpoint": "https://business.example.com/ucp/v1" },
        { "transport": "mcp",  "endpoint": "https://business.example.com/ucp/mcp" }
      ]
    }
  }
}

O primeiro passo do fluxo, na especificação, é o agente buscar esse perfil. O desenho é o mesmo do card de servidor MCP e do catálogo de API em /.well-known/, que descrevi no post sobre MCP para sites, em que um endereço fixo diz ao robô o que existe e por onde chamar.

No ACP, o lojista envia um feed de produtos à OpenAI, com nove campos obrigatórios por item ou variante, que são item_id, title, description, url, brand, seller_name, image_url, availability e price. O feed vai por SFTP, com um retrato completo pelo menos uma vez por dia, e a entrada está aberta só para parceiros aprovados. O checkout exige uma integração habilitada à parte.

No Google, a base continua sendo o dado estruturado de oferta. A documentação de merchant listing pede name, image e offers no Product, e price e priceCurrency no Offer, com availability, priceValidUntil, shippingDetails e hasMerchantReturnPolicy entre os recomendados. O anúncio do UCP acrescentou dezenas de atributos novos no Merchant Center para comércio conversacional.

O ponto comum aos três é preço legível por máquina. Agente não negocia com um "consulte". Quando o preço só existe na cabeça do vendedor ou atrás de um formulário, a oferta sai da comparação.

Onde fica o serviço vendido por orçamento?

O serviço vendido por orçamento fica fora dos três protocolos abertos. O roadmap do UCP lista como próximas verticais alimentação e hospedagem, e as especificações de ACP e AP2 que li tratam de item com preço. Clínicas, escritórios, marcenarias e prestadores de reforma, que fecham venda depois de uma conversa, não têm hoje um contrato aberto para receber o pedido de um agente.

Dois mecanismos chegam perto, e os dois são recursos fechados de plataforma.

• Get Quote da OpenAI: a especificação de conversão para serviços locais, em beta com parceiros aprovados, mostra um botão Get Quote no cartão do negócio dentro do ChatGPT. O parceiro registra uma ferramenta MCP chamada request_service, que abre o formulário de orçamento em um modal, e envia um feed de negócios com nome, endereço, coordenadas, telefone e site, mais um registro de prestador com action_type igual a request_a_quote;
• Ligações automáticas do Google: a ajuda do Perfil da Empresa descreve o Google telefonando ao negócio a pedido de um cliente, com três usos, que são marcar horário, conferir preço e checar se produto ou serviço está disponível, sem custo para o negócio. Quando o negócio já informou o dado ao Google, o cliente recebe por e-mail ou SMS o orçamento do serviço. O recurso está em regiões e idiomas selecionados, com os Estados Unidos como mercado descrito, e o negócio pode desligar as ligações no Perfil da Empresa verificado.

As duas plataformas partem do mesmo dado de serviço. A ajuda do Google diz que ele não liga para perguntar estoque quando o dado já está no Merchant Center, o que mostra a ligação como remendo para o dado que o negócio não publicou. O que um prestador tem como alavanca técnica hoje é a parte que já é aberta, com faixa de preço de partida publicada no HTML, área atendida, prazo e um pedido de orçamento que um agente consiga acionar.

Como marcar um serviço sem preço fixo?

Um serviço sem preço fixo se marca no schema.org com Service e um Offer que carrega uma faixa de preço, em vez de um valor único. O priceSpecification aceita PriceSpecification com minPrice, que o vocabulário define como o menor preço quando o preço é uma faixa, e o areaServed diz onde o serviço é prestado. A documentação de merchant listing do Google trata de produto, então essa marcação serve à leitura por agente e por modelo, sem resultado enriquecido prometido.

{
  "@type": "Service",
  "name": "Projeto de móveis planejados",
  "areaServed": { "@type": "City", "name": "Belo Horizonte" },
  "offers": {
    "@type": "Offer",
    "priceSpecification": {
      "@type": "PriceSpecification",
      "minPrice": 4500,
      "priceCurrency": "BRL"
    }
  }
}

O número do exemplo é ilustrativo. O que conta é o mesmo valor aparecer no texto visível da página, porque o agente que lê o HTML e o que lê o JSON-LD precisam chegar à mesma faixa.

A ação de pedir orçamento pode ser uma ferramenta WebMCP sobre o formulário de orçamento, que o agente dentro do navegador chama com os campos preenchidos. Para a leitura, a versão em Markdown para agentes de IA entrega a página sem menu nem script, com o preço de partida no texto.

Content Signals e a permissão de uso

A Content Signals Policy da Cloudflare, publicada em 24 de setembro de 2025, acrescenta ao robots.txt uma linha que separa três usos do conteúdo, que são search, ai-input e ai-train. O search cobre índice e resultado de busca e, pelo texto da política, não inclui resumo gerado por IA. O ai-input cobre RAG, grounding e outro uso em tempo real para respostas de busca generativa. O ai-train cobre treino e ajuste fino de modelo.

Na minha leitura, para comércio agêntico o sinal que conta é o ai-input, porque é ele que trata do agente lendo a página na hora de recomendar ou comparar. A política diz que os sinais expressam preferência e não são contramedida técnica, e que a ausência do sinal não concede nem restringe permissão. No lucasferraz.com, o robots.txt traz Content-Signal: search=yes, ai-input=yes, ai-train=yes em cada um dos 20 grupos, porque o robô com grupo próprio ignora o grupo *. Conferi o arquivo ao vivo em 1º de novembro de 2026.

O que dá para preparar em um site brasileiro em 2026?

Em um site brasileiro, o preparo para comércio agêntico em 2026 é o que já vale para leitura por agente, com atenção ao preço. Nenhuma página oficial que li lista o Brasil no checkout por UCP, no Get Quote ou nas ligações automáticas. A ordem que sigo está abaixo.

• Preço legível: Product com Offer completo para quem vende item, e faixa de preço de partida em texto para quem vende por orçamento;
• Feed com o mesmo dado da página: Merchant Center atualizado, para o preço do feed não divergir do preço do HTML;
• Ação chamável: o formulário de orçamento exposto como ferramenta, com campos nomeados e resposta que o agente consiga ler;
• Permissão declarada: ai-input coerente com o que o negócio quer, já que o agente que compara depende dele;
• Perfil da Empresa revisado: os dados de serviço e a configuração das ligações automáticas, para quando o recurso chegar ao país.

O /.well-known/ucp fica para quando o lojista tiver um checkout que um agente possa usar e o Google abrir o mercado. Publicar o perfil antes disso anuncia uma capacidade que o site não tem.