Fazer a automação sobreviver à segunda-feira sem duplicar registro

Um fluxo aprovado pelo time na sexta costuma quebrar na segunda.

Um banner de cookies apareceu no meio do caminho. A rede ficou meio segundo mais lenta. Um botão desceu dois pixels porque o time de produto adicionou um selo de promoção. Nenhuma dessas coisas é anormal: é assim que a web se comporta. O que estava anormal era o roteiro, que assumia um mundo parado.

Existe um estrago pior que a quebra, porque ele não aparece como erro. O agente (o assistente de IA que opera o navegador por você) envia um formulário, a requisição chega ao servidor, o registro é criado, e a resposta se perde antes de voltar. O cliente vê apenas silêncio, conclui que falhou e repete. Agora existem dois leads idênticos no CRM, dois pedidos, duas cobranças.

O caso caro é a requisição que funcionou e cuja resposta se perdeu; a que falhou pelo menos avisa.

Antes de qualquer regra, veja o mecanismo, que é simples. O tempo esgotado do lado do cliente não cancela nada do lado do servidor. Ele apenas encerra a espera. O efeito colateral no destino já aconteceu, e o cliente não tem como saber.

É por isso que a proteção contra duplicidade não pode morar na sua disciplina de não repetir. Ela precisa morar no protocolo da chamada.

Comece pela espera, porque é o erro mais comum e o mais barato de corrigir. Dormir três segundos parece razoável até você perceber que o número está errado nos dois sentidos ao mesmo tempo.

Na rede lenta, três segundos são curtos demais e o passo seguinte age sobre uma página que ainda não terminou de responder. Na rede rápida, são desperdício puro, multiplicado por centenas de passos até virar minutos de espera por execução.

A segunda fonte de fragilidade é onde você aponta. Um seletor CSS profundo descreve o caminho até o elemento dentro de uma estrutura que muda toda semana. Uma coordenada de pixel descreve onde o elemento estava numa janela daquele tamanho, naquele dia.

Papel, rótulo acessível e texto visível descrevem outra coisa: a intenção. Um botão chamado "Salvar cadastro" continua sendo esse botão depois do redesenho, porque o nome é justamente o que o produto não muda por acaso.

Agora a escrita. Uma operação é idempotente quando executá-la duas vezes produz o mesmo resultado que executá-la uma. Ler é idempotente por natureza. Criar registro não é, a menos que alguém no caminho saiba reconhecer que aquela criação já aconteceu.

A chave de idempotência é esse reconhecimento. Ela nasce antes da primeira tentativa, viaja em toda repetição e permite ao destino devolver o registro original em vez de criar um irmão gêmeo.

Falta a parte que quase ninguém escreve: o que o agente faz quando o mundo não colabora. A tentação é deixar o modelo improvisar um caminho alternativo, e nesse improviso ele clica em coisas que você nunca autorizou.

Calibre a expectativa pelos números. O estudo do Online-Mind2Web mediu agentes em 300 tarefas cotidianas sobre 136 sites reais: o melhor concluiu 61,3% e a maioria ficou perto de 30%, enquanto humanos ficam perto do total. Placares comerciais de 2026 reportam números bem mais altos, com metodologias que não são comparáveis entre si.

Tarefa deste módulo. No perfil de laboratório que você montou no módulo 3, construa um fluxo de três a cinco passos com pelo menos uma escrita, contendo os três elementos obrigatórios: nenhuma espera por tempo fixo, ponto de verificação depois de cada passo, e chave de idempotência na escrita.

Rode três vezes seguidas, de propósito. Depois remova do ambiente um elemento que o roteiro espera (esconda o botão pelo DevTools, por exemplo) e rode de novo para forçar a desistência. O teste passou quando o destino termina com um registro só e a quarta execução para com a mensagem de desistência, sem escrever nada.