Percepção Estruturada em Tempo de Execução: O Que os Agentes Estão Perdendo

Os últimos três posts da série Runtime Snapshots construíram uma base. #15 disse que seu agente é cego e precisa de olhos e mãos. #16 nomeou as três maneiras pelas quais ele pode ver: visão, árvore de acessibilidade e percepção em tempo de execução. #17 perguntou o que acontece quando mais de um agente compartilha o mesmo espaço de navegador ao vivo. Este post vai por baixo de todos eles, para a pergunta que esses posts assumem uma resposta: o que um agente realmente percebe no meio segundo antes de agir?

A assimetria que ninguém menciona

A maioria das falhas de agentes de navegador é registrada como falhas de modelo. O modelo clicou no botão errado, perdeu o menu, preencheu o campo errado, pensou que a página tinha carregado quando não tinha, não conseguiu se recuperar quando a interface do usuário mudou. Às vezes, esse diagnóstico está certo. Muitas vezes, o modelo recebeu a superfície errada e foi solicitado a raciocinar a partir dela.

Aqui está a parte que é ignorada: os agentes não falham da mesma maneira que as pessoas. Você abre uma aba e compensa silenciosamente tudo o que a página não diz em voz alta - um botão desativado que você não clica, um ícone de carregamento ainda girando, então você espera, um modal sobre a página para que você saiba que a coisa embaixo ainda não está ao vivo. Você recebe essa continuidade de graça, por ser um humano olhando para uma página renderizada. Um LLM não recebe nada disso de graça. Ele recebe exatamente a representação que lhe entregamos, e nada mais. Portanto, a representação é o jogo todo.

Três superfícies, nenhuma delas a aplicação

Um navegador não é uma captura de tela, não é uma árvore de acessibilidade, não é DOM bruto. Essas são visões da aplicação - úteis, mas ainda assim visões. Entregue ao modelo pixels e ele infere o estado a partir da aparência: esse botão está desativado ou apenas cinza? Entregue-lhe uma árvore de acessibilidade e ele lê uma estrutura construída para tecnologia assistiva, que aplicativos web modernos muitas vezes preenchem de forma incompleta ou inconsistente. Entregue-lhe DOM bruto e ele se afoga - resíduos de framework, nós obsoletos, ramos ocultos, identificadores gerados, texto duplicado, elementos que existem na marcação, mas não na experiência atual do usuário.

O problema não é que essas superfícies sejam inúteis. Elas são úteis. O problema é que nenhuma delas é a aplicação. O que está faltando é uma representação construída a partir da página ao vivo no momento em que o agente precisa agir.

A camada que falta tem um nome

Essa camada é a percepção estruturada em tempo de execução. (No #16 eu a chamei de percepção estrutural em tempo de execução; o nome já se estabeleceu.) Um instantâneo estruturado em tempo de execução responde às perguntas que um loop de ação realmente tem: o que posso ver agora, o que posso agir agora, o que está desativado ou oculto ou coberto ou carregando ou obsoleto, quais identidades de elementos sobreviverão à próxima ação, qual texto é a tarefa e qual é navegação e resíduos de framework, o que mudou desde o último passo.

Concretamente, ele carrega a lacuna entre o que o HTML diz e o que a página é:

form#login (action=/auth)
  input[email]      "user@example.com"
  input[password]   required
  button[submit]    "Entrar"   [desativado]
  div.error.hidden  "Credenciais inválidas"

O botão de envio desativado e o erro ainda não visível são exatamente o tipo de estado que decide se a próxima ação faz algo. Eles são ambíguos em pixels, muitas vezes incompletos ou não confiáveis em uma visão de acessibilidade fina, e presentes, mas ruidosos em DOM bruto. SiFR, a Representação de Interface Estruturada usada pelo E2LLM, carrega esse estado de forma compacta, com cada nó relevante endereçado, para que o modelo possa apontar de volta para o elemento que ele significa. Essa é a diferença prática entre "o modelo viu uma página" e "o modelo recebeu uma representação de estado utilizável."

Por que a sessão do navegador importa

A percepção estruturada em tempo de execução roda ao lado da própria sessão do navegador do usuário - a sessão real, já autenticada, com as mesmas permissões e restrições que o usuário já possui. Isso importa porque muitas aplicações importantes não têm uma API limpa para a tarefa que o usuário precisa realizar: portais bancários, portais governamentais, ferramentas internas, painéis de administração legados, dashboards de SaaS com estado de fluxo atrás do login. Nesses lugares, uma conta de bot desconectada ou um navegador recém-logado não é o mesmo estado da aplicação. O agente precisa perceber o estado que o usuário está realmente vendo, dentro de uma sessão explicitamente autorizada, antes que ele possa fazer uma proposta útil para o próximo passo. Isso não é uma característica de conveniência - é a diferença entre "pode tentar a tarefa" e "não consegue ver a página relevante de forma alguma."

Da tese à evidência

Por vários posts, isso tem sido arquitetura, então, claramente, onde está. O substrato está ao vivo: E2LLM expõe o estado estruturado do navegador através de uma extensão de navegador e ferramentas MCP, documentadas em e2llm.com/docs/mcp-tools. A categoria pública e a superfície de evidência estão em insitu.im/e2llm e insitu.im/e2llm/evidence, e o índice Runtime Snapshots vive em insitu.im/e2llm/runtime-snapshots. O próximo instantâneo é a parte para a qual esta série tem sido construída: um walkthrough completo da percepção estruturada em tempo de execução dirigindo uma tarefa real em um site sem API, do início ao fim - incluindo onde fica difícil.

A fronteira, não o modelo

A próxima onda de automação de navegador não será definida apenas por melhores modelos. Ela será definida por melhores fronteiras de percepção - pelo que o agente pode saber antes de agir. Capturas de tela são úteis, árvores de acessibilidade são úteis, DOM é útil. Mas um agente operando dentro de uma sessão real do navegador precisa de algo mais específico: uma representação estruturada do que a página é agora, o que pode ser agido agora e o que mudou desde o passo anterior. Essa é a categoria que me importa. Não "IA olhando para páginas." Percepção estruturada em tempo de execução: a camada que os agentes de navegador estão perdendo.

e2llm.com

Esta é a parte 18 da série Runtime Snapshots - explorando como dados estruturados do navegador mudam a maneira como construímos, testamos e enviamos software. #16 nomeou as três arquiteturas; #17 fez com que compartilhassem uma sessão; esta é sobre o que qualquer uma delas percebe antes de agir.

Se você construiu ou usou agentes de navegador - onde o seu falhou primeiro: percepção, planejamento ou ação?