Taxas de falha compostas em agentes multi-etapas são brutais — isso já estabelecemos. Um workflow de sete etapas com 95% de confiabilidade por etapa dá uns 70% de ponta a ponta. Três de cada dez execuções explodem. Mas aqui está a parte que ninguém resolve: quando a etapa quatro retorna um HTTP 500, o que acontece com as três etapas que já rodaram? A mensagem no Slack já foi enviada, a linha no banco já foi escrita, o ticket no Jira já foi criado. Seu agente não sabe quais etapas foram concluídas. Ele não tem checkpoint — nenhuma posição salva pra retomar. E não tem lógica de compensação — nenhum "desfazer" automático pra trabalho feito pela metade.

Ver a taxa de falha é o passo um. Sobreviver à falha é o passo dois. Ninguém entrega o passo dois.

Teatro da Recuperação

Os três principais runtimes de agentes lançaram features de recuperação neste abril. Nenhum deles realmente resolve recuperação.

O Managed Agents da Anthropic (8 de abril) usa um log de eventos append-only — um diário de escrita única de tudo que o agente fez. Crashou? Reinicia, relê o diário, continua. O time de engenharia deles: "Nada no harness precisa sobreviver a um crash." Parece resiliente. Mas não tem dead-letter queue pra tarefas com falha, nenhuma garantia de exactly-once de que cada ação roda uma e apenas uma vez, e nenhuma forma de reverter efeitos colaterais já concluídos.

A atualização do Agents SDK da OpenAI (15 de abril) adicionou snapshotting e reidratação — salvando e restaurando o estado do agente entre reinicializações de container. Mas persiste histórico de mensagens, não estado de execução. O modelo lembra o que disse; não rastreia o que fez.

O Google ADK (anunciado no Cloud Next, 22 de abril) traz SequentialAgent, ParallelAgent, LoopAgent e um ResumabilityConfig. As letras miúdas: o chamador precisa detectar a interrupção e re-invocar manualmente. Sem recuperação automática.

Três abordagens diferentes pra durabilidade. Todas três modelam execução como loops de inferência — "pensa → chama ferramenta → observa → repete." Nenhuma modela como uma máquina de estados durável — um sistema que rastreia exatamente em qual estado está e quais transições são válidas, tipo uma máquina de refrigerante que lembra que você já colocou a moeda mesmo depois de uma queda de energia.

As Soluções que Já Existem (Fora da IA)

Engines de workflow resolveram execução durável uma década atrás. A indústria de IA só ainda não adotou.

O Temporal encapsula cada etapa em uma atividade retentável e reproduzível. Crashou no meio do workflow? O Temporal reproduz a partir da última atividade concluída — não do zero. Veja como fica uma etapa de agente envolvida pelo Temporal:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal retenta isso automaticamente em caso de falha.
    Se o agente crashar no meio do workflow, reproduz
    a partir da última atividade concluída — não do zero."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # previne tickets duplicados
    )

Aquela idempotency_key — um ID único que garante que a mesma requisição não execute duas vezes — é a diferença inteira entre "pronto pra produção" e "demo impressionante."

O Project Think da Cloudflare (15 de abril) tomou uma rota completamente diferente: bancos SQLite por agente, checkpoints step.do() e hibernação com custo zero. Cada agente é uma entidade durável isolada com seu próprio estado persistente, não um job num orquestrador centralizado. Pra times que já estão nos Cloudflare Workers, esse é provavelmente o caminho mais limpo — sem engine de workflow externo, sem message broker, apenas durable objects com checkpointing embutido.

O Restate fica entre os dois: mais leve que o Temporal, mais estruturado que durable objects crus. Oferece garantias de exactly-once com um mecanismo de replay baseado em journal, e publicou padrões de integração direta com o Google ADK.

O Meio-Termo Desconfortável

Aqui está o problema que ninguém quer reconhecer: a lacuna funciona nos dois sentidos.

Engines de workflow não falam LLM. Não entendem token budgets — quanto texto uma IA consegue processar por chamada. Não conseguem lidar com fallback routing de modelos — trocar pra um modelo mais barato quando o caro bate nos rate limits. Não têm conceito de versionamento de prompts, gerenciamento de janela de contexto ou evolução de schema de tool-call. Parafusar agentes no Temporal significa escrever uma camada de tradução entre "etapa de workflow" e "chamada de inferência" — e manter isso toda vez que seu provedor de modelo muda a API.

Plataformas de agentes não entendem durabilidade. Tratam chamadas de ferramentas como efeitos colaterais efêmeros da inferência, não como transições de estado que precisam de garantias transacionais. Um LLM chamando uma ferramenta é filosoficamente diferente de uma etapa de workflow chamando uma função: o LLM pode decidir chamar a ferramenta de novo, chamar uma ferramenta diferente, ou alucinar uma ferramenta que não existe. Engines de workflow assumem definições de etapas determinísticas. LLMs são, por definição, não-determinísticos.

Nenhum dos dois lados está errado. Estão resolvendo metades diferentes do mesmo problema.

O Que Isso Significa pra Você

Se seu agente modifica estado externo em mais de três etapas — envia emails, escreve em bancos de dados, chama APIs de terceiros — você já precisa de garantias de engine de workflow. Sua plataforma de agentes não fornece isso. Você tem três opções:

  1. Parafusar Temporal/Restate você mesmo. Complexidade real de integração, mas durabilidade testada em batalha. Vale a pena se você roda agentes em produção com SLAs de verdade.
  2. Ir full Cloudflare. Se já está nos Workers, o Project Think te dá agentes duráveis sem o overhead de orquestração. Contrapartida: lock-in de plataforma.
  3. Aceitar a taxa de falha e construir ferramentas de reconciliação manual. Honestamente, pra ferramentas internas com usuários tolerantes, isso pode ser racional. Só não chame de "pronto pra produção."

A convergência é inevitável. O primeiro vendor a entregar execução de máquina de estados durável como primitiva padrão de agentes — não como gambiarra tardia, não como integração de terceiro — domina a camada de confiabilidade de produção acima dos três runtimes. O Temporal sabe disso; a integração deles com o OpenAI Agents SDK é uma corrida pra plantar bandeira. A Cloudflare sabe disso; o Project Think foi desenhado pra tornar agentes uma feature de plataforma.

Sua demo de sete etapas ainda funciona lindamente. Levar pra produção ainda significa escolher qual modo de falha você aceita conviver.