Isso não é adjacente ao que os agentes de IA precisam. Que é o que os agentes de IA precisam. Muito antes de existirem LLMs, as tecnologias de apoio provaram a tese central: as máquinas podem navegar em interfaces, a semântica pode sobreviver à apresentação e a estrutura pode substituir a visão. Agentes baseados em capturas de tela gastam tokens redescobrindo fatos que o navegador já conhece. A árvore de acessibilidade já contém função, nome e estado de forma estruturada. Em meu próprio trabalho de agente, mudar da execução baseada em captura de tela para a execução nativa do DOM reduziu a latência por ação de 2 a 5 segundos para menos de 500 ms e o custo do token em uma ordem de magnitude.
A acessibilidade comprovou a tese. Agora precisamos da próxima camada
A constatação mais esclarecedora que tive foi esta: a acessibilidade já havia resolvido grande parte dos problemas enfrentados pelos agentes. A acessibilidade dá às máquinas uma maneira de descobrir interfaces. Expõe os controles disponíveis, seus nomes, seus estados e seus relacionamentos. Mas descoberta não é execução. A árvore de acessibilidade pode identificar um botão denominado “Checkout” e indicar se ele está desabilitado. O que não pode fornecer é um contrato para a ação em si. Por exemplo, que entradas aceita, que pré-condições são necessárias e que mudanças de estado produz.
Uma resposta emergente para essa lacuna é o WebMCP, que introduz uma maneira nativa do navegador de expor recursos digitados que os agentes podem invocar diretamente. Quando um campo de formulário não tem nenhuma anotação explícita de agente, a API declarativa do Chrome deriva a descrição do parâmetro do associado
