Por que seu agente de IA tem 95% de chance de falhar em produção — e o que fazer sobre isso

Jonathan Souza · 2026-04-18 · 6 min

TL;DR: Um agente com 5 passos a 99% de sucesso cada tem apenas 95% de confiabilidade total. Essa conta mata agentes em produção. Execução durável resolve porque persiste estado a cada passo, faz retry granular e permite que o agente retome de onde parou — sem recomeçar do zero.

O problema: a matemática que mata agentes de IA em produção

Seu time construiu um agente de aprovação de crédito. O protótipo funciona: analisa documentos, consulta o bureau, toma uma decisão preliminar, escala para humano quando não tem certeza. Duas semanas de desenvolvimento. Demo impecável. O CEO aprovou.

Três meses em produção, e o quadro é outro.

O agente trava no meio de uma análise porque a API do bureau deu timeout. Ninguém sabe em que estado ficou. O documento já foi processado? A consulta já retornou? O bureau já cobrou? O agente precisa recomeçar do zero — mas a consulta ao bureau já foi paga.

E aqui entra a matemática que ninguém mostra no pitch do LLM.

Se cada passo do seu agente tem 99% de sucesso — e 99% é generoso para chamadas a APIs externas, LLMs e bancos de dados — a confiabilidade total de um agente com 5 passos é:

0.99 × 0.99 × 0.99 × 0.99 × 0.99 = 0.9510 → 95,1%

A cascata de falha composicional: 5 passos a 99% cada resultam em 95% de confiabilidade total — cada passo multiplica a probabilidade, e a queda acumula passo a passo

Cinco por cento de falha. Em 1.000 execuções por dia, são 50 agentes falhando. Todo dia. Silenciosamente. É o que a Inngest chamou de compositional failure — e é a razão pela qual a maioria dos agentes de IA construídos hoje não sobrevive ao contato com produção.

Com 10 passos? A confiabilidade cai para 90,4%. Com 15? 86%. A conta é implacável.

E o problema não é o LLM. O problema é tudo ao redor dele: a chamada de API que dá timeout, o banco que fica lento sob carga, a fila que perde a mensagem, a conexão que cai entre o passo 3 e o passo 4.

A armadilha do wrapper: por que LangChain + if/else não escala

O protótipo típico de um agente de IA segue um padrão previsível:

// O protótipo que funciona no demo
public async Task<DecisaoCredito> AnalisarCredito(Documento doc)
{
    // Passo 1: análise de documento via LLM
    var analise = await _llmClient.AnalisarDocumento(doc);

    // Passo 2: consulta ao bureau de crédito
    var score = await _bureauClient.ConsultarScore(doc.CPF);

    // Passo 3: decisão preliminar
    var decisao = await _llmClient.TomarDecisao(analise, score);

    // Passo 4: se incerto, escala para humano
    if (decisao.Confianca < 0.85)
    {
        // TODO: como esperar o humano responder?
        // TODO: e se o serviço reiniciar enquanto espera?
        // TODO: e se o humano demorar 3 dias?
    }

    return decisao;
}

Funciona. No demo. Com um request por vez. Sem falhas de rede. Sem timeout. Sem deploys.

O time tenta escalar: adiciona retry manual com Polly. Estado em banco de dados. Uma fila para a parte assíncrona. Logging custom para saber onde o agente parou. Um cron job para limpar execuções órfãs.

Em 6 meses, o "agente de IA" virou um monolito de infraestrutura mais complexo que o sistema que ele deveria automatizar. O time que deveria estar melhorando a inteligência do agente gasta 60% do tempo mantendo encanamento de retry, estado e filas.

Isso é a armadilha do wrapper. O wrapper de LLM resolve o problema errado: encapsula a chamada ao modelo, mas ignora que o difícil não é chamar o LLM — é garantir que os 5, 10 ou 15 passos ao redor dele executem de forma confiável, recuperável e auditável.

O que muda com execução durável: cada passo persiste, cada falha recupera

Execução durável resolve a falha composicional na raiz. Em vez de tratar o agente como um método que roda do início ao fim (e recomeça do zero quando falha), cada passo é persistido individualmente. Se o passo 3 falha, o agente retoma do passo 3 — não do passo 1.

Onde o estado vive: no wrapper, estado fica em memória (perdido no crash) — em execução durável, estado é persistido a cada passo (sobrevive a qualquer coisa)

A diferença é arquitetural. Com um wrapper, o estado do agente vive em memória. Se o processo reinicia, o estado desaparece. Com execução durável, o estado é persistido linha a linha. O processo pode cair, reiniciar, ser redistribuído entre servidores — o agente retoma exatamente de onde parou.

Veja o mesmo agente de aprovação de crédito, agora com skail:

// Agente de aprovação de crédito com execução durável
[SkailFunction]
public async Task<DecisaoCredito> AnalisarCredito(Documento doc)
{
    // Passo 1: análise via LLM — persistido automaticamente
    var analise = await ctx.CallCommand(
        new AnalisarDocumentoCommand(doc));

    // Passo 2: consulta ao bureau — retry automático com backoff
    var score = await ctx.CallCommand(
        new ConsultarBureauCommand(doc.CPF));

    // Passo 3: decisão preliminar
    var decisao = await ctx.CallCommand(
        new TomarDecisaoCommand(analise, score));

    // Passo 4: se incerto, espera aprovação humana
    // O agente hiberna sem custo — retoma quando o humano responde
    if (decisao.Confianca < 0.85)
    {
        var aprovacao = await ctx.WaitForEvent<AprovacaoHumana>(
            timeout: TimeSpan.FromDays(7));

        if (aprovacao == null)
            return DecisaoCredito.Expirada();

        decisao = decisao.ComAprovacao(aprovacao);
    }

    return decisao;
}

[SkailCommand]
public async Task<Analise> AnalisarDocumentoCommand(Documento doc)
{
    // Cada comando é retried independentemente
    // Se a chamada ao LLM falha, só ESTE passo é reexecutado
    return await _llmClient.AnalisarDocumento(doc);
}

[SkailCommand]
public async Task<ScoreBureau> ConsultarBureauCommand(string cpf)
{
    // Retry automático com backoff exponencial
    // Se o bureau cobra pela consulta, o estado persistido
    // garante que não consultamos duas vezes
    return await _bureauClient.ConsultarScore(cpf);
}

Cada [SkailCommand] é uma unidade de execução durável. Se a consulta ao bureau dá timeout, o skail faz retry automático — mas só daquele passo. O passo 1 (análise de documento) já executou e está salvo. O bureau não é consultado novamente desnecessariamente.

O WaitForEvent resolve o problema mais difícil dos agentes: esperar intervenção humana. O agente hiberna sem consumir recursos. Se o humano demora 3 dias, 3 semanas ou 3 meses, o agente retoma exatamente de onde parou — com todo o contexto preservado.

A linha do tempo de execução: abordagem wrapper (falha → recomeça do zero, bureau cobra de novo) vs abordagem durável (falha → retoma do checkpoint, nenhum passo duplicado)

A validação do mercado: todos convergindo para a mesma resposta

Isso não é uma aposta teórica. O mercado inteiro está convergindo para a mesma conclusão.

A Temporal levantou US$ 300 milhões em 2025 nomeando AI como caso de uso principal. A Inngest lançou o AgentKit — execução durável projetada especificamente para agentes. A Trigger.dev lançou Waitpoints na v4 para human-in-the-loop com persistência de estado.

Três plataformas diferentes. Três empresas diferentes. A mesma resposta: agentes de IA precisam de execução durável.

Como Jonathan Souza coloca: "O LLM serve como o cérebro que interpreta estímulos, mas a execução das ações deve ser previsível e determinística." O LLM decide o que fazer. A execução durável garante que o "fazer" aconteça de forma confiável — com retry, persistência e auditabilidade.

Leôncio Torres complementa: "Os N1 do NOC poderiam ser agentes autônomos se essa infraestrutura estivesse pronta." A infraestrutura é o gargalo, não a inteligência artificial.

O que seu agente ganha com execução durável

Voltando ao agente de aprovação de crédito. Com execução durável, a matemática muda:

Sem execução durável:

5 passos × 99% = 95,1% de sucesso
50 falhas a cada 1.000 execuções
Cada falha = recomeçar do zero + bureau cobrado novamente + estado perdido

Com execução durável:

Cada passo tem retry automático com backoff
Falha no passo 3? Retoma do passo 3, não do passo 1
Estado persistido: zero duplicação de chamadas pagas
Human-in-the-loop nativo: o agente hiberna e retoma quando o humano decide
Visibilidade total: "Agente #4521 — Documento analisado (ok) → Bureau consultado (timeout, retry 2/3) → Aguardando aprovação humana"

O dev que sabe C# já sabe construir esse agente. Não precisa aprender uma linguagem de orquestração. Não precisa de cluster dedicado. Não precisa de time de plataforma. Dois atributos — [SkailFunction] e [SkailCommand] — e o agente ganha durabilidade, retry e persistência de estado.

A documentação completa de SkailFunction e SkailCommand mostra cada primitiva. Os exemplos de código incluem padrões como approval com timeout, saga com compensação e fan-out/fan-in — todos aplicáveis diretamente a agentes de IA.

Conclusão

A falha composicional não é um bug — é uma propriedade matemática de sistemas com múltiplos passos. Não importa quão bom é o seu LLM. Se os 5 passos ao redor dele não são duráveis, seu agente tem 95% de chance de funcionar. E 5% de chance de falhar silenciosamente, perder estado e custar dinheiro a cada execução.

Execução durável não é uma feature. É a infraestrutura mínima para agentes de IA em produção.

Se o seu time está construindo agentes e ainda está montando infraestrutura manual de retry e estado, vale conhecer como a execução durável funciona na prática. A documentação do skail é um bom ponto de partida — 10 minutos do setup ao primeiro deploy.