Comércio agêntico chegou: o que muda para quem trabalha com e-commerce

Dois protocolos abertos já definem como um agente compra em nome de uma pessoa, e eles estão sob custódias diferentes. A disputa de padrão continua aberta, e a decisão de arquitetura começa agora.

A conversa sobre agentes que compram sozinhos saiu do terreno da especulação no momento em que grandes empresas publicaram especificações abertas para resolver o problema mais difícil dessa cadeia, que é a autorização do pagamento.

A especificação define uma API de checkout e um fluxo de pagamento delegado em formato OpenAPI, além de modelos de dados para feed, carrinho e pedidos, autenticação e integração com MCP. Vale reparar no que essa lista implica para quem opera loja: o feed e o carrinho, até aqui tratados como formato de exportação, viram contrato público, com esquema versionado e quebra declarada.

O anúncio saiu com mais de 60 organizações parceiras, entre elas American Express, Mastercard, PayPal, Adyen, Worldpay, Etsy e Salesforce. A composição dessa lista diz mais que o número: ela junta bandeiras, adquirentes, carteiras e lojistas, que são exatamente as partes que precisam concordar para que uma autorização de pagamento tenha validade na ponta.

O que os dois protocolos de comércio agêntico têm em comum

Ambos partem do mesmo diagnóstico. Um agente que preenche formulário imitando uma pessoa não resolve a questão da responsabilidade, porque ninguém consegue provar depois o que foi autorizado. A resposta dos dois é tornar explícito o contrato entre pessoa, agente e loja, com registro verificável.

A diferença que pesa está em quem guarda a especificação. O ACP é mantido pelas duas empresas que também operam o assistente e a camada de pagamento onde ele roda. O AP2 saiu das mãos do Google e passou a uma fundação de indústria. Para quem decide arquitetura, o que muda é sobretudo a expectativa de estabilidade e de captura da especificação ao longo dos anos, com pouco efeito sobre o código.

A consequência para quem opera loja é direta. O catálogo, além de conteúdo de página, vira interface de transação, com contrato de dados que precisa estar correto, atualizado e disponível em formato que o agente consome.

Por que a autorização é o problema difícil desta cadeia

A parte tecnicamente simples dessa cadeia é fazer um agente preencher um formulário. Isso já funciona, de forma frágil, desde que existem robôs de navegação. O que nunca funcionou é provar depois o que a pessoa autorizou.

O sistema de pagamento atual parte de uma premissa que os dois protocolos precisam substituir: a de que alguém clicou em comprar numa tela confiável. Essa premissa é o que sustenta a regra de responsabilidade em caso de contestação. Quando um agente inicia a transação, some o clique e some a tela, e com eles a prova.

Por isso os dois desenhos giram em torno de registro assinado, com a interface em segundo plano. O mandato existe para reconstruir, meses depois, o que foi pedido e o que foi aprovado. Para quem opera loja, a consequência é que a conformidade passa a ser uma questão de integridade de dado no catálogo.

O que fazer no e-commerce agora, com padrão indefinido

Enquanto os dois protocolos disputam adoção, dá para trabalhar no que vale nos dois. As quatro frentes abaixo independem de qual padrão vencer, porque todas tratam da qualidade do dado que qualquer agente vai consumir.

• Qualidade de dado de produto. Preço, disponibilidade, variação, prazo e política de devolução precisam ser verdadeiros em tempo real na fonte que alimenta qualquer canal. Loja com catálogo desatualizado quebra em qualquer protocolo.
• Feed como cidadão de primeira classe. O feed sai do território de mídia paga e vira infraestrutura de descoberta e de transação.
• Regras de negócio explícitas. Frete, restrição regional, limite por pedido e política de cancelamento precisam estar documentados de forma legível por máquina.
• Decisão de exposição. Definir quais categorias e quais faixas de preço a empresa aceita transacionar por agente, antes que a pergunta chegue do jurídico.

Nenhuma das quatro é aposta em protocolo. São condições de base que a loja precisaria ter de qualquer forma, e que ficam bem mais caras de arrumar depois que a integração já está em produção.

O que muda para loja em plataforma e para prevenção de fraude

Para quem opera loja em plataforma, como VTEX, Shopify, Nuvemshop ou WooCommerce, a integração com qualquer um dos dois protocolos tende a chegar pela própria plataforma e pelo processador de pagamento, e o trabalho da loja fica concentrado nas quatro frentes acima. Vale perguntar ao fornecedor, por escrito, qual protocolo está no roteiro e com qual prazo, porque essa resposta define quando a decisão de exposição deixa de ser teórica.

No Brasil, a pergunta sobre Pix precisa entrar na conversa com o processador. Um mandato assinado tem de conversar com as regras de autorização e de contestação do pagamento instantâneo, e essa integração é o ponto a confirmar antes de qualquer piloto.

A prevenção de fraude muda de lugar pelo mesmo motivo. Com um agente no meio, o comportamento de quem navega na tela some como sinal, e o mandato assinado vira a evidência principal em caso de contestação. Guardar esses registros com a mesma disciplina aplicada hoje a nota fiscal e a comprovante de entrega faz parte da preparação. O que já existe hoje para identificar e filtrar bots e agentes de IA na entrada do site está no guia de bots de IA.

Onde entra o SEO no comércio agêntico

A pergunta que estrutura o trabalho muda de forma. Além de descobrir se a página aparece para a busca, passa a valer descobrir se a oferta é compreensível e transacionável por um agente. Marcação estruturada, consistência entre canais e clareza de política viram requisito de operação. Do lado do site, o WebMCP é a proposta que leva essa lógica para a própria página, com ações expostas como ferramentas que um agente consegue chamar.