Failure recovery em agentes de IA: o que muda quando o modelo tenta de novo em vez de parar

Fala aí, beleza? Existe um segundo, logo depois que uma ferramenta devolve erro, que decide o destino da tarefa inteira

Ou o modelo entende o que aconteceu e escolhe outro caminho, ou ele repete a mesma chamada quebrada até o turno morrer e sobrar pra você terminar na mão

Esse comportamento tem nome agora: failure recovery, ou seja, diagnosticar o erro da chamada de ferramenta e tentar de novo em vez de parar

E virou assunto de benchmark porque a régua mudou: não basta o agente acertar quando tudo está bonito, ele precisa se comportar quando a API muda, o retorno vem estranho ou a execução simplesmente falha

Bora destrinchar o que os testes mostram, e o que isso muda no desenho do seu fluxo

O que é failure recovery em um agente de IA

É o pedaço do comportamento do agente que entra em cena DEPOIS do erro

São três movimentos encadeados: perceber que a chamada de ferramenta falhou, classificar que tipo de falha foi aquela, e escolher a ação seguinte

Os caminhos de recuperação considerados válidos na literatura recente são quatro: tentar de novo, fallback (ir por outra ferramenta ou outra rota), verificação e checagem cruzada

Se você conhece tratamento de exceção em código, a analogia é quase direta: o try é a chamada da ferramenta, e o failure recovery é o catch que o modelo escreve sozinho, na hora, sem ninguém ter previsto aquele erro específico

A diferença é que o catch de código é determinístico, e o do agente depende de ele ter diagnosticado certo o que quebrou

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 108 aulas
• 4 projetos
• 9h

Conhecer formação

ToolBench-X: injetar a falha e garantir que ela tem saída

O ToolBench-X injeta tipos estruturados de falha no ambiente de ferramentas

São cinco tipos: Specification Drift, Invocation Error, Execution Failure, Output Drift e Cross-source Conflict

O detalhe que faz o benchmark valer: toda instância injetada continua resolvível por pelo menos um caminho válido de recuperação

Ou seja, quando o agente falha ali, não é porque a tarefa era impossível, é porque ele não achou a saída que existia 😅

ToolMaze: separar "tarefa difícil" de "ferramenta quebrada"

O ToolMaze ataca outro problema de medição

Quando um agente erra numa cadeia longa, é porque o plano era complexo ou porque uma ferramenta perturbou o caminho? Misturar as duas coisas esconde o que está sendo medido

Por isso o desenho é em duas dimensões: complexidade topológica baseada em DAG de um lado, e uma taxonomia 2×2 de perturbações de ferramenta do outro (explícita ou implícita, transitória ou permanente)

Com isso dá pra isolar o replanejamento dinâmico, que é justamente a parte que interessa aqui

O que os testes mostram: o gargalo é o diagnóstico, não o esforço

Aqui vem a parte que quebra a intuição, se liga nisso

Ao olhar a ação seguinte à primeira chamada de ferramenta que falha, o comportamento dominante em TODOS os modelos avaliados é o mesmo: repetir a mesma ferramenta

Repetir a mesma ferramenta representa de 44% a 76% das trajetórias pós-falha, enquanto o encerramento direto, o desistir na hora, fica abaixo de 12%

Só que a qualidade da recuperação não vem de tentar de novo nem de trocar de ferramenta

Ela vem de a ação escolhida casar com o TIPO da falha

A prova disso é meio cruel: taxas altas de retry aparecem tanto nos modelos mais fortes quanto nos mais fracos, e os modelos que trocam muito de ferramenta ficam em acurácia intermediária

O diagnóstico é o gargalo central, não a disposição de insistir

O número que dói no ToolMaze

No ToolMaze, perturbações nas ferramentas degradam o desempenho de quase todos os modelos, e a queda mais forte acontece nas falhas semânticas implícitas

A Perturbation Recovery Rate (PRR) cai cerca de 37% nesses cenários

Faz sentido, né? Falha explícita grita ("erro 500", "parâmetro inválido"), falha implícita passa: o retorno chega, parece plausível, e está errado

E tem o dado que muda planejamento de longo prazo: a tolerância a falhas do agente melhora com a escala do modelo 3,66 vezes mais devagar que a execução básica de tarefas

Traduzindo: esperar o próximo modelo maior resolver isso sozinho é aposta ruim

Mais computação não compra diagnóstico

Agentes que vão muito bem com ferramentas confiáveis desandam diante de erros recuperáveis

A causa apontada é diagnóstico limitado da falha somado a recuperação ineficaz, e NÃO volume de chamadas ou orçamento de inferência

A evidência disso é direta: dicas de recuperação direcionadas recuperam muitas tarefas antes falhas, enquanto escalar computação em tempo de teste traz ganho bem mais limitado

Informação certa na hora certa vale mais que mais tentativas, sempre foi assim…

O efeito cascata na cadeia longa

E tem o agravante estrutural: topologias complexas prendem agentes em ciclos improdutivos de tentativa e erro

Uma exceção mal tratada no meio de uma cadeia longa tende a contaminar o raciocínio seguinte, num comportamento de falha em cascata conforme a cadeia de chamadas cresce

É o velho problema de um erro pequeno lá no passo 3 virar um plano inteiro errado no passo 9

Tipos de falha de ferramenta e o caminho de recuperação que cada um pede

Um aviso de honestidade antes da tabela, porque isso importa: o benchmark NÃO publica uma receita do tipo "falha X se resolve com ação Y"

O que ele garante é que toda instância injetada tem pelo menos um caminho válido entre os quatro

Por isso a tabela lista só o que a fonte sustenta: o tipo injetado e a garantia de saída

E a leitura da evidência vem separada, de propósito, porque ela é AGREGADA: vale pro conjunto dos modelos e das falhas, não é retrato de nenhum tipo específico da tabela

• repetir a mesma ferramenta é a reação dominante pós-falha, de 44% a 76% das trajetórias
• encerrar direto, sem tentar nada, aparece abaixo de 12%
• trocar de ferramenta não é atalho: quem troca muito fica em acurácia intermediária
• a qualidade da recuperação depende da ação casar com o tipo da falha, não do esforço
• a causa da queda é diagnóstico limitado somado a recuperação ineficaz, não falta de chamadas

Ou seja: quem tem que fazer o casamento entre tipo de falha e ação é o agente (ou o seu fluxo), na hora, e é exatamente aí que a coisa desanda

E como eu reconheço isso no meu log?

Essa é a pergunta prática, e uma síntese acadêmica recente ajuda aqui ao citar a taxonomia ToolScan, de tipos recorrentes de erro de uso de ferramenta

São sete tipos recorrentes, e a fonte nomeia estes:

• chamadas de API insuficientes
• valor de argumento incorreto
• nome de argumento incorreto
• tipo de argumento incorreto
• chamadas de API repetidas (redundantes)
• nome de função incorreto, ou seja, função alucinada

Quando você abrir o log de uma sessão que deu errado, é bem provável que o que está lá tenha um desses nomes

E repara: "chamadas repetidas" está na lista. O comportamento mais comum depois do erro é também um dos erros catalogados 🙂

Os dois extremos do erro na prática, com o que fazer em cada um

O bonito (e meio doloroso) é que os dois extremos descritos nos papers aparecem reportados como bugs distintos no repositório oficial do Claude Code

São comportamentos opostos, com a mesma raiz: diagnóstico

Extremo 1: o agente repete a mesma chamada que já falhou

Como reconhecer: o modelo dispara a mesma chamada de Edit que falha várias vezes, sem diagnosticar o erro (issue #29944)

No log isso aparece como blocos idênticos em sequência, mesmo arquivo, mesma tentativa, mesmo retorno de erro

Por que acontece: é exatamente o comportamento dominante medido nos benchmarks, repetir a mesma ferramenta depois da falha

A ação é barata de escolher, e sem classificar o tipo da falha ela vira o padrão

Como prevenir: cortar a cadeia em blocos menores, porque cadeia longa é o que transforma um erro isolado em ciclo improdutivo de tentativa e erro

Extremo 2: o turno acaba em silêncio

Como reconhecer: o Claude encerra o turno quando o Edit falha, em vez de tentar de novo ou seguir o plano que ele mesmo tinha acabado de anunciar (issue #52241)

Esse é o pior de ler, porque não tem erro vermelho na sua frente, tem só uma tarefa pela metade

E repara que nada disso é o aplicativo caindo, tipo quando o ChatGPT trava no meio do uso: aqui a interface está viva, quem parou foi a tarefa

Por que acontece: o encerramento direto é minoritário nos testes, abaixo de 12%, mas ele existe, e é o extremo oposto do retry cego

Como prevenir: ponto de retorno explícito, pra que retomar não custe reconstruir tudo do zero

O caso do meio: o retry interno acontece e mesmo assim o turno morre

Tem ainda um cenário reportado que mostra que retry sozinho não é garantia de nada

O Claude Code injeta a mensagem "Your tool call was malformed and could not be parsed. Please retry."

Aí a resposta re-tentada volta de novo sem bloco tool_use, e o turno termina com "The model’s tool call could not be parsed (retry also failed)", abortando a ação em andamento (issue #63875)

Ou seja: houve tentativa, houve nova chamada, e ainda assim o trabalho parou

Insistir sem diagnosticar é gastar turno, não é recuperar

Como desenhar o fluxo sabendo que o agente vai errar no meio

Beleza, e o que dá pra fazer HOJE com isso? Vamos por camadas

Camada 1: o retry que já existe é de rede, não de julgamento

Os SDKs oficiais da Anthropic já re-tentam automaticamente falhas transitórias da API

É retry automático com backoff exponencial para erros de conexão, rate limit e 5xx, duas vezes por padrão, honrando o cabeçalho retry-after quando presente

E cada cliente aceita uma opção de máximo de retentativas, pra você ajustar ou desativar

Tome cuidado com a leitura fácil aqui: isso cobre a chamada que não chegou, não a decisão errada

Rede instável, o SDK resolve. Argumento com o tipo errado, ele não tem como saber

Camada 2: dar ao modelo um jeito de VOLTAR

Para harness de agentes de longa duração, a Anthropic documenta um padrão bem concreto: pedir ao modelo que faça commit do progresso no git com mensagens descritivas, e que escreva resumos em um arquivo de progresso

Com isso o modelo usa o próprio git pra reverter mudanças ruins e recuperar estados funcionais

A alternativa, quando não existe esse rastro, é o modelo ficar adivinhando o que aconteceu e gastando tempo pondo o app de pé de novo

Esse é o ponto de retorno que os dois extremos lá de cima precisam: com ele, o erro no passo 3 custa um revert, sem ele custa a sessão

Camada 3: uma funcionalidade por vez

A mesma orientação recomenda trabalhar em uma funcionalidade por vez, justamente pra conter a tendência do agente de fazer coisa demais de uma vez

Na prática: decompor a construção em blocos tratáveis e usar artefatos estruturados (histórico do git mais o arquivo de progresso) pra passar contexto entre sessões

Assim, um contexto novo entende rápido o estado do trabalho

E isso conversa direto com a cascata dos benchmarks: cadeia curta é cadeia que não contamina o raciocínio seguinte

Camada 4: contexto que não mora na janela

No Claude Managed Agents, o contexto fica guardado fora da janela de contexto do modelo

Ele é armazenado de forma durável no session log, e a interface getEvents() permite consultar esse contexto selecionando fatias posicionais do stream de eventos

É outra forma de dizer a mesma coisa: memória do que já foi feito é o que separa recuperar de recomeçar

Por que o harness importa tanto

Segundo a Anthropic, rodar o Claude Fable 5 em um harness como o Claude Code ou o Claude Managed Agents permite trabalhar por dias seguidos: planejando por estágios, delegando a subagentes e checando o próprio trabalho, inclusive escrevendo os próprios testes

Ou seja, a autoverificação não é mágica do modelo solto, ela vive no arranjo em volta dele

E sobre disponibilidade, pra ninguém se perder: os controles de exportação sobre Fable 5 e Mythos 5 foram levantados em 30/06/2026, e o Fable 5 voltou a ficar disponível globalmente a partir de 01/07/2026 na Claude Platform, no Claude.ai, no Claude Code e no Claude Cowork

O acesso ao Mythos 5 foi restaurado para um conjunto de organizações dos EUA depois de aprovação do governo americano em 26/06/2026

Quem acompanha a dança de datas de lançamento e liberação de modelo sabe que isso muda rápido, é o mesmo tipo de novela que rolou com a data de lançamento do GPT 5

O que observar daqui pra frente

A conclusão dos autores é a frase que eu levaria pra qualquer projeto com agente: comportamento confiável exige diagnóstico e recuperação POR CHAMADA, não apenas resposta final melhor

E isso não é um recorte de um paper solitário

Uma síntese publicada em 07/07/2026 por pesquisadores da Universidade de Oxford reúne 27 artigos de benchmark, taxonomia e auditoria publicados entre 2023 e 2026, cobrindo 19 benchmarks distintos, numa taxonomia única de limitações de agentes

E o PRIMEIRO cluster de falhas dessa taxonomia é justamente erros de invocação de ferramenta e de parâmetro

Os outros vêm depois: falhas de planejamento e satisfação de restrições, degradação em horizonte longo por acúmulo de contexto, falhas de coordenação multiagente e falhas de segurança sob condições adversariais ou subespecificadas

O placar de benchmark esconde tudo isso, e o seu log não 😀

Então o próximo passo é bem concreto, e não custa nada: abra os logs das suas últimas sessões de agente e procure qual dos dois extremos o SEU fluxo produz

É a mesma chamada repetida em série? Ou é o turno que termina em silêncio no meio do plano?

Sabendo qual dos dois é o seu, dá pra fazer a única coisa que a evidência sustenta: cortar a cadeia em blocos menores e garantir um ponto de retorno em cada bloco

failure recovery, no fim das contas, é menos sobre o modelo insistir mais e mais sobre você desenhar um caminho de volta

até o próximo post!