Quando a sessão do navegador expira, um agente de IA deve suspender ações que alteram dados, registrar o ponto alcançado e restabelecer o acesso pelo fluxo autorizado. Antes de retomar, precisa descobrir se a última ação já aconteceu no sistema. Fazer login novamente e repetir o último clique pode duplicar um pedido, uma mensagem ou uma publicação.
A recuperação segura separa três problemas: autenticar a pessoa ou conta correta, reconstruir a navegação e reconciliar os efeitos da tarefa. Este guia trata dessa retomada no navegador. A troca ou renovação de credenciais de serviços é outro assunto; aqui o foco é continuar uma operação interrompida sem perder contexto nem executar duas vezes a mesma ação.
Resumo rápido
- Detecte o fim da sessão por sinais combinados, não apenas pelo endereço da página.
- Congele novas alterações e guarde um ponto de recuperação sem segredos.
- Use o login autorizado e encaminhe verificações humanas ao responsável.
- Confirme usuário, empresa e ambiente depois do acesso.
- Consulte o resultado da última ação antes de repeti-la.
Como reconhecer que o acesso realmente terminou
Uma página de login no lugar do painel é um sinal forte, mas não explica sozinha o ocorrido. O portal pode ter redirecionado para outra conta, pedido uma confirmação adicional ou apresentado uma tela intermediária. Uma interface travada também pode decorrer de rede, carregamento ou erro do próprio serviço.
Combine a presença de elementos de autenticação, a ausência de um indicador conhecido de usuário e o resultado das requisições relevantes. O padrão HTTP associa 401 à necessidade de autenticação válida e distingue essa resposta de 403, que indica recusa de atendimento. Consulte a RFC 9110. Não transforme qualquer erro em uma sequência automática de tentativas de login.
Na regra da aplicação, reconheça somente origens e telas esperadas. Se a automação encontra um formulário em domínio diferente do autorizado, pare e encaminhe a análise. A tarefa não justifica preencher senha em qualquer página que se apresente como continuação do fluxo. Registre a transição observada sem copiar dados sensíveis.
Considere também que sessão ativa não significa permissão suficiente para toda ação. Um usuário pode consultar pedidos e não poder aprová-los. Se a tela está autenticada, mas a operação foi negada, preserve o diagnóstico de autorização. Reautenticar indefinidamente não corrige uma permissão ausente.
O ponto de recuperação que permite continuar
Um ponto de recuperação é um registro durável do progresso da tarefa. Ele deve permitir que outra execução entenda o que já foi confirmado, o que estava em andamento e quais evidências faltam. Não basta guardar a última URL: a mesma página pode atender empresas, períodos ou objetos diferentes.
Inclua o identificador da tarefa, a conta esperada, a organização, o ambiente e o objeto de negócio. Registre os filtros aplicados e a última etapa concluída com evidência. Para uma ação iniciada, anote um estado como “resultado ainda não confirmado”, em vez de marcar falha apenas porque a interface deixou de responder.
Uma estrutura simples pode distinguir consulta, preparacao, envio_iniciado, resultado_confirmado e revisao_necessaria. Esses nomes são uma proposta operacional, não uma exigência de ferramenta. O benefício é impedir que o agente confunda ausência de confirmação com prova de que nada ocorreu.
Evite armazenar senhas, cookies, códigos de verificação e URLs com tokens no ponto de recuperação. Se uma captura de tela for necessária, limite o conteúdo e o acesso. O registro de negócio deve continuar útil mesmo quando o material de autenticação é descartado ou renovado.
A definição dessas etapas pode acompanhar a documentação do processo executado pelo agente. Descreva qual consulta comprova cada transição. “Pedido encontrado com o identificador esperado” é uma evidência mais verificável que “pareceu funcionar”.
Restabelecer a sessão sem perder o controle da conta
Use o mecanismo de autenticação já aprovado para aquela operação. Quando houver autenticação multifator ou desafio que dependa de uma pessoa, suspenda a tarefa e informe exatamente o que falta. Não peça ao modelo para adivinhar códigos nem tente substituir o responsável usando dados encontrados em conversas antigas.
A OWASP diferencia expiração por inatividade de expiração absoluta e recomenda controle de sessão no servidor. Por isso, manter uma aba aberta ou produzir cliques periódicos não garante uma sessão válida. A explicação está no guia de gerenciamento de sessão da OWASP.
Depois de autenticar, faça uma verificação curta: usuário esperado, empresa correta, ambiente de produção ou teste e permissões necessárias. Só então reconstrua a navegação. Um portal que abre a última empresa utilizada pode levar o agente ao lugar errado mesmo após um login bem-sucedido.
Em automações com Playwright, o estado de autenticação pode ser reutilizado quando apropriado. A documentação alerta que o arquivo de estado pode conter cookies e cabeçalhos sensíveis capazes de representar a conta. Proteja esse material e mantenha-o fora de repositórios, conforme a documentação oficial de autenticação. Reutilizar estado não substitui conferir se o acesso continua válido.
Prefira manter contexto de navegação isolado por conta e finalidade. Compartilhar um perfil sem controle entre execuções dificulta saber quem alterou a sessão ou trocou a organização ativa. Se for necessário compartilhar recursos, estabeleça exclusividade durante a recuperação e registre qual execução assumiu a tarefa.
Decidir o que pode ser repetido
| Situação interrompida | Primeira providência | Condição para continuar |
|---|---|---|
| Leitura de uma lista | Reabrir e reaplicar filtros | Conta e escopo confirmados |
| Formulário ainda não enviado | Conferir rascunho e dados | Ausência de envio confirmada |
| Envio com resultado desconhecido | Consultar histórico ou objeto criado | Resultado reconciliado |
| Objeto já encontrado | Validar identidade e conteúdo | Registrar conclusão sem reenviar |
| Resultado impossível de verificar | Encaminhar revisão | Decisão do responsável |
Para consultas, retomar normalmente envolve reconstruir filtros e posição. Mesmo assim, uma lista pode ter mudado enquanto a sessão estava encerrada. Prefira identificar objetos por chave de negócio em vez de confiar na posição visual de uma linha. “Terceiro pedido da tela” deixa de ser uma referência confiável depois de uma atualização.
Para ações que criam ou alteram objetos, consulte o sistema antes de repetir. Procure um número de pedido, identificador de mensagem, rascunho ou evento de histórico. Compare também os campos relevantes. Encontrar um registro com título parecido não comprova que ele corresponde à operação interrompida.
Se houver uma API autorizada com suporte documentado a idempotência, a integração pode usar o mecanismo previsto pelo fornecedor. A Stripe, por exemplo, documenta chaves para requisições idempotentes em sua API. Isso aparece na referência oficial da Stripe. Esse suporte não deve ser presumido em botões de navegador ou em outros serviços.
Na rotina de recuperação, uma chave local ajuda a reconhecer a intenção, mas só impede duplicação no destino se o destino participar desse contrato. Sem essa garantia, consultar o resultado e eventualmente encaminhar revisão continua necessário. O agente não deve anunciar execução única apenas porque sua própria tabela não contém duplicatas.
Um roteiro de retomada para a equipe
- Suspender: interrompa novos envios e marque a tarefa como aguardando recuperação.
- Registrar: preserve o objeto, os filtros e a última evidência confirmada.
- Autenticar: restabeleça acesso pelo fluxo autorizado, com intervenção humana quando exigida.
- Conferir: valide usuário, organização e ambiente.
- Reconciliar: consulte os efeitos da operação que ficou sem confirmação.
- Continuar: avance da próxima etapa comprovadamente pendente.
Defina limites de repetição para esse roteiro. Uma nova expiração durante a recuperação pode indicar que a execução está usando o perfil errado, que o acesso foi revogado ou que o fluxo exige revisão. O limite precisa ser escolhido pela operação; não existe um número universal adequado a todos os portais.
Registre tempos e causas sem transformar o monitoramento em cópia da sessão. Um evento útil informa tarefa, etapa, motivo de suspensão e decisão de retomada. Tokens de acesso e conteúdo integral de formulários geralmente não são necessários para entender o incidente.
Inclua testes com expiração antes do envio, depois do envio e durante a confirmação. O caso mais relevante é aquele em que a ação chegou ao sistema, mas o navegador não mostrou sucesso. O agente precisa localizar o resultado existente e continuar sem criar outro. Veja também o guia de testes de agentes antes da produção.
Exemplo: distribuidora de alimentos em Recife
Em um exemplo brasileiro ilustrativo, uma distribuidora de Recife usa um agente para preparar pedidos no portal de um fornecedor. O responsável já autorizou o fluxo e definiu quais pedidos o agente pode enviar. Cada tarefa registra cliente interno, produtos e referência de compra.
O agente envia um pedido e recebe uma tela de login antes de ler a confirmação. O ponto de recuperação fica como “envio iniciado, resultado desconhecido”. Em vez de montar outro pedido, ele suspende alterações. O responsável conclui a autenticação exigida pelo portal.
Após o acesso, o agente confirma a empresa ativa e abre o histórico de pedidos. Encontra um registro com a referência esperada, confere os itens e salva o número confirmado. A próxima etapa passa a ser comunicar o resultado, sem novo envio. Se a busca não fosse conclusiva, o caso seguiria para revisão antes de uma repetição.
O exemplo não supõe taxas de erro ou ganhos financeiros. Ele mostra uma decisão operacional: recuperar o acesso e verificar o efeito são passos diferentes. Para tarefas com consequências externas, combine esse desenho com padrões de aprovação humana adequados ao negócio.
Erros comuns
- Repetir o último clique: uma resposta perdida não demonstra ausência de execução. Consulte o histórico.
- Restaurar somente a URL: empresa e filtros podem ter mudado. Reconstrua o escopo.
- Salvar cookies na conversa: o registro de progresso não deve carregar material que representa a conta.
- Ignorar a troca de usuário: valide identidade depois de cada recuperação.
- Insistir em login diante de falta de permissão: diferencie autenticação de autorização.
- Confundir rascunho com envio: registre qual estado o sistema realmente confirmou.
Outra falha é declarar a tarefa encerrada assim que o painel reaparece. O acesso recuperado apenas permite continuar a análise. A conclusão depende do resultado de negócio solicitado e das evidências que a equipe definiu para aceitá-lo.
Perguntas frequentes
Uma aba aberta mantém a sessão ativa?
Não é uma garantia. O servidor pode aplicar expiração independentemente da aba. A automação deve reconhecer a perda de acesso e usar o fluxo de recuperação previsto.
Posso reutilizar um arquivo de autenticação?
Quando o desenho da ferramenta e a política da operação permitirem, sim. Proteja o arquivo como material sensível e valide o estado da sessão antes de executar alterações.
O que fazer se o envio sumiu da tela?
Marque o resultado como desconhecido e consulte o histórico ou o objeto de destino. Se não houver evidência suficiente, encaminhe revisão antes de enviar outra vez.
Todo erro 403 pede novo login?
Não. A resposta pode representar uma recusa de autorização. Verifique a causa no contexto da aplicação e evite ciclos de autenticação que não alteram a permissão disponível.
Como retomar quando o portal não tem histórico?
Procure outra evidência autorizada, como o objeto criado ou a confirmação registrada. Se o resultado continuar incerto, peça uma decisão ao responsável e explique o risco de repetição.
