Back home

A compatibilidade da Web para agentes está passando de um recurso complementar para um requisito padrão

Os sites públicos devem ser legíveis, verificáveis ​​e rastreáveis ​​por humanos, rastreadores e agentes

Um conteúdo normal aparece no navegador, mas muitas vezes não pode ser lido completamente quando passado para o programa agente. Só porque a página pode ser aberta não significa que ela possa realmente ser consumida; só porque pode ser visto pelas pessoas, não significa que possa ser lido, verificado e rastreado de forma estável por máquinas.

Esse assunto costumava ser considerado uma questão secundária, como “preencher o mapa do site” ou “adicionar alguns dados estruturados à página do artigo”. Não é mais uma esquina. Quando um site público enfrenta rastreadores de IA, recuperação automatizada e fluxos de trabalho baseados em agentes, os objetos compatíveis não são mais apenas navegadores e mecanismos de pesquisa, mas também um tipo de cliente que pode dividir páginas com base na semântica, saltar com base em links e continuar a execução com base no status. Se uma página for amigável apenas para leitores humanos, mas cheia de armadilhas para esses clientes, ela começará a parecer um site com compatibilidade incompleta.

Só porque a página pode ser aberta não significa que a página possa ser lida.

O primeiro problema geralmente não é a qualidade do conteúdo, mas a forma como o conteúdo é produzido.

Se uma página incorporar o texto do corpo na renderização do lado do cliente, ocultar campos-chave em painéis sanfonados, transformar a paginação em um fluxo de rolagem sem URLs explícitos e renderizar tabelas em imagens, o programa do agente só poderá confiar em suposições. Para os humanos, um palpite errado pode significar que um parágrafo foi perdido; para uma máquina, uma suposição errada pode fazer com que as ações subsequentes se desviem, e mais alguns passos no futuro apenas continuarão no entendimento errado.

Esse tipo de problema é especialmente óbvio em sites de documentos e sites de conteúdo. Os leitores humanos seguem a camada visual e completam eles próprios o contexto; os agentes não. O que o agente vê é o DOM, a hierarquia de cabeçalhos, relacionamentos de links, controles de formulário, códigos de status e texto rastreável. Se o texto principal estiver desconectado desses sinais básicos, a página aparecerá em um estado estranho: parece moderna, mas na verdade é instável.

No passado, ao migrar aplicativos de página única, essa camada costumava ser a primeira a ser exposta. A primeira tela aparece e a interação é possível, mas a máquina captura o shell e o texto real não aparece até que o script seja finalizado. Juntamente com carregamento lento, rolagem infinita e vários designs de “expansão e visualização”, a página de conteúdo se tornará uma série de eventos acidentais. Para os usuários do navegador, é apenas uma ligeira lentidão; para os agentes, é uma cadeia de entradas não confiáveis.

O que a máquina quer é uma entrada estável, não conteúdo visual.

Tornar o site “pronto para agente” é essencialmente adicionar uma camada de compatibilidade, em vez de adicionar um novo truque.

O aspecto mais valioso desta camada de compatibilidade não é fazer com que a página “pareça que é para máquinas”, mas declarar claramente os fatos mais básicos: que página é esta, onde está o texto, qual é o status atual, se pode continuar a saltar e o que deve ser retornado quando falhar. Enquanto estes factos forem instáveis, os agentes testarão repetidamente os limites.

As coisas mais valiosas para lidar primeiro em sites de conteúdo geralmente são estas:

  • O texto deve ser acessível diretamente a partir do HTML, sem depender de scripts para adivinhá-lo
  • A hierarquia de títulos deve ser estável e não permitir que o estilo visual substitua a estrutura semântica.
  • A paginação, a filtragem e os resultados da pesquisa devem ter URLs compartilháveis, em vez de existirem apenas no estado front-end
  • Imagens, tabelas e blocos de código devem ter texto alternativo legível ou texto original
  • As exportações básicas de canônico, mapa do site e feed devem ser limpas e não misturadas com vários parâmetros temporários.

Isto pode parecer clichê, mas seu significado agora mudou. No passado, estes foram adicionados por causa dos motores de busca e da acessibilidade; agora, eles são adicionados para permitir que o agente localize o conteúdo de maneira estável, determine o relacionamento entre as páginas e prossiga para a próxima etapa sem solicitações manuais. Todos apontam para a mesma coisa: a página precisa ser tratada como uma entrada definitiva de outro cliente, em vez de um resultado visual único.

É por isso que “adicionar um botão AI” realmente não ajuda. O botão em si não torna a página mais consumível. Na melhor das hipóteses, apenas envolve uma ação em uma nova entrada. Se a camada inferior ainda depender do layout visual e do estado temporário para manter a compreensão, o programa do agente ainda perderá o controle ao atualizar, saltar, reverter e alterar as permissões.

A interação deve completar a ação, não apenas parar no prompt

Se a página for apenas para exibição de conteúdo, os problemas de compatibilidade serão relativamente fáceis de resolver. Quando se trata do nível de interação e operação, o problema fica ainda mais difícil.

O que um agente realmente precisa não é “quase suficiente”, mas limites de ação claros. Enviar, confirmar, revogar, baixar, assinar, pular e exportar. Essas ações devem preferencialmente ter pré-condições claras, retornos de falha e resultados rastreáveis. Contanto que as ações sejam misturadas com vários pop-ups, prompts e confirmações secundárias, a máquina ficará presa no mesmo lugar repetidamente.

É aqui que a diferença entre sites públicos e sistemas internos começa a aumentar. Os sites públicos enfrentam problemas de consumo, enquanto os sistemas internos enfrentam permissões e controle de riscos. O primeiro é mais adequado para estabilizar a estrutura da informação e a semântica das ações, para que os clientes externos possam evitar desvios; este último não deve flexibilizar os limites para ser “compatível com os Agentes”, especialmente quando estão envolvidos fundos, publicação, exclusão e alterações de permissão. Ainda temos que ser conservadores onde deveríamos ser conservadores.

Portanto, não se trata de transformar todas as páginas web em interfaces de máquina. Uma abordagem mais realista é transformar as páginas originalmente destinadas ao consumo externo em entradas estáveis, verificáveis ​​e reproduzíveis. Páginas de artigos, páginas de documentação, bases de conhecimento, centrais de ajuda, APIs abertas e resultados de pesquisa pública são os primeiros a serem afetados e os primeiros a ver os benefícios.

Este nível de compatibilidade tem limites claros

A preparação para o agente não é uma meta única para todos.

O backend de uma intranet completa, o sistema empresarial com forte controle de permissões, a página de atividades de ciclo de vida curto e a estação de conteúdo para consumo público não estão no mesmo nível. O primeiro se preocupa mais com o controle, enquanto o segundo se preocupa mais com a legibilidade, indexabilidade e rastreabilidade. Forçar estes dois tipos de sistemas no mesmo conjunto de padrões que “tornam as máquinas utilizáveis” só acabará por aumentar os custos de gestão.

Mas é difícil continuar fingindo que nada mudou no site público. Os rastreadores de IA lerão cada vez mais as páginas diretamente e os fluxos de trabalho dos agentes dependerão cada vez mais de conteúdo estruturado e ações estáveis. Se um site ainda aderir à ideia de “basta que as pessoas vejam”, mais cedo ou mais tarde haverá falhas na distribuição, recuperação, arquivamento e integração automatizada de conteúdo.

Portanto, esta mudança é mais como uma atualização de compatibilidade. No passado, o front-end tinha que considerar diferentes navegadores, diferentes telas e diferentes redes; agora ele também precisa considerar um tipo de cliente que pode dividir páginas sozinho, seguir links sozinho e verificar o status sozinho. Com essa camada de compatibilidade adicionada, o site pode realmente entrar em um novo requisito padrão: ele deve não apenas ser visível, mas também consumido de forma estável.

FAQ

What to read next

Related

Continue reading