Retries existem porque o mundo real falha: timeout, rede instável, serviço lento, fila que reentrega, dependência que volta. Em sistemas tradicionais, retry é quase sempre uma virtude: melhora disponibilidade e reduz incidentes.
Em sistemas com agentes, o retry muda de natureza quando há efeito colateral. Enviar e-mail, criar ticket, bloquear conta, disparar cobrança, alterar cadastro, acionar runbook — isso não é “resposta”. É ação. E ação repetida não é “o mesmo” duas vezes; é duas vezes.
A falha clássica é tratar retry como detalhe técnico e depois descobrir que ele virou um multiplicador de dano.
O desafio — Fazer o sistema saber a diferença entre “repetir leitura” e “repetir ação”
Em agentic AI, o sistema precisa distinguir dois tipos de passos:
Passos que são seguros de repetir (consultas, leituras, cálculos, simulações).
Passos que são perigosos de repetir (qualquer coisa que muda estado externo).
Quando essa distinção não existe no desenho, o retry vira loteria: às vezes ajuda, às vezes duplica efeitos. E quando duplica efeitos em escala, você ganha um tipo de incidente que parece pequeno por evento, mas grande por volume: clientes recebendo mensagens repetidas, operações recebendo tickets duplicados, reversões manuais, perda de confiança.
O desafio é estrutural: colocar a fronteira de efeito colateral como parte do controle de fluxo do agente, não como “boa prática” no código.
O cenário — Um agente que “se recupera” duplicando o problema
Um agente de suporte cria tickets e envia follow-ups automáticos. Um dia, o provedor de e-mail fica lento. A chamada dá timeout. O agente assume falha e tenta de novo. O wrapper da ferramenta também tem retry. A fila reentrega a mensagem porque não recebeu ack. O sistema “se recupera” — mas o cliente recebe dois e-mails, o time recebe dois tickets, e a operação vira limpeza.
Nada foi “malicioso”. Foi só retry em lugares diferentes, sem uma regra única do que é permitido repetir. O custo aparece depois, como intervenção humana, reclamação e desgaste.
Visão AI — Retentar melhora confiabilidade; basta limitar tentativas
Na visão otimização-primeiro, retry é parte do kit de confiabilidade. Se falhou, tenta de novo. Se ainda falhou, tenta mais uma vez. Limita-se o número de tentativas, e pronto. Para muitos sistemas isso é correto.
O problema é quando a mesma lógica é aplicada a ações com efeito colateral. Nelas, “tentar de novo” é “agir de novo”. Limitar tentativas reduz o dano, mas não elimina o risco estrutural, porque o retry pode estar duplicado em camadas (cliente, SDK, gateway, fila) e porque a ação pode ter sido executada mesmo quando a resposta falhou.
Visão WM — Retry em ação com efeito colateral exige corredor, prova e idempotência
Na visão WM, retry em ação com efeito colateral é um evento de governança. Ele precisa de três coisas para ser seguro.
Primeiro, um corredor explícito: o sistema precisa classificar ações por tipo (leitura vs efeito colateral) e aplicar políticas diferentes de retry. Em leitura, retry pode ser agressivo. Em efeito colateral, retry precisa ser conservador e condicionado.
Segundo, prova de execução: o sistema precisa conseguir responder se a ação foi ou não foi executada, mesmo quando a resposta não voltou. Sem determinabilidade, o retry vira aposta. E aposta não escala.
Terceiro, idempotência real: quando a ação é repetida, ela precisa se comportar como repetição e não como nova execução. Isso é mais do que “não duplicar”; é garantir que o mundo externo não mude duas vezes. A chave estável (idempotency key) e o registro do fato são parte do produto, não um detalhe de implementação.
O ponto central é que retry precisa virar decisão controlada. “Vamos tentar de novo” só é aceitável quando o sistema também consegue dizer “e isso não vai agir duas vezes”.
Síntese final — Como reconhecer quando retries estão virando um multiplicador de dano
O sinal não aparece em dashboards clássicos. Ele aparece como ruído operacional: duplicidade, reconciliação manual, pedidos de estorno, mensagens repetidas, tickets em cascata, reclamações de insistência. Em geral, a organização trata como casos isolados, até perceber que é um padrão.
O teste de maturidade é perguntar: o que acontece quando a chamada falha depois de executar? Se a resposta for “a gente tenta de novo”, então o sistema está assumindo que o mundo é atômico — e ele não é. Se a resposta for “a gente verifica o fato e só repete de forma idempotente”, então o sistema está tratando ação como autoridade.
Em produção, retries bem desenhados aumentam confiabilidade. Retries mal desenhados aumentam dano. A diferença não é o número de tentativas. É a geometria do efeito colateral.
O que ainda poderia melhorar — sinais de próxima maturidade
Ainda faltaria padronizar uma taxonomia de ações por risco e efeito colateral que atravessasse toda a stack, para que o retry não seja decidido “por biblioteca” e sim por política. Também faltaria tornar visível onde o retry está acontecendo (cliente, gateway, fila, ferramenta) e como essas camadas se somam, para que a organização pare de descobrir duplicidade apenas pelo impacto.
Por fim, faltaria ligar retries a coortes e contestação: em quais segmentos o retry concentra dano, quais ações deveriam automaticamente mudar para modo de hesitação (abster-se e escalar) após certas falhas, e quais evidências precisam ser preservadas para provar que o sistema não “agiu duas vezes” quando o mundo ficou instável.