Sites 'prontos para agentes': como preparar o frontend para navegadores de agentes e ferramentas estruturadas

Da legibilidade para modelos de visão ao WebMCP: passos práticos para tornar as interações mais rápidas, confiáveis e depuráveis.

Por que “agent-ready” não significa “web separado”

Quando se fala de web agente, é fácil imaginar uma “nova web”. Na verdade, é mais útil vê-la como uma evolução da web atual: as pessoas continuam a ler conteúdos, comprar, reservar, gerenciar contas… mas cada vez mais frequentemente o fazem delegando partes do fluxo a um agente de IA.

Os agentes podem se apresentar de várias formas:

• No local: integrados diretamente na experiência do site.
• Agente do navegador: nativos do navegador ou fornecidos por meio de extensões.
• Fora do navegador: ferramentas externas (também CLI) que guiam o navegador por meio de protocolos como CDP.

Aqui nos concentramos no caso mais “próximo” do frontend cotidiano: agentes que operam no navegador e precisam entender rapidamente o que a página exibe e quais ações são possíveis.

Como um agente “vê” realmente seu site

Um agente não interpreta uma página como um humano de forma mágica: ele coleta sinais e os combina. Na prática, os canais principais são três.

1) Captura de tela + modelo de visão

O agente pode capturar screenshots da página renderizada e usar um modelo multimodal para interpretar layout e conteúdos visuais. Isso funciona, mas é caro (em contexto e computação) e pode ser frágil com UIs densas ou pouco consistentes.

2) DOM renderizado

O DOM fornece estrutura: hierarquias, aninhamentos, proximidades. Um botão dentro de uma seção ou um formulário com campos rotulados corretamente “conta” muito mais do que uma grade de divs.

Além disso, o texto real é um sinal chave:

• o conteúdo de um <button> sugere a ação
• títulos e rótulos ajudam a entender o que é primário/secundário

3) Árvore de Acessibilidade

É a destilação semântica que o navegador expõe (papéis, nomes acessíveis, estados). É também o que os leitores de tela usam.

Aqui há um ponto importante: melhorar a acessibilidade e a semântica ajuda simultaneamente humanos e agentes. Não é um compromisso, é um alinhamento.

O problema: quanto mais complexo é a jornada, maior é o “contexto”

Nos fluxos reais (reservas, e-commerce, configuradores, onboarding) o agente deve:

• manter memória de escolhas anteriores
• interpretar passos intermediários e estados da UI
• distinguir variantes semelhantes (ex. “modificar texto” vs “mudar estado”)

Quanto maior a complexidade, mais o agente deve sintetizar screenshots, DOM e árvore de acessibilidade. Isso implica:

• maior latência (mais contexto, mais raciocínio)
• maior probabilidade de erro (sinais ambíguos → desvios errados)

Portanto, é necessário um modo de tornar a interação mais direta e menos ambígua.

WebMCP: expor “ferramentas” estruturadas diretamente das páginas

A ideia chave do WebMCP (proposta de padrão) é simples: além de “entender” a UI, um agente deve poder invocar ações estruturadas expostas pelo site.

Exemplo conceitual:

• em vez de deduzir qual campo preencher e qual botão pressionar para “reservar uma mesa”,
• o agente pode chamar uma ferramenta como bookTable({name, date, time, partySize, notes}).

Resultado: fluxos mais rápidos, mais confiáveis, mais depuráveis.

O ponto interessante é que essas ferramentas não “substituem” a UI: elas a complementam como API de intenção para os agentes.

Definir ferramentas: abordagem imperativa (JavaScript)

No modelo imperativo, você registra uma ferramenta via API, fornecendo:

• nome: nome estável e específico
• descrição: quando usá-la
• esquema de entrada: parâmetros em JSON Schema
• executar: função que realmente executa a ação

Um aspecto frequentemente subestimado: o valor de retorno de execute é um canal de comunicação para o agente, não para o usuário. Você pode usá-lo para:

• indicar erros de validação nos parâmetros
• indicar sucesso/falha
• sugerir “próximo passo” (ex. “é necessária a confirmação do usuário”)

Ciclo de vida e limpeza

Se a existência da ferramenta depende do estado da página ou do ciclo de vida de um componente, você pode gerenciar sua remoção com um AbortController. Isso é particularmente útil em frameworks (ex. limpeza em onDestroy).

Definir ferramentas: abordagem declarativa (formulário HTML)

Se você já tem formulários “clássicos”, a abordagem declarativa é frequentemente a mais econômica.

Bastam dois atributos obrigatórios no formulário:

• toolname
• tooldescription

Além disso, você pode adicionar descrições para os parâmetros (opcional, mas muito útil) para esclarecer o que inserir nos campos.

Descrição da ferramenta = contexto operacional (não “comentários”)

Naming e descrições não são um detalhe: são parte da informação que o agente usa para decidir qual ferramenta invocar e com quais parâmetros. Na prática, é uma forma de “prompting estruturado” incorporado no markup.

Autosubmit e controle do usuário

Por padrão, uma ferramenta baseada em formulário tende a:

• fazer o agente preencher os campos
• exigir o clique do usuário para o envio

Se você quiser permitir o envio automático, entra em cena um atributo como toolautosubmit.

Reconhecer envios invocados por agente

No evento de envio, aparece um novo membro como agentInvoked para distinguir:

• envio do usuário
• envio ativado pelo agente

Isso permite que você:

• aplique validações e regras dedicadas
• responda com mensagens direcionadas ao agente (ex. explicar por que uma entrada é inválida)

Depuração: DevTools e ferramentas como para qualquer JS

Uma vantagem prática das ferramentas WebMCP é que elas são depuradas como código web normal:

• você pode ver quais ferramentas estão sendo chamadas
• com quais entradas
• e o que é retornado como saída

E se uma ferramenta for implementada em JavaScript, você pode:

• pular para o ponto de registro
• definir pontos de interrupção
• inspecionar estado e parâmetros

Isso muda a experiência de “o agente errou algo” para “eu tenho um rastreamento reproduzível de entrada/saída e posso corrigir ferramentas, esquemas ou descrições”.

Diretrizes concretas para tornar um site mais “agent-ready”

1) Comece pelos fundamentos: UI legível, HTML semântico, acessibilidade sólida. Melhore imediatamente também a experiência humana.

2) Identifique os pontos de alto atrito nas jornadas (pesquisas complexas, configuradores, checkout, reservas) e avalie onde uma ferramenta reduz a ambiguidade.

3) Projete ferramentas pequenas e específicas: “alternar status” não é “editar texto”. Evite ferramentas “faça tudo” que aumentam erros.

4) Escreva descrições operacionais (nome/descrição/descrição do parâmetro): devem ajudar um agente a escolher corretamente, não ser marketing.

5) Use JSON Schema com cuidado: tipos, enum, required,