Todo time que entrega um sistema com agentes IA eventualmente faz a mesma pergunta, geralmente por volta do terceiro mês: "precisamos de Temporal / Inngest / Restate, ou podemos só adicionar retries?"
A resposta é quase sempre "você precisa do orquestrador durável, mas por um motivo que não é 'retries.'"
O que retries de fato resolvem
Retries são a ferramenta certa quando uma falha transiente é observada pelo mesmo processo que fez a chamada. Oscilação de rede, resposta de rate-limit, um downstream instável — quem chamou tem o resultado da falha na mão, sabe o que estava tentando fazer e pode simplesmente tentar de novo.
Para isto você precisa: uma política de retry com backoff exponencial, um teto de tentativas máximas, e idempotência no receptor. Isto é uma biblioteca, não um sistema. p-retry, tenacity, tokio-retry — escolha uma e siga em frente.
O que execução durável de fato resolve
Execução durável é a ferramenta certa quando o próprio processo pode morrer entre passos. Crash, deploy, k8s removendo o pod, uma chamada LLM de 30 minutos que excede seu timeout de requisição — a pergunta não é "podemos tentar de novo" mas "onde estávamos quando as luzes apagaram, e como retomamos sem refazer as partes que já tinham sucesso?"
Este é um problema fundamentalmente diferente. Precisa de:
- Estado persistente dos passos — um log de quais passos completaram, com seus resultados.
- Histórico replayable — quando o processo retoma, percorre o log, pula passos finalizados, e continua do primeiro não finalizado.
- Limites de passo determinísticos — código estruturado para que o orquestrador identifique passos sem ambiguidade entre replays.
Você pode escrever isto do zero. Pessoas fazem. São seis meses depurando condições de corrida antes de perceber que construiu uma versão pior do Temporal.
A decisão de fato
Se seu sistema com agentes IA tem:
- Chamadas de tool que levam mais de alguns segundos individualmente,
- Workflows com mais de ~3 passos sequenciais,
- Um handoff ou human-in-the-loop em algum lugar do meio,
- SLAs que não toleram um restart de deploy causando uma falha visível para o usuário,
…você precisa de um orquestrador durável. Não "você pode querer um para conveniências." Você precisa de um, e adicioná-lo depois será muito mais caro do que começar com ele.
Se seu sistema é curto, síncrono e sem estado (um prompt, uma resposta, pronto em 5 segundos), retries servem. Não exagere na engenharia.
O que entregamos
Na prática, nosso padrão é Temporal ou Restate (dependendo da stack de linguagem), com o código de workflow estruturado para que cada chamada LLM, invocação de tool e aprovação seja um passo separado. O custo é alguma curva de aprendizado e um runtime para operar. O benefício é que "o que acontece quando este processo crasha no meio do workflow" deixa de ser uma pergunta que temos que responder para cada nova feature — o orquestrador responde uma vez.
Retries resolvem "esta chamada falhou." Execução durável resolve "este workflow precisa sobreviver a falhas da coisa que o executa." Não são alternativas — a maioria dos sistemas em produção precisa de ambos, e é o segundo que as pessoas subestimam.