Um agente de IA que opera navegador trabalha sobre uma página que muda sozinha. Quando a aba recarrega (atualização de painel, sessão expirada, re-renderização por polling), o agente pode continuar clicando no que já não existe, duplicar uma ação já concluída ou repetir um lançamento.
O caminho seguro é observar sinais de mudança antes de agir, esperar a página estabilizar e verificar se o efeito já aconteceu antes de refazer. Registro de passos e checagem de comprovante evitam a maioria dos erros.
Resumo rápido
- Abas que recarregam sozinhas invalidam o mapa da página que o agente tinha em memória.
- Sinais de mudança: elemento que some, id que troca, URL diferente, indicador de carregamento.
- Esperar a página estabilizar antes do próximo passo evita clicar no lugar errado.
- Antes de repetir, checar se o efeito já aconteceu (idempotência).
- Registro de passos permite retomar de onde parou após sessão expirada.
- Em dúvida, pedir confirmação humana em vez de tentar de novo.
Por que uma aba que recarrega derruba o contexto do agente
Um agente de navegador mantém uma referência dos elementos da página: o campo de nome, o botão de salvar, o link do menu. Essa referência é o contexto de operação. Quando a página recarrega ou re-renderiza, o navegador descarta os elementos antigos e cria novos. A referência guardada passa a apontar para nada, ou para outro elemento que herdou a posição na tela.
A partir daí, dois problemas aparecem. O primeiro é a falha visível: o clique não funciona porque o elemento sumiu. O segundo é pior: o clique funciona, mas em um elemento diferente, porque a página mudou e o agente agiu sobre uma posição que agora significa outra coisa.
Páginas de painel, single page applications e sistemas que fazem polling (consulta repetida ao servidor em intervalos) recarregam com frequência. Quanto mais dinâmica a tela, mais rápido o contexto envelhece.
Os sinais de que a página mudou
O agente não precisa adivinhar. A página avisa de várias formas. Reconhecer esses sinais antes de agir é o que separa automação estável de automação que quebra sozinha.
- Elemento que some: o campo ou botão que existia não está mais na lista de elementos da página.
- Id ou seletor que muda: sites geram identificadores aleatórios a cada renderização, então o seletor da rodada anterior não resolve.
- URL diferente: o endereço mudou, o que indica navegação, redirecionamento para login ou troca de rota na aplicação.
- Indicador de carregamento: spinner, barra de progresso ou texto “carregando” mostram que o conteúdo ainda não está pronto.
- Marca de tempo ou versão: muitos painéis exibem horário de atualização e avisam quando recarregaram.
Por que esperar a página estabilizar
Agir durante a re-renderização é a causa de muitos cliques errados. No instante em que a página troca de conteúdo, é comum ver um layout intermediário: os elementos antigos ainda visíveis, os novos entrando, um overlay de carregamento por cima. Clicar nesse momento acerta o que estava lá, não o que ficou.
Esperar a estabilização significa aguardar uma condição concreta: o indicador de carregamento desaparecer, o elemento esperado aparecer com um texto específico, o botão ficar habilitado. Espera por tempo fixo é frágil, porque a rede varia. Espera por condição é robusta, porque verifica o estado real da página.
Idempotência: checar antes de repetir
Idempotência, em automação, é desenhar cada passo para que repeti-lo não cause efeito duplicado. É o antídoto contra o agente que relança a mesma nota, reenvia o mesmo e-mail ou registra o mesmo pedido duas vezes depois de um recarregamento.
Antes de refazer, o agente consulta a evidência de que o passo já foi executado. Em um portal de notas, isso significa procurar o número da nota na lista, ou abrir o comprovante. Em um sistema de e-mail, significa checar a caixa de enviados. Só se a evidência não existir, o agente repete.
Essa checagem resolve a ambiguidade central: quando a página recarrega no meio de uma ação, o agente não sabe se o servidor recebeu o pedido. Procurar o resultado é mais confiável do que presumir que falhou.
O risco de duplicar um pedido ou lançamento
Duplicar é pior do que falhar. Uma ação que falha aparece como erro e alguém corrige. Uma ação duplicada entra no sistema como se fosse legítima: dois boletos emitidos, dois lançamentos contábeis, duas mensagens enviadas ao cliente.
Os efeitos se espalham. Estoque desatualizado, cobrança repetida, relatórios incorretos. Quando o erro é percebido, a correção costuma envolver estorno e ajuste manual, com custo de tempo e de confiança. Por isso a regra de ouro é: nunca repetir um passo de escrita sem antes checar se ele já foi aplicado.
Passos de leitura (abrir uma página, consultar um valor) podem ser repetidos sem dano. Passos de escrita (enviar, salvar, lançar, pagar) exigem a checagem prévia. Separar os dois tipos de passo no desenho do agente é a defesa mais básica.
Timeout de sessão e reautenticação
Sessões de sistemas corporativos expiram por segurança. Quando o tempo acaba, o servidor redireciona o agente para a tela de login. Se o agente não percebe, ele tenta preencher um formulário que já não está lá, ou pior, digita dados em um campo de login achando que é o campo de destino.
A reautenticação deve ser tratada como um passo explícito do fluxo, não como erro inesperado. Ao detectar que a URL virou a de login, o agente efetua a autenticação, volta para a tarefa e retoma do ponto registrado. Credenciais e códigos de verificação ficam guardados no cofre do sistema, nunca no texto do fluxo.
Comparativo de situações, sinais e ação correta
A tabela reúne as quatro situações mais comuns em que a página muda sob o agente, o sinal que ele deve observar e o que fazer.
| Situação | Sinal a observar | Ação correta |
|---|---|---|
| Recarregamento suave (re-renderização) | Elemento some ou ganha novo id; indicador de carregamento breve | Esperar a condição de pronto e reler os elementos antes de clicar |
| Sessão expirada | URL virou a de login; campo de senha apareceu | Reautenticar pelo cofre e retomar do último passo registrado |
| Navegação para outra URL | Endereço fora da rota esperada; título da página mudou | Interromper o passo atual e reavaliar o estado antes de continuar |
| Erro de rede | Página de erro, conteúdo em branco, resposta lenta | Não repetir escrito; checar se o efeito entrou e só então decidir |
Note que em nenhuma linha a ação correta é “clicar de novo imediatamente”. A resposta sempre passa por reavaliar o estado da página e verificar o efeito antes de qualquer repetição.
O papel de um registro de passos
Sem registro, um agente que perde a sessão não sabe onde estava. Ele recomeça do início e refaz passos já concluídos, o que reintroduz a duplicação que queríamos evitar.
O registro de passos (log) anota, a cada ação, o quê foi feito, o resultado e a evidência obtida. Depois de uma interrupção, o agente lê o log, identifica o último passo concluído com sucesso e retoma a partir dali. É o mesmo princípio de um trabalho que pode ser pausado e continuado sem perder o progresso.
Um bom log guarda o identificador do item em processamento, o comprovante gerado e a marca de tempo. Com isso, a retomada é precisa e a checagem de duplicidade fica direta: basta procurar o comprovante antes de refazer.
Quando pedir confirmação humana
Existem momentos em que tentar de novo é pior do que parar. Se o agente não consegue determinar se o efeito aconteceu, se o comprovante não aparece nem confirma nem nega, ou se a ação tem consequência financeira ou jurídica, a atitude correta é pausar e pedir confirmação.
A confirmação humana é o freio de segurança. Ela transfere para uma pessoa a decisão sobre repetir ou não, em situações que o agente não consegue resolver sozinho. Para ações de escrita sensíveis, esse freio vale mais do que qualquer heurística de retry.
Exemplo: transportadora em Goiânia (GO)
Uma transportadora em Goiânia automatiza o lançamento de notas fiscais em um portal do cliente. O portal derruba a sessão a cada 15 minutos e volta para o login. O agente, ao ser redirecionado, reautenticava e reenviava a nota que estava processando, sem checar se o envio anterior tinha entrado.
O resultado foi duplicidade de lançamentos. A mesma nota aparecia duas vezes na lista, o que bagunçava a conferência do cliente e gerava cobrança indevida. A equipe só notou ao comparar o volume lançado com o número de notas emitidas no dia.
A correção seguiu três mudanças. Primeiro, o agente passou a registrar cada passo com o número da nota e a marca de tempo. Segundo, antes de qualquer reenvio, ele procurar o comprovante do lançamento na lista do portal e só repete se não encontrar. Terceiro, quando o comprovante não aparece nem confirma nem nega, ele para e pede conferência humana. Sem números de resultado a apresentar, o ganho foi a queda dos lançamentos repetidos.
Erros comuns
- Clicar logo após um recarregamento, sem esperar a página estabilizar.
- Guardar referência de elementos e reutilizá-la depois que a página mudou.
- Reenviar um passo de escrita sem checar se o efeito já aconteceu.
- Tratar a ida para a tela de login como erro em vez de passo de reautenticação.
- Recomeçar o fluxo do zero depois de uma queda de sessão, refazendo tudo.
- Insistir em repetir quando não há comprovante e a ação é sensível.
Perguntas frequentes
Como o agente detecta que a página mudou?
Observando sinais concretos: elemento que sumiu, seletor que deixou de resolver, URL diferente da esperada e indicador de carregamento ativo. Qualquer um deles indica que o mapa da página anterior não vale mais.
Por que esperar por condição é melhor do que esperar por tempo?
Porque o tempo de resposta da rede varia. Esperar uma condição (loading terminar, elemento aparecer) verifica o estado real da página, enquanto uma pausa fixa pode terminar antes ou depois do ponto certo.
O que é idempotência aplicada a um agente de navegador?
É desenhar cada passo para que repeti-lo não cause efeito duplicado. Na prática, o agente consulta o resultado antes de refazer: procura o comprovante, o número do lançamento ou o e-mail enviado.
Como retomar uma tarefa após a sessão expirar?
Reautenticando pelo cofre de credenciais e lendo o registro de passos para continuar do último ponto concluído, sem refazer o que já deu certo.
Quando o agente deve parar e pedir ajuda humana?
Quando não consegue saber se o efeito aconteceu, quando o comprovante é inconclusivo, ou quando a ação tem consequência financeira ou jurídica. Pausar é mais seguro do que repetir no escuro.
Repetir um passo de leitura causa problema?
Não. Ler uma página ou consultar um valor pode ser repetido sem dano. O cuidado é com passos de escrita: enviar, salvar, lançar e pagar.
Fontes e leitura recomendada
- Documentação da Anthropic para Claude: uso de ferramentas e fluxo de agentes.
- Documentação de plataforma da OpenAI: conceitos de orquestração de ferramentas.
- Google AI for Developers: documentação de modelos Gemini e agentes.
- MDN: evento pageshow: quando uma página volta a ficar visível após recarregar ou vir do cache.
- MDN: evento visibilitychange: como detectar que a aba mudou de estado.
- WAI: WCAG 2.2, critério Timing Adjustable: boas práticas sobre limites de tempo em sessões.
Para aprofundar o assunto, veja o que são agentes autônomos de IA, como controlar permissões de agentes de IA e o guia sobre memória em agentes de IA.
