Pra mim, um pipeline de agentes falha de forma diferente de um pipeline determinístico. A falha determinística tem causa identificável e estado anterior recuperável a partir do log. A falha agêntica tende a se manifestar como degradação: o agente produz uma saída plausível, parcialmente correta, que a próxima etapa aceita como entrada válida e propaga adiante até o momento em que a inconsistência se torna visível numa camada onde a origem já não pode ser reconstruída. O que observo em produção é que a maior parte dos incidentes em pipelines de agentes não começa com uma exceção, mas com uma resposta aceitável que corrompe a etapa seguinte de forma silenciosa.
Na minha análise, o primeiro erro de projeto que torna a recuperação cara é tratar a falha do agente como evento binário. Num pipeline bem modelado, cada agente produz um resultado que pertence a uma de quatro categorias: correto e completo, parcial mas verificável, incorreto porém detectável, ou incorreto e indetectável. A engenharia de recuperação não existe pra primeira categoria e não é possível pra última. O valor da arquitetura está em empurrar o máximo de casos pras duas categorias intermediárias e em impedir que casos da quarta se acumulem até se tornarem dominantes. Essa redistribuição depende do que é validado na fronteira entre agentes, e não das instruções que cada um carrega internamente.
A recuperação começa antes da falha, no momento em que o estado do pipeline é definido. Um pipeline em que cada etapa escreve seu resultado num store externo, com identificador estável e versão, pode ser retomado a partir de qualquer ponto sem reexecutar o que já foi concluído. Um pipeline em que o estado existe apenas como contexto acumulado na conversa com o modelo só pode ser retomado reexecutando desde o início, porque o estado intermediário nunca foi materializado fora do loop do agente. A diferença aparece no custo do primeiro incidente: o primeiro paga a reexecução da etapa que falhou, o segundo paga tudo, inclusive das etapas que produziram saídas corretas. Persistir o estado entre agentes, mesmo quando parece desnecessário no protótipo, é o que separa um pipeline que sobrevive a falhas de um pipeline que precisa ser reiniciado a cada incidente.
Na minha avaliação, a detecção de falha no meio do fluxo exige critérios que não dependam do julgamento do próprio modelo sobre o resultado. A forma mais robusta é validar a saída de cada agente contra um schema estruturado e contra invariantes do domínio antes de entregá-la à etapa seguinte. O schema bloqueia saídas malformadas, que são a classe mais comum de falha. Os invariantes bloqueiam saídas bem formadas porém inconsistentes, que são a classe mais perigosa, porque passam pelo schema e só falham na regra de negócio. Quando a validação estrutural está ausente, a detecção da falha é empurrada pra um ponto distante no pipeline, onde o custo de diagnosticar a origem é várias vezes maior que o custo de bloquear na fonte.
O padrão de recuperação que se sustenta em produção é o retry com variação controlada. Retry idêntico não funciona. Repetir a mesma chamada com o mesmo prompt e o mesmo contexto costuma produzir a mesma saída, especialmente em modelos operados com temperatura baixa. A recuperação efetiva introduz mudança deliberada entre tentativas: reformulação do prompt pra incluir a falha detectada, troca do modelo por uma variante com viés diferente, redução do escopo da tarefa, ou inserção de uma ferramenta de verificação que não estava disponível na primeira tentativa. Cada variação custa tokens adicionais e latência, e o orçamento de recuperação precisa ser explícito no desenho do pipeline, com limite máximo de tentativas e critério claro pra escalonar a falha pra fora do loop automático.
O fallback pra caminho alternativo é a segunda camada de recuperação, e opera num nível acima do retry. Quando uma etapa falha além do orçamento de retry, o pipeline precisa decidir entre seguir num modo degradado, trocar o agente por uma implementação determinística de menor capacidade ou interromper e escalar pra intervenção humana. Cada uma dessas decisões tem consequência direta no contrato que o pipeline oferece ao consumidor. Seguir em modo degradado obriga o resultado final a carregar uma marca de confiança reduzida, o que só é útil se o consumidor sabe interpretar essa marca. A rota determinística introduz uma trajetória paralela pra mesma tarefa, e isso dobra o custo de evolução. A escalação humana só faz sentido quando o canal de intervenção tem latência tolerável pelo caso de uso. A escolha pertence ao produto e precisa estar registrada como decisão explícita no desenho do pipeline.
Pra mim, o ponto em que a recuperação deixa de funcionar é o ponto em que o pipeline acumula estado corrompido que não foi detectado na fronteira em que foi introduzido. A partir daí, enquanto qualquer retry reproduz o erro e qualquer fallback opera sobre entrada inválida, a única recuperação possível é a reconstituição do estado a partir do último checkpoint confiável. Pipelines que tratam a persistência de estado intermediário como opcional descobrem, no primeiro incidente sério, que o último checkpoint confiável é o início do pipeline, e que a recuperação custa exatamente o mesmo que a execução completa. Pipelines que tratam a persistência como fundação descobrem que a recuperação fica local e previsível, e que o custo real do incidente é o tempo de engenharia gasto pra entender por que a falha escapou da validação de fronteira.