30 Dias de Agentes de IA Comprando em uma Loja WooCommerce Real: O Que os Dados Dizem
Na semana passada @benjifisher publicou um artigo perspicaz sobre o meio bagunçado do comércio agente — a camada de confiança, verificação e responsabilidade entre "encontrou" e "comprou". Sua conclusão: o meio está em grande parte não construído.
Temos 30 dias de dados de produção que dizem o contrário. Não é uma demonstração. Não é um sandbox. Uma loja de perfumes holandesa ao vivo com 40.000 SKUs, preços reais, impostos reais, débitos reais na carteira. Aqui está o que realmente aconteceu.
Os números
- €1.269 em receita impulsionada por IA — últimos 30 dias
- 39 pedidos concluídos via agentes de IA
- €32,54 valor médio do pedido por transação de IA
- 76,5% de conversão de sessão — 39 de 51 sessões de agentes resultaram em um pedido concluído
- 1,5 chamadas médias por sessão — o benchmark de especificação é 4 (listar → criar → atualizar → concluir)
Esse último número é o que eu quero focar.
1,5 chamadas por sessão significa que os agentes estão pulando etapas
O benchmark otimizado da especificação UCP é de 4 chamadas de ferramentas para uma compra completa: listar produtos, criar checkout, atualizar checkout, concluir checkout. Nossos agentes estão com uma média de 1,5.
Isso não significa que os agentes estão falhando — são agentes que já fizeram a descoberta em uma sessão anterior, chegando com intenção e indo direto para o checkout. A camada de instruções /agents.md que enviamos há duas semanas está funcionando: os agentes estão lendo o manual de operação na primeira visita e não o relendo em cada transação subsequente.
O meio bagunçado não parece bagunçado quando o protocolo é limpo e as instruções são explícitas.
Quem está realmente comprando
Oito agentes distintos acessaram a loja em 30 dias. Aqui está o que a tabela de agentes mostra:
| Agente | Sessões | Chamadas Médias | Status |
|---|---|---|---|
| Verificador de Diretório UCP | 19 | 1 | Apenas descoberta |
| Agente Desconhecido | 13 | 2,2 | Transacionando de forma eficiente |
| Verificador UCP | 8 | 1,4 | Validação + transação leve |
| UCPReady MCP | 5 | 1,2 | Teste interno |
| UCP Playground | 2 | 5 | +1 acima do benchmark |
| Claude | 2 | 1 | Limpo |
| Ucptools.dev | 1 | 2 | Dentro da meta |
| Bot Genérico | 1 | 1 | Dentro da meta |
A linha mais interessante é a do Agente Desconhecido — 13 sessões, 2,2 chamadas médias, na meta ou abaixo dela. Um agente que não conseguimos identificar pelo nome está transacionando contra a loja de forma eficiente e repetida. Ele encontrou o manifesto /.well-known/ucp, analisou as declarações de capacidade e está completando compras sem nenhum trabalho de integração do nosso lado.
Isso é o protocolo funcionando exatamente como projetado.
O UCP Playground é o único agente acima do benchmark com 5 chamadas — esse é o ambiente de teste do Ben executando sessões de validação completas de ponta a ponta, incluindo o fluxo de vinculação de identidade. Ruído esperado, não um problema.
Como era realmente o meio bagunçado
Construir até este ponto não foi limpo. A primeira compra totalmente autônoma — pedido WooCommerce #82251 em 25 de março — levou 24 horas de depuração entre duas pessoas. As falhas foram específicas:
Formatação da chave de idempotência. Claude continuava enviando meta como um objeto JSON stringificado em vez de um objeto aninhado adequado. Corrigido no nível do orquestrador, injetando automaticamente a forma da chave.
ID do instrumento da carteira vs nome do manipulador. O validador da loja aceitava com.terrawallet.store_credit (o nome do manipulador) mas rejeitava terrawallet-1 (o ID do instrumento). Dois identificadores diferentes, um caminho de pesquisa, um modo de falha silenciosa.
Sessões OAuth obsoletas. A revogação de token do lado do comerciante não estava sendo detectada. Os agentes estavam segurando tokens Bearer expirados e recebendo 401s sem um caminho claro de recuperação. Corrigido adicionando validação de token na conexão e limpando automaticamente em 401.
Substituição do endpoint MCP. Nossa sonda de loja Shopify estava substituindo o endpoint do manifesto. Tokens OAuth estavam armazenados contra /api/mcp mas chamadas MCP estavam indo para /wp-json/ucpready/v1/mcp. Um desajuste de endpoint, zero conclusões bem-sucedidas até ser encontrado.
Cada uma dessas foi uma falha real que bloqueou compras reais. O protocolo não as escondeu — os dados da sessão capturaram cada uma. A observabilidade é o que as tornou corrigíveis.
O que 76,5% de conversão significa em contexto
A conversão de checkout humano no e-commerce média 2-4%. O mobile é mais baixo. Mesmo lojas de alto desempenho raramente excedem 5% em tráfego frio.
76,5% não é comparável à conversão de checkout humano — as sessões de agentes são intencionais por definição, não navegação. Mas isso te diz algo sobre a fricção. Um agente que chega a create_checkout em um endpoint UCP bem implementado completa a compra 76,5% das vezes. As falhas são principalmente sessões de descoberta (Verificador de Diretório UCP, Verificador UCP) que nunca tiveram a intenção de comprar.
Se você remover as sessões de descoberta pura, a taxa de conclusão é maior.
O imposto de prontidão do pequeno varejista — revisitado
Paul do Forno, da Deloitte, postou na semana passada que pequenos varejistas enfrentam um "imposto de prontidão agente oculto" — dados de catálogo perfeitos como pré-requisito, acesso profundo ao sistema criando risco de vazamento de dados.
Os dados acima são de um pequeno varejista holandês. Não é uma plataforma. Não é uma empresa. Uma loja WooCommerce. O imposto é real — levou meses de desenvolvimento para chegar aqui — mas o resultado são 39 pedidos impulsionados por IA e €1.269 em receita em 30 dias que não existiriam de outra forma.
O imposto de prontidão é um custo único. A receita é recorrente.
O que vem a seguir
As 13 sessões do Agente Desconhecido são o ponto de dados mais interessante que temos agora. Um agente não identificado encontrou esta loja, analisou o protocolo e está transacionando repetidamente. Não sabemos de onde veio. Esse é o efeito de rede de um protocolo aberto — você não precisa estar listado em nenhum lugar específico. Você publica um manifesto /.well-known/ucp conforme o padrão e os agentes te encontram.
O próximo marco é identificar esse agente e entender seu escopo de mandato. Se ele estiver executando compras autônomas AP2 sem uma etapa de confirmação explícita do comprador, a trilha de auditoria é a única coisa que separa "funcionou" de "comprou a coisa errada". Essa é a camada de observabilidade sobre a qual Ben está certo — não uma necessidade teórica, uma exigência operacional ao vivo.
O meio não está inacabado. Está cedo, é bagunçado para acertar e gera receita real quando você faz isso.
UCPReady é o plugin WooCommerce por trás desses dados. O painel de análise de Agentes de IA é um recurso Pro. houseofparfum.nl é a loja de referência ao vivo — o manifesto está em houseofparfum.nl/.well-known/ucp.
Se você quiser ver onde sua loja WooCommerce está: ucpchecker.com
Este estudo de caso demonstra o potencial dos agentes de IA para impulsionar vendas em e-commerce, especialmente para pequenas empresas. A análise dos dados revela a importância de protocolos claros e a capacidade de observação para resolver falhas. Isso pode inspirar outras empresas brasileiras a adotarem tecnologias semelhantes.
