Os quatro artigos anteriores desta série falavam de leitura. Este fala de ação — um agente que reserva, compra, submete um formulário ou obtém um valor. Verifiquei em que ponto estão realmente as normas, e o quadro é nítido: o WebMCP é um rascunho de Community Group do W3C, está em origin trial no Chrome e no Edge, e a Apple apresentou uma objeção formal. O protocolo de comércio da OpenAI e da Stripe exige que o comerciante implemente cinco endpoints e está em beta — e o seu próprio site oficial diz que os mecanismos de descoberta ainda estão a ser construídos. O grupo de trabalho do IETF para a identidade dos agentes foi constituído, mas ainda não adotou um único documento. E no principal benchmark independente de execução de tarefas de escritório, o melhor resultado verificado concluiu 42,9% das tarefas.
As três camadas que têm todas de existir
Para que um agente conclua uma tarefa no seu site, três coisas têm de ser verdadeiras ao mesmo tempo: ele tem de saber o que lhe é permitido fazer, tem de ter uma interface através da qual o fazer, e o senhor tem de saber que é mesmo aquele agente e não alguém a fazer-se passar por ele. A tabela resume em que ponto está hoje cada camada.
| Camada | Mecanismo principal | Estado real |
|---|---|---|
| Declaração de capacidades | WebMCP | Rascunho de Community Group; origin trial no Chrome e no Edge; WebKit contra |
| Concluir uma compra | ACP da OpenAI e da Stripe | Beta; cinco endpoints do comerciante; sem mecanismo de descoberta |
| Autorização de pagamento | AP2 da Google | Versão 0.2; entregue à FIDO Alliance; não exige alterações ao site |
| De agente para agente | A2A | Versão 1.0.1; estável, mas resolve outro problema |
| Identidade do agente | Web Bot Auth | Grupo de trabalho constituído no IETF; nenhum documento adotado; a Cloudflare já implementou |
| Identificação de navegadores agênticos | — | Nenhum user-agent documentado para qualquer navegador agêntico |
WebMCP: em que ponto está realmente
O WebMCP é a ideia de que um site pode declarar, dentro da própria página, que ações oferece a um agente — em vez de o agente adivinhar onde clicar. É a abordagem certa, e é por isso que gera tantos títulos. Mas importa conhecer o seu estatuto formal.
O documento é publicado pelo W3C Web Machine Learning Community Group, e o seu cabeçalho declara explicitamente que não é uma norma do W3C e que não está na via de normalização. Os editores vêm da Microsoft e da Google. A versão do rascunho que li tem a data de 26 de agosto de 2026.
As implementações: o Chrome abriu um origin trial na versão 149, segundo um artigo do blogue para programadores publicado a 9 de junho de 2026. O Edge abriu um origin trial na versão 150, o Brave executa-o de forma experimental no Leo, e a aplicação de ambiente de trabalho do ChatGPT suporta-o. Do outro lado, o WebKit apresentou uma posição de oposição com uma lista de reservas que inclui a própria escolha do fórum de normalização, e a Mozilla apresentou uma posição neutra.
Dois erros que se repetem em todos os guias: a API não se chama navigator.modelContext — a palavra Navigator não aparece uma única vez no texto da especificação. E o Chrome não lançou isto na versão 146 em fevereiro de 2026; o blogue oficial fala de um origin trial na versão 149. Se um guia lhe disser o contrário, não leu a fonte.
Como isto se traduz em código
A API verdadeira é document.modelContext.registerTool. A ideia é simples: a página regista uma ferramenta com um nome, uma descrição, um esquema de entrada e uma função que a executa. O agente que percorre a página vê a ferramenta sem ter de adivinhar o que faz cada botão.
document.modelContext.registerTool({
name: “book_appointment”,
description: “Book an appointment on a given date”,
inputSchema: {
type: “object”,
properties: { date: { type: “string” } },
required: [“date”]
},
async execute({ date }) {
const result = await bookOnServer(date);
return { content: [{ type: “text”, text: result.confirmation }] };
}
});
O que importa aqui não é a sintaxe mas a implicação: a ação passa pelo seu código. É o senhor que decide o que fica exposto, que valida a entrada e que controla os efeitos secundários. É algo radicalmente diferente de um agente que tenta clicar na interface visual e esperar que resulte. Nesta fase, qualquer implementação deste tipo é uma experiência — não uma infraestrutura de produção.
Comércio agêntico: três protocolos, três problemas diferentes
É fácil confundir-se, porque os três nomes aparecem nos mesmos artigos, quando na verdade resolvem coisas completamente diferentes.
ACP — o Agentic Commerce Protocol, mantido pela OpenAI e pela Stripe, define-se a si próprio como estando em beta, sob licença Apache-2.0. A versão mais recente da especificação que vi tem a data de 17 de abril de 2026. Do ponto de vista de um comerciante o requisito é concreto: implementar cinco endpoints REST para gerir uma sessão de checkout — criar, atualizar, concluir, cancelar e obter — mais webhooks para eventos de encomenda. O site oficial diz que ainda estão a trabalhar na criação de mecanismos de descoberta que permitam às plataformas de IA identificar empresas. O que significa que mesmo que implemente tudo, hoje não há forma padrão de declarar que o fez — exatamente a lacuna que descrevi no artigo sobre a camada de descoberta.
AP2 — o Agent Payments Protocol da Google, na versão 0.2, anunciado em setembro de 2025 e desde então entregue à FIDO Alliance para prosseguir a normalização. Está construído como uma extensão do A2A e trata da autorização de pagamento: mandatos verificáveis que provam que o utilizador autorizou mesmo o agente a pagar. Não exige qualquer alteração ao HTML do seu site, pelo que não substitui o ACP mas é uma camada por baixo dele.
UCP — o Universal Commerce Protocol que, segundo um anúncio da Shopify datado de 24 de março de 2026, está a ser desenvolvido em conjunto com a Google e tem o apoio da Walmart, Target, Etsy, American Express, Mastercard, Stripe e Visa. Não abri a especificação em si, pelo que não vou citar uma versão.
Uma nota que evita desilusões: esse mesmo anúncio da Shopify descreve a sua integração com o ChatGPT como funcionando através de um navegador interno, e em computador redirecionando diretamente para a loja do comerciante. Por outras palavras, «comprar dentro do ChatGPT» não é necessariamente um checkout ACP nativo. E a documentação da OpenAI diz que o Instant Checkout está disponível para parceiros aprovados — não para qualquer comerciante.
O A2A resolve outro problema
O A2A chegou à versão 1.0.0 em março de 2026 e à versão 1.0.1 em maio de 2026, e é o protocolo mais maduro do grupo. Define um agent card — um documento JSON que descreve a identidade, as capacidades, as competências, o endpoint de serviço e os requisitos de autenticação de um servidor de agentes — e publica-o em /.well-known/agent-card.json. É também a única entrada do mundo dos agentes registada no registo da IANA.
E precisamente por isso vale a pena ser exato: o seu domínio é a comunicação entre sistemas de agentes independentes, não entre um site e um agente. Publicar este ficheiro num site institucional não faz nada, a menos que esteja mesmo a correr um servidor A2A por trás. Já vi bastantes recomendações que perdem esta distinção.
Como é que se identifica sequer um agente
Esta é a camada que mais falta, e a conclusão mais nítida desta pesquisa é negativa: não existe user-agent documentado para qualquer navegador agêntico. A página de bots da OpenAI lista OAI-SearchBot, OAI-AdsBot, GPTBot e ChatGPT-User — e não tem entrada para o ChatGPT Atlas. A página de bots da Anthropic lista ClaudeBot, Claude-User e Claude-SearchBot — e não tem entrada para o Claude in Chrome. Se vir nos seus registos uma cadeia que parece um navegador agêntico, ela não está documentada e pode mudar sem aviso.
A resposta que está a ganhar forma é o Web Bot Auth: uma assinatura criptográfica sobre o próprio pedido. Foi constituído no IETF um grupo de trabalho com esse nome, mas até hoje não adotou um único documento — todos os rascunhos relevantes continuam a ser submissões individuais. O rascunho do protocolo central foi atualizado a 19 de agosto de 2026.
A Cloudflare já implementou o mecanismo: um diretório de chaves em /.well-known/http-message-signatures-directory e os cabeçalhos Signature-Agent, Signature-Input e Signature no pedido. A sua documentação nota ainda que desde 1 de julho de 2026 existe um novo campo de metadados que distingue um agente direto de um intermediário, e que as categorias de comportamento incluem explicitamente transacionar em nome de um utilizador. Uma ressalva a conhecer: a Cloudflare implementa versões de rascunho anteriores à mais recente, pelo que nesta fase são de esperar desencontros entre implementações.
Até que ponto os agentes concluem realmente tarefas
Aqui quero dar um número real em vez de uma impressão. O benchmark independente mais sério que encontrei é o TheAgentCompany, desenvolvido entre outros na Carnegie Mellon University, composto por 175 tarefas que simulam o trabalho numa empresa de software. Os resultados da tabela estão marcados como verificados de forma independente.
- O melhor resultado da tabela: 42,9% das tarefas concluídas, uma entrada registada a 10 de novembro de 2025.
- O OpenHands-Versa com Claude Sonnet 4 concluiu 33,1%, em junho de 2025.
- O OpenHands com GPT-4o concluiu 8,6%, em dezembro de 2024.
Uma ressalva que tenho de declarar: a entrada mais recente da tabela é de novembro de 2025, e não contém modelos de fronteira de 2026. Portanto não apresente os 42,9% como «o estado da arte em 2026» mas como o melhor resultado verificado de forma independente neste benchmark. O que o número diz apesar disso, mesmo assumindo uma melhoria significativa, é que ainda não existe uma realidade em que se entregue a um agente uma tarefa complexa esperando que a termine.
O que fazer de facto hoje
A recomendação honesta é não correr a implementar rascunhos. A minha ordem de operações, baseada no que está documentado e é estável: primeiro garantir que o site é sequer legível — permissões corretas, conteúdo presente no HTML inicial, e páginas que possam ser citadas. Depois verificar que o seu bloqueio não está a deitar fora agentes legítimos que agem em nome de um utilizador: é um erro comum, e o único mecanismo de aprovação explícito que encontrei documentado é o da Cloudflare, que permite aos fornecedores de bots candidatarem-se e aos donos de sites ativarem definições por categoria.
E só então, se o seu modelo de negócio beneficiar mesmo disso, considere um piloto: um origin trial de WebMCP para uma ação bem definida, ou uma implementação de ACP se vende produtos e tem recursos de desenvolvimento. Em ambos os casos trate-o como uma experiência, porque é o que é.
A lacuna que continua aberta é exatamente aquela que descrevi ao longo de toda esta série: não existe forma padrão de um site declarar o que oferece a um agente. O ACP admite-o ele próprio, o MCP não o cobre e o A2A resolve outro problema. É por isso que estou a trabalhar na especificação AX. Mas enquanto não houver uma norma acordada, a minha recomendação não é inventar um caminho privado e esperar — mas construir o que já funciona.
Perguntas frequentes
Devo implementar o WebMCP no meu site hoje?
Apenas como experiência. O documento é um rascunho de Community Group do W3C, e declara explicitamente que não é uma norma e que não está na via de normalização. O Chrome e o Edge abriram origin trials, o WebKit apresentou oposição e a Mozilla uma posição neutra. Não é sobre isto que se constrói infraestrutura de produção.
Como se chama realmente a API do WebMCP?
document.modelContext.registerTool. O nome navigator.modelContext, que aparece em muitos guias, está errado — a palavra Navigator não aparece de todo no texto da especificação.
O que tenho exatamente de implementar para suportar o comércio agêntico da OpenAI?
Segundo a especificação do ACP, um comerciante precisa de implementar cinco endpoints REST para gerir uma sessão de checkout — criar, atualizar, concluir, cancelar e obter — mais webhooks para eventos de encomenda. O protocolo define-se como estando em beta, e o Instant Checkout está documentado como disponível para parceiros aprovados.
Devo publicar o agent-card.json no meu site?
Só se estiver mesmo a correr um servidor A2A. O cartão descreve a identidade, as capacidades, o endpoint de serviço e os requisitos de autenticação de um servidor de agentes, e o A2A trata da comunicação entre sistemas de agentes — não entre um site e um agente. Num site institucional o ficheiro não faz nada.
Como identifico tráfego de navegadores agênticos nos meus registos?
Até hoje, não há forma documentada. As páginas de bots da OpenAI e da Anthropic não contêm entrada para os seus navegadores agênticos. O mecanismo que está a ganhar forma é o Web Bot Auth, baseado na assinatura do pedido; foi constituído no IETF um grupo de trabalho sobre isso, mas ainda não adotou um documento, e a Cloudflare já implementou versões de rascunho.
Para continuar a ler
O protocolo AX: declarar a um agente o que o seu site sabe fazer – O passo seguinte, depois de um agente poder agir no seu site, é dizer-lhe o que está disponível. É exatamente a lacuna que hoje nenhum protocolo existente preenche.