Depois de conversar com André Cipriani Bandarra no Google I/O Connect em Berlim, ficou claro que o WebMCP era apenas uma peça de algo maior. Uma semana depois, retomamos o assunto em uma entrevista sobre a Web Agêntica.

André trabalha com Developer Relations no Google e acompanha a evolução do Chrome há mais de uma década. Nesse período, viu conceitos como design responsivo e PWA deixarem de ser novidades. Com o tempo, eles viraram parte do trabalho cotidiano na web.

A Web Agêntica pode seguir um caminho parecido. Hoje, ainda discutimos nomes, padrões e limites. Porém, em algum momento, preparar sites para agentes talvez seja tão comum quanto criar uma interface responsiva.

Neste post, você vai entender como esses agentes descobrem, interpretam e usam um site. Além disso, verá o que já pode melhorar agora, sem reconstruir seu projeto em torno de uma tecnologia experimental.

O que é a Web Agêntica?

A Web Agêntica é uma web em que agentes de IA ajudam as pessoas a encontrar informações e a concluir tarefas. Esses agentes podem viver no site, no navegador ou em outra aplicação.

Portanto, o conceito não se resume a um chatbot no canto da tela. Ele inclui desde um filtro inteligente de passagens até um agente capaz de acompanhar uma jornada em vários sites.

Imagine uma loja virtual. Em vez de abrir cada filtro, você pede: “Mostre calças pretas no meu tamanho, disponíveis para entrega nesta semana”. O agente interpreta o objetivo, configura a busca e apresenta os resultados.

Agora imagine uma tarefa maior. Você pesquisa produtos em várias lojas, compara prazos e organiza as opções. Nesse caso, o agente atua como um parceiro de navegação. Esse modelo recebe o nome de co-browsing.

A documentação do Chrome sobre Agentic Web reúne APIs e práticas para esse novo tipo de interação. No entanto, o ecossistema continua em movimento. Por isso, vale entender os princípios antes de apostar em uma implementação específica.

Agentes no site e agentes externos

Existem dois caminhos principais para participar da Web Agêntica. Primeiro, você pode criar um agente dentro do próprio site. Depois, pode preparar o site para agentes externos.

Agentes on-site

Um agente on-site conhece o domínio do produto. Ele pode entender regras internas, catálogo, suporte e contexto do usuário.

Por exemplo, um site de viagens pode receber pedidos em linguagem natural. O usuário informa horário, limite de conexões e orçamento. Em seguida, o agente converte esse pedido em filtros da aplicação.

Essa abordagem oferece bastante controle. Porém, também exige modelo, interface, segurança, observabilidade e manutenção. Como resultado, o custo cresce rapidamente.

Agentes externos

Um agente externo reside no navegador, em uma extensão ou em outra aplicação. Ele visita o site em nome do usuário e tenta realizar uma tarefa.

Esse agente não conhece todos os detalhes do negócio. Por outro lado, ele acompanha o usuário ao longo de diferentes serviços. Assim, consegue ajudar em uma jornada que não termina em uma única aba.

Para a maioria dos projetos, preparar o site para esses agentes é o ponto de partida mais acessível. Você melhora a base existente e reduz as barreiras. Além disso, essas mudanças costumam beneficiar pessoas, buscadores e tecnologias assistivas.

Três etapas da Web Agêntica

Na conversa com André, surgiu um modelo prático para pensar na Web Agêntica. Um agente precisa passar por três etapas:

1. Descobrir que o site e seu conteúdo existem.
2. Entender a interface e as opções disponíveis.
3. Atuar no site para concluir uma tarefa.

Cada etapa usa sinais diferentes. Portanto, uma boa estratégia não depende de um único arquivo nem de uma API isolada.

1. Descoberta: como o agente encontra seu site

A descoberta se parece bastante com o trabalho de SEO. O agente precisa localizar páginas, identificar o tema e acessar conteúdo útil.

Por isso, os fundamentos continuam relevantes:

• conteúdo rastreável;
• links internos claros;
• títulos e descrições coerentes;
• respostas HTTP corretas;
• robots.txt e sitemap.xml atualizados;
• conteúdo principal disponível sem interações desnecessárias.

O ponto de atenção está no uso de JavaScript. Buscadores maduros conseguem renderizar muitas aplicações com Client-Side Rendering. Porém, nem todo agente dispõe da mesma infraestrutura.

Se o conteúdo essencial só aparece após várias chamadas no cliente, alguns agentes podem receber uma página vazia. Portanto, Server-Side Rendering, pre-rendering ou uma versão estática podem melhorar a descoberta.

llms.txt, Markdown e arquivos de identidade

O llms.txt é uma convenção emergente para oferecer um resumo do site e links importantes. O arquivo usa Markdown e normalmente fica na raiz do domínio.

Ele pode reduzir o trabalho necessário para entender a estrutura geral. Ainda assim, o arquivo é opcional. A auditoria de llms.txt no Lighthouse deixa esse caráter experimental explícito.

Também existem propostas para publicar uma identidade estruturada em arquivos como identity.json. Contudo, ainda há formatos concorrentes e pouco suporte oficial documentado. Portanto, trate esse recurso como um experimento, não como substituto de Schema.org, de páginas institucionais ou de dados visíveis.

Outra opção é oferecer uma versão em Markdown do conteúdo. Esse formato remove boa parte do ruído do HTML. Como resultado, o agente consome menos tokens e encontra o texto principal com mais facilidade.

No entanto, nenhum desses arquivos corrige uma arquitetura ruim. A base continua sendo conteúdo claro, HTML acessível e URLs confiáveis.

2. Entendimento: como o agente interpreta a página

Depois da descoberta, o agente precisa entender a página aberta. Para isso, agentes de navegador podem combinar três sinais:

1. screenshot da interface;
2. DOM renderizado;
3. árvore de acessibilidade.

O screenshot ajuda o modelo a reconhecer botões, campos e relações visuais. Portanto, hierarquia, contraste e consistência também influenciam a leitura feita pela IA.

O DOM oferece a estrutura da página. Se um botão usa o elemento <button> e possui um texto descritivo, o agente entende melhor sua função. Por outro lado, uma <div> com onclick exige mais inferência.

Finalmente, a árvore de acessibilidade expõe nomes, funções e estados. Um formulário com <label>, campos corretos e mensagens de erro claras oferece sinais melhores.

O que ajuda pessoas também ajuda agentes

Esse é um dos pontos mais importantes da Web Agêntica. Você não precisa criar uma versão separada do site para IA.

Comece com práticas que já deveriam fazer parte do desenvolvimento:

• use HTML semântico;
• mantenha uma hierarquia visual clara;
• associe cada campo ao seu <label>;
• ofereça nomes acessíveis para controles;
• preserve a navegação por teclado;
• informe erros e mudanças de estado;
• evite esconder ações essenciais em gestos obscuros.

Além disso, use ARIA apenas quando o HTML nativo não resolver o problema. ARIA existe para tecnologias assistivas e seus usuários. Portanto, não transforme atributos de acessibilidade em espaço para prompt engineering.

Se desenvolvedores começarem a otimizar descrições ARIA para modelos, usuários de leitores de tela pagam a conta. Por isso, agentes e tecnologias assistivas podem aproveitar sinais comuns, mas suas interfaces especializadas precisam permanecer separadas.

3. Atuação: como o agente conclui uma tarefa

Entender a interface não garante que o agente conclua uma jornada. Ele ainda precisa preencher campos, clicar em controles e acompanhar o resultado.

Esse processo costuma ser chamado de actuation. Em uma automação visual, o agente analisa a tela, escolhe uma ação e observa o novo estado. Depois, repete o ciclo.

Para uma tarefa curta, esse método pode funcionar bem. No entanto, a complexidade aumenta a cada etapa.

Uma reserva pode exigir data, horário, número de pessoas, disponibilidade e confirmação. Assim, o agente coleta mais screenshots, mais DOM e mais dados da árvore de acessibilidade.

Como resultado, a operação fica mais lenta e cara. Além disso, cresce a chance de clicar no controle errado ou perder uma mudança de estado.

Onde o WebMCP entra

O WebMCP oferece uma alternativa para tarefas estruturadas. Em vez de obrigar o agente a reproduzir cada clique, o site expõe funções como ferramentas.

Por exemplo, uma loja pode registrar uma ferramenta add_to_cart. A descrição informa quando usá-la, enquanto o schema define os parâmetros esperados. Assim, o agente chama a função diretamente.

Esse modelo reduz contexto, tempo e ambiguidade. Além disso, o desenvolvedor mantém a lógica dentro da aplicação.

O WebMCP possui duas formas de registro. A API imperativa usa JavaScript e document.modelContext.registerTool(). Já a API declarativa transforma formulários HTML em ferramentas.

Um formulário básico pode começar assim:

<form
  toolname="book_table"
  tooldescription="Reserva uma mesa no restaurante."
>
  <label for="date">Data</label>
  <input id="date" name="date" type="date" required>

  <label for="guests">Número de pessoas</label>
  <input
    id="guests"
    name="guests"
    type="number"
    min="1"
    toolparamdescription="Quantidade de pessoas na reserva."
    required
  >

  <button type="submit">Reservar</button>
</form>Code language: HTML, XML (xml)

O navegador converte os campos em parâmetros estruturados. Porém, o formulário continua visível. Dessa forma, o usuário acompanha a ação e mantém o contexto.

A API ainda está em discussão e pode mudar. Portanto, use a documentação da API declarativa como referência atual.

Se você quiser aprofundar a implementação, já publiquei um guia sobre como preparar seu site para agentes de IA com WebMCP. Ele compara WebMCP e MCP, mostra as duas APIs e discute testes.

WebMCP não substitui acessibilidade

Uma dúvida aparece com frequência: por que não usar apenas a árvore de acessibilidade?

A resposta está na diferença entre descrever uma interface para uma pessoa e oferecer uma ferramenta para um modelo. Um leitor de tela precisa apresentar a jornada humana. Já um agente pode usar uma operação mais direta.

Considere um agendamento com cinco telas. Pessoas precisam ver profissionais, horários e detalhes antes de confirmar. Um agente, contudo, pode consultar disponibilidade e concluir o agendamento com duas ferramentas.

Portanto, a ferramenta não representa cada botão da interface. Ela representa uma capacidade do produto.

Ainda assim, a interface humana continua essencial. O agente pode falhar, pedir ajuda ou devolver o controle. Além disso, nem toda pessoa vai querer delegar a tarefa.

A acessibilidade garante que a jornada humana funcione. O WebMCP oferece um caminho adicional para o agente. Esses objetivos se complementam, mas não são intercambiáveis.

Segurança e controle do usuário

Dar ferramentas a um agente exige limites claros. Uma busca de produtos possui risco baixo. Porém, uma compra, uma transferência ou a exclusão de dados exige confirmação.

Primeiro, valide todos os parâmetros no código. O schema ajuda o modelo, mas não substitui validação, autorização e regras de negócio.

Depois, mantenha o usuário informado. Mostre o que o agente pretende fazer e permita cancelar a operação. Para ações sensíveis ou irreversíveis, peça confirmação na própria interface.

Além disso, aplique o princípio do menor privilégio. Uma ferramenta deve acessar apenas os dados e ações necessários para sua função.

Por fim, considere ataques de prompt injection. Conteúdo malicioso pode tentar manipular o agente. A documentação de segurança para agentes e WebMCP recomenda tratar descrições, resultados e conteúdo da página como entradas potencialmente não confiáveis.

O rascunho público do WebMCP também reforça o papel do humano no processo. A proposta busca fluxos colaborativos dentro do navegador, não agentes autônomos sem supervisão.

Como preparar seu site para a Web Agêntica

Você não precisa esperar a padronização terminar. Grande parte do trabalho inicial melhora o site atual e possui baixo risco.

1. Revise a base técnica

• confirme se o conteúdo principal chega no HTML inicial;
• corrija links quebrados e respostas HTTP incorretas;
• mantenha sitemap.xml e robots.txt coerentes;
• use URLs canônicas e títulos descritivos;
• teste páginas importantes sem JavaScript.

2. Melhore a estrutura e a acessibilidade

• substitua controles genéricos por elementos HTML nativos;
• associe campos a labels visíveis;
• organize títulos em uma hierarquia lógica;
• teste a navegação por teclado;
• revise nomes e estados na árvore de acessibilidade;
• mantenha texto, ícones e ações consistentes.

3. Mapeie jornadas críticas

Liste as tarefas que geram valor para o usuário. Depois, identifique quantas etapas cada uma exige.

Uma busca simples talvez funcione com a interface atual. Porém, uma jornada longa pode se beneficiar de uma API interna ou de uma ferramenta WebMCP.

Nesse momento, não modele cada clique. Modele capacidades, como search_products, check_availability e create_booking.

4. Comece por ações seguras

Primeiramente, exponha ferramentas de leitura ou baixo impacto. Em seguida, acompanhe erros, parâmetros e cancelamentos.

Depois, crie testes com pedidos diretos e ambíguos. O agente deve pedir contexto quando faltarem dados, não inventar uma resposta.

Finalmente, avance para operações sensíveis apenas quando autorização, validação e confirmação estiverem claras.

5. Trate formatos experimentais como experimentos

Você pode testar llms.txt, versões em Markdown e WebMCP. Contudo, registre a hipótese e acompanhe o uso.

Se ninguém consome determinado arquivo, ele pode virar apenas mais uma fonte desatualizada. Por isso, meça acessos, erros e divergências.

O que muda para desenvolvedores

A Web Agêntica não elimina front-end. Pelo contrário, ela valoriza fundamentos que ficaram escondidos atrás de frameworks.

HTML semântico, acessibilidade e arquitetura de informação voltam ao centro. Além disso, desenvolvedores precisam pensar em capacidades, schemas, permissões e jornadas.

Também surge uma mudança no processo. Antes, a equipe desenhava a interface para pessoas e entregava APIs para integrações. Agora, o navegador pode juntar esses dois mundos.

O agente atua dentro da experiência visível. Portanto, produto, design, front-end, segurança e conteúdo precisam conversar desde o início.

Esse movimento também deve aproximar SEO e desenvolvimento. A descoberta por agentes compartilha parte dos fundamentos de busca. Porém, agentes vão além da leitura, pois tentam concluir tarefas.

Conclusão

A Web Agêntica ainda possui perguntas abertas. Mesmo assim, a direção já merece atenção.

Agentes precisam descobrir o site, entender sua interface e atuar com segurança. Para isso, eles combinam conteúdo rastreável, design claro, DOM semântico, acessibilidade e ferramentas estruturadas.

O melhor ponto de partida não é adicionar IA em todas as telas. Comece construindo um site melhor para pessoas. Depois, identifique onde um agente pode reduzir etapas sem remover controle.

Foi assim com mobile e PWA. Primeiro, tratamos o assunto como uma categoria separada. Depois, as boas práticas entraram no desenvolvimento cotidiano.

Provavelmente, a Web Agêntica seguirá um caminho parecido. Em algum momento, perguntar “como um agente vai usar este site?” pode se tornar apenas mais uma etapa natural do projeto.

Fontes consultadas

• Agentic Web no Chrome for Developers
• Documentação oficial do WebMCP
• API declarativa do WebMCP
• Rascunho público do WebMCP
• Segurança para agentes e WebMCP
• Auditoria de llms.txt no Lighthouse