O que é uso do computador e por que isso importa? O uso do computador é uma ideia simples com amplas implicações: em vez de pedir aos modelos que respondam a perguntas, pedimos que operem softwares — navegando por sites, preenchendo formulários, avançando por fluxos de trabalho e concluindo tarefas de ponta a ponta com autonomia.
Isso viabiliza uma ampla classe de tarefas do mundo real que hoje estão fragmentadas entre diferentes interfaces, como reservas de ponta a ponta, finalização de compras online, planejamento de viagens em várias etapas e fluxos administrativos sem um equivalente adequado em API. Esses problemas não são novos. A novidade é que agora é viável resolvê-los com modelos de uso geral.
Sistemas recentes da Anthropic e da OpenAI demonstraram agentes que não apenas agem, mas raciocinam sobre o estado, recuperam-se de erros e criam soluções específicas para cada tarefa em tempo real. Isso transforma o navegador em um ambiente de execução geral para agentes, mas levanta imediatamente uma questão de projeto: quanto desse ambiente devemos expor ao modelo?
Os primeiros sistemas responderam envolvendo o navegador em um conjunto fixo de ações seguras e predefinidas. Como argumentaremos neste artigo, essa abordagem está chegando ao limite.
Ao criar agentes para navegadores, é comum seguir um instinto conhecido: não confie demais no modelo.
Por isso, envolvemos o navegador em um wrapper. Disponibilizamos ferramentas predefinidas como click, type, scroll, select e read_text. Simplificamos o Modelo de Objetos de Documento (DOM). Reduzimos o espaço de ações. Tentamos tornar o comportamento compreensível e controlável por meio de abstrações que nós mesmos projetamos.
Esse é um ponto de partida sensato. Mas também é, cada vez mais, a arquitetura errada no longo prazo.
À medida que os modelos de fronteira melhoram, a limitação já não é apenas a falta de ferramentas para o modelo. O problema é que o forçamos a operar por meio de abstrações que removem informações demais do sistema subjacente. Comprimimos um ambiente complexo e dinâmico em uma interface fixa de ações e, então, pedimos ao modelo que tenha um bom desempenho apesar dessa perda de informações.
Essa troca está se tornando menos vantajosa.
A mudança que temos explorado é simples de descrever, mas traz consequências significativas. Em vez de tratar o agente como um seletor de ações predefinidas, nós o tratamos como um sintetizador de programas que opera em um ambiente de execução restrito.
Os modelos ficaram muito bons e já não precisam das proteções abstratas que você criou. Eles precisam do espaço completo de ações para projetar, executar e refinar a tarefa até atingir seu objetivo.
Este artigo aborda essa mudança, da automação de navegadores carregada de abstrações para o uso restrito do computador, e o que muda quando os sistemas são projetados dessa maneira.
O problema não é que interfaces fixas de ações sejam conceitualmente erradas. O problema é que a web não coopera com elas.
As interfaces modernas são criadas com React, Vue e Angular, incluindo atualizações assíncronas de estado, sistemas de eventos sintéticos e widgets incorporados de terceiros que operam em iframes de origens diferentes e têm ciclos de vida próprios. Um wrapper que diz "digite neste campo" só funciona corretamente se a página concordar com a sua definição de digitação. Muitas não concordam. Definir um valor diretamente muitas vezes ignora por completo a detecção de alterações do framework. O campo parece preenchido. A validação nunca é acionada. O formulário continua sem funcionar.
É possível corrigir isso. Você pode adicionar casos especiais para campos do React, disparar eventos de blur após o foco e aguardar a inatividade da rede antes de ler o estado. Cada correção funciona em seu contexto específico. Em conjunto, porém, elas se acumulam e formam um sistema cada vez mais difícil de manter e cada vez mais específico para os sites que você já encontrou.
A questão mais profunda é que você incorpora à camada de abstração pressupostos sobre como as interações deveriam funcionar e depois descobre que a web adota pressupostos diferentes.
Considere um formulário de pagamento incorporado via Stripe ou Adyen em um iframe de origem diferente. Seu wrapper não consegue acessá-lo diretamente porque ele está em uma origem separada. Sua ferramenta read_text não consegue observar o estado interno dele. Sua ferramenta type não consegue acessar os campos dele. Um agente baseado em wrappers fica sem saída nesse ponto. A abstração foi projetada para o documento principal. A tarefa real está em um local que a abstração não consegue enxergar.
Uma incompatibilidade semelhante aparece em fluxos menos óbvios. Um menu suspenso controlado por um framework pode não responder a cliques diretos, pois o elemento visível não é o controle propriamente dito. Talvez seja necessária uma sequência de eventos de teclado para acionar a transição de estado subjacente. Para quem vê de fora, a interface parece permitir cliques. A abstração diz "clique". Nada acontece.
Ou considere um fluxo modal com várias etapas, no qual as atualizações visíveis do DOM ficam atrasadas em relação às alterações do estado interno. A próxima ação correta depende de uma transição de estado que ainda não se reflete nos elementos visíveis para o wrapper. Um agente baseado em wrappers acaba agindo cedo demais ou lendo um estado desatualizado, pois opera com uma visão incompleta do sistema.
Em cada caso, a abstração oculta os sinais de que o agente realmente precisa.
Um modelo que opera em um nível mais baixo — inspecionando o DOM em tempo real, raciocinando sobre os limites entre frames e sintetizando a sequência de interação para aquela superfície específica — consegue lidar com essas situações. Não é que o modelo seja inerentemente mais inteligente. É que ele tem acesso às informações que haviam sido removidas.
A mudança que buscamos é simples de descrever: em vez de pedir ao modelo que selecione ações predefinidas, oferecemos uma superfície de execução de nível mais baixo e a restringimos por meio de políticas de execução, e não pelo projeto de abstrações.
Essa escolha de projeto decorre de uma mudança mais ampla no setor, que começa a favorecer ferramentas primitivas de nível mais baixo. Elas aproveitam a capacidade natural do agente de se corrigir em tempo de execução e produzir código de alta qualidade, em vez de depender de ferramentas específicas codificadas de forma rígida, que são robustas, mas eliminam a capacidade do modelo de se adaptar a ambientes diferentes.
Considere o sucesso do Claude Code como uma das principais opções no conjunto de ferramentas de muitos desenvolvedores e o movimento mais amplo do setor em direção a agentes baseados em terminal. A maior vantagem do Claude Code não é o modelo em si, mas o harness de nível mais baixo. Oferecer ao modelo menos ferramentas, porém mais modulares e de nível mais baixo — isto é, o terminal — melhora o desempenho na chamada de ferramentas, sobretudo porque o agente pode raciocinar e criar scripts personalizados para a tarefa em questão, em vez de tentar usar ferramentas generalizadas que sobrecarregam a janela de contexto.
Na prática, para a automação de navegadores, isso significa que o modelo pode inspecionar diretamente o estado da página em tempo real, percorrer frames e criar código de interação sob medida para a interface atual, em vez de mapear tudo para um conjunto fixo de ações prontas.
O modelo se comporta menos como um seletor e mais como um autor em tempo de execução. Ele inspeciona o estado atual, raciocina sobre a interface e sintetiza a lógica de interação para aquela situação específica. Ele pode criar sequências de várias etapas, adaptar-se a fluxos incomuns e validar os resultados antes de prosseguir. Quando uma ação falha, o modelo vê o erro subjacente e se corrige. Isso é mais poderoso e mais arriscado, mas se aproxima muito mais da verdadeira natureza do problema.
É importante destacar que remover a camada de abstração não torna o sistema menos rigoroso. Apenas transfere esse rigor para outro lugar.
O trabalho que antes ficava no projeto de wrappers e no tratamento de casos extremos migra para três lugares: o prompt, que se torna uma forma de treinamento operacional; o ambiente de execução, que impõe limites como escopo de navegação, ações sensíveis e comportamento de novas tentativas; e a camada de avaliação, que determina não apenas se a tarefa foi concluída, mas também se as etapas intermediárias estavam corretas. Menos abstrações frágeis. Sistemas de apoio mais robustos.
Um dos resultados dessa mudança é que o código do produto muitas vezes fica mais simples, embora o sistema como um todo se torne mais capaz. Em vez de codificar padrões de interação como wrappers reutilizáveis, o agente sintetiza o comportamento em tempo de execução. Você mantém um pequeno conjunto de primitivas poderosas e um ambiente de execução restrito, em vez de uma variedade crescente de ferramentas especializadas e lógica para casos extremos.
Isso também muda a forma como o sistema generaliza. Um agente baseado em wrappers generaliza bem para tarefas semelhantes àquelas contempladas pelos wrappers que você já criou. Um agente com ambiente de execução restrito generaliza para tarefas que compartilham uma mesma base de execução, mesmo quando a interface visível é diferente.
Por exemplo, interagir com um formulário de busca, um fluxo de reserva ou uma página de configurações pode parecer algo completamente diferente no nível da interface. Mas, nos bastidores, essas interações compartilham padrões: leitura de estado, acionamento de eventos, validação de resultados e tratamento de atualizações assíncronas. Um sistema que opera nesse nível transfere seu aprendizado entre tarefas com mais naturalidade.
O componente reutilizável não é a lista de ações. É a capacidade do modelo de inspecionar o estado, agir com segurança e verificar os resultados.
A lição mais clara deste trabalho é que a confiabilidade não vem de oferecer mais funções auxiliares ao modelo. Muitas vezes, ela vem de oferecer menos primitivas, porém mais poderosas, e restringi-las da maneira adequada. A ajuda excessiva incorpora ao código pressupostos sobre como uma tarefa deve ser realizada. As restrições definem limites operacionais seguros e permitem que o modelo descubra soluções locais melhores.
Uma superfície de execução mais poderosa também exige um modelo de segurança mais rigoroso. Quando o agente deixa de estar restrito a um pequeno conjunto de ações predefinidas, ele passa, na prática, a operar diretamente em software real. Isso muda imediatamente o perfil de risco.
Há quatro questões que precisam ser consideradas no projeto:
Exposição de dados. Quando interage com interfaces reais, o agente frequentemente encontra informações confidenciais. Isso exige uma abordagem rigorosa para mascaramento e controle de acesso. Os dados só devem ser revelados quando necessários à execução, e logs e rastreamentos precisam ser tratados com cuidado para que a observabilidade não se torne a parte mais sensível do sistema.
Escopo de execução. Um agente poderoso não deve poder operar de forma irrestrita. Na prática, isso significa limitar os locais pelos quais ele pode navegar, os domínios que pode acessar e os sistemas com os quais tem permissão para interagir. Essas restrições devem ser impostas no ambiente de execução, e não deixadas como meras convenções no prompt.
Confiabilidade do ambiente. Interfaces modernas podem incluir instruções, conteúdo ou fluxos enganosos ou deliberadamente hostis. A injeção de prompt por meio do conteúdo da página é uma superfície de ataque real. O sistema precisa de uma hierarquia clara de instruções, verificações de validação e condições de encerramento para impedir que o agente siga orientações indevidas.
Espectro de autonomia. Nem todas as ações devem ser totalmente autônomas. Em muitos ambientes de produção, é importante tratar a autonomia como um espectro. O sistema pode contar amplamente com agentes de IA ao explorar e executar, mas ainda exigir aprovação para determinadas categorias de ações.
O princípio subjacente é simples: dar mais poder ao modelo exige fortalecer o sistema ao seu redor. Autonomia sem políticas não está pronta para produção.
Paramos de perguntar: quais ações do navegador devemos disponibilizar?
Começamos a perguntar: como podemos oferecer ao modelo um espaço completo de ações e criar, em torno dele, políticas de execução que ainda garantam a segurança?
Essa nova perspectiva muda o que é importante. Taxonomias de ações e a abrangência dos wrappers passam a importar menos. Políticas de execução, observabilidade e avaliação de cada etapa passam a importar mais. A capacidade do modelo e o projeto do sistema não substituem um ao outro. À medida que os modelos melhoram, o trabalho do sistema se torna mais importante, não menos.
Agentes de navegador que funcionam em demonstrações muitas vezes têm sucesso porque a tarefa é limitada e o ambiente coopera. Sistemas de produção exigem algo diferente: execução restrita, comportamento instrumentado e avaliações capazes de distinguir um resultado correto de um resultado obtido por sorte.
Menos projeto de wrappers. Mais engenharia de sistemas.
Embora tenhamos nos concentrado em agentes de navegador, isso aponta para uma forma mais ampla de pensar o uso do computador como uma disciplina de sistemas.