Postmortems de Agentes: O Que Aprendemos Quando IA Autônoma Falha em Produção

Você já escreveu um postmortem que começa com "o engenheiro X rodou o comando Y sem verificar Z". Tem um nome, tem um Slack para checar, tem uma pessoa que você pode chamar numa call e perguntar "por que você fez isso?". Agora imagina escrever esse mesmo documento quando quem executou a ação foi um agente. Não tem "por que você fez isso" para perguntar — só um trace de decisões que, na melhor das hipóteses, você reconstrói depois do fato.

Esse cenário virou rotina em times que colocaram agentes autônomos para executar ação real em produção: deletar registro, mandar mensagem, abrir PR, mexer em infraestrutura. Quando algo dá errado, o playbook clássico de postmortem — reconstituir a timeline, entrevistar quem participou, achar a causa raiz, propor ação corretiva — esbarra numa premissa que não existe mais: a de que há uma pessoa, com intenção, que você entende através de conversa.

Este post é sobre o que muda quando o "autor" do incidente é um agente, quais padrões de falha se repetem em sistemas multiagente, e como estruturar um postmortem que produza ação corretiva de verdade — em vez de virar uma reunião tentando "consertar a IA para ela errar menos da próxima vez". O tema fecha a semana que abrimos com o post sobre observabilidade e tracing de agentes: sem trajectory reconstruível, nem começa a existir postmortem de agente.

---

Por Que Postmortem de Agente é um Animal Diferente

O primeiro instinto de qualquer time maduro em confiabilidade é aplicar o processo que já funciona: cultura blameless, timeline reconstruída, cinco porquês, ação corretiva documentada. A tentação de carimbar "agente" no lugar de "engenheiro" no template é grande. O problema é que duas premissas desse processo não se sustentam quando o ator é um agente autônomo.

A primeira é determinismo reproduzível. Num incidente humano, você pergunta "o que você estava pensando", e mesmo imperfeita, a resposta existe. Num incidente de agente, o "pensamento" foi inferência de modelo sobre um contexto específico, e rodar o mesmo prompt de novo não garante o mesmo resultado — temperatura, variação interna do provider, uma sutileza no contexto acumulado, qualquer coisa pode levar a uma decisão diferente na segunda tentativa. "Vamos reproduzir o incidente para confirmar a causa raiz", passo padrão em postmortem de software, muitas vezes simplesmente não é uma opção. Você tem uma trajectory, e só uma.

A segunda premissa que quebra é a de que existe uma decisão auditável entrevistando quem decidiu. Um agente não tem intenção no sentido humano. Ele teve um prompt, ferramentas disponíveis, contexto acumulado, e gerou uma sequência de chamadas. Perguntar "por que o agente fez isso" não tem resposta análoga a "por que você fez isso" — a resposta correta é sempre sobre o sistema: que informação estava disponível, que instrução foi dada, que verificação existia antes da ação. Isso desloca o objeto de investigação inteiro: você não investiga uma decisão individual, investiga um design.

Consequência prática: o postmortem de agente vive ou morre pela qualidade do tracing que já estava rodando antes do incidente. Sem trajectory instrumentada — cada prompt exato, cada chamada de ferramenta, cada decisão de sub-agente — não há testemunha para chamar. A trajectory é a testemunha, e se não foi capturada, o postmortem vira especulação educada.

---

Padrões Comuns de Falha em Sistemas Multiagente

Alguns padrões se repetem com frequência suficiente para virar categoria. Os cenários abaixo são ilustrativos e compostos — não descrevem incidente de nenhuma empresa nomeada, mas o tipo de coisa que se repete o bastante para merecer nome próprio.

O Loop Sem Convergência

Um agente tenta uma abordagem, o resultado não bate com o esperado, e ele tenta de novo — só que "de novo" costuma ser a mesma ação, ou uma variação cosmética, sem sinal de que a próxima tentativa vai dar certo. Imagine um agente de reconciliação financeira corrigindo uma divergência ao chamar repetidamente a mesma API de ajuste, porque cada chamada devolve um erro ligeiramente diferente e o agente lê isso como motivo para tentar de novo, não para escalar. Sem limite de tentativas e sem uma condição explícita de "isso não está convergindo, chame um humano", o loop roda por horas, consome tokens e pode deixar os dados numa condição pior a cada volta.

Alucinação em Cascata

O padrão mais insidioso, porque não parece erro no momento em que acontece. Um sub-agente busca uma informação — o status de conformidade de um fornecedor, digamos — e retorna algo plausível mas incorreto: leu mal um documento, misturou dois registros parecidos, ou inferiu um dado que não estava na fonte. O orquestrador recebe isso sem motivo de desconfiar, porque veio formatado como fato, sem sinalizador de incerteza algum. Esse "fato" vira premissa para a próxima decisão, que vira premissa para a próxima, e no fim da cadeia existe uma ação concreta — aprovar contrato, liberar pagamento, publicar comunicado — fundamentada numa informação que nenhum agente verificou de forma independente.

Permissão Excessiva Fora do Escopo Pretendido

O padrão de dano mais concreto e imediato. Um agente ganha acesso amplo — a um banco, a uma caixa de mensagens, a um sistema de arquivos — porque escopo granular exigiria mais engenharia do que só liberar acesso generoso "para não travar o agente no meio de uma tarefa legítima". Quando ele interpreta mal uma instrução, ou é levado por conteúdo externo a agir fora do esperado, tem capacidade técnica de causar um dano bem maior do que a tarefa pedia. Um agente de limpeza de dados com permissão de delete direto pode apagar em massa algo que devia só ter sido arquivado. Um agente de suporte com acesso à caixa de saída inteira pode mandar uma mensagem indevida para uma lista muito mais ampla do que a prevista. É o território que já mapeei no post sobre permission-hungry agents e a lethal trifecta: o agente mais útil tende a ser o mais faminto por permissão, e essa fome transforma um erro de interpretação pequeno num incidente grande.

Falha de Coordenação Entre Agentes

Sistemas com múltiplos agentes em paralelo frequentemente assumem, de forma implícita, que todos veem o mesmo estado. Raramente é verdade em produção. Um agente age sobre uma versão do estado que já mudou quando outro lê o mesmo dado segundos depois — sem lock, sem versão, sem sinal de que alguém mais mexeu ali. O resultado clássico é duplicação: dois agentes processando o mesmo reembolso porque nenhum sabia que o outro já tinha começado. Ou contradição: um cancela o que o outro, no mesmo instante, está confirmando, deixando o sistema num estado que nenhum dos dois foi desenhado para detectar.

---

Como Estruturar um Postmortem de Agente

O primeiro passo, que não aceita atalho, é reconstruir a trajectory completa antes de escrever qualquer análise: cada prompt exato enviado a cada modelo, cada chamada de ferramenta com argumentos e retorno, cada delegação entre agente pai e sub-agente, na ordem em que aconteceram. Sem isso, o postmortem vira reconstrução por inferência — o oposto do rigor que deveria ter. Se a instrumentação ainda não existe por padrão, o primeiro item de ação corretiva de qualquer incidente de agente é justamente instrumentar isso antes do próximo.

Com a trajectory em mãos, o passo seguinte é uma distinção que muda tudo: separar "o modelo teve um comportamento razoável dado o contexto que recebeu" de "o contexto ou a instrução estava mal desenhado". É o equivalente, no mundo de agentes, ao princípio de que erro humano não é causa raiz no SRE tradicional. Se o prompt, as ferramentas disponíveis e o histórico de contexto levam a uma ação que é interpretação plausível daquilo, o problema não está no modelo — está no que ele recebeu. Um agente que chamou a ferramenta errada porque duas descrições eram ambíguas não "errou": resolveu um problema mal especificado da forma que a especificação permitia. Um agente que apagou dados em massa porque tinha permissão de delete não "decidiu mal": o sistema deu a ele autoridade maior do que a tarefa exigia. Essa distinção evita a armadilha mais comum, que é concluir "o modelo alucinou" e parar por aí — isso é sintoma, não causa raiz.

A ação corretiva daí em diante mira em dois lugares, e nenhum é "melhorar o prompt para o modelo errar menos". O primeiro é bounded autonomy: qual era o raio de ação desse agente, e ele devia ter tanto assim? Se a resposta é não, a correção é reduzir esse raio — escopo mais estreito, confirmação humana obrigatória antes de ação destrutiva, limite explícito de operações em lote sem checkpoint. É o princípio que detalhei no post sobre bounded autonomy como padrão arquitetural: autonomia proporcional ao impacto da ação, não à conveniência de implementação. O segundo lugar é verificação: existia, antes da ação, algum mecanismo de checar a premissa? Se um sub-agente retorna uma informação e ninguém a valida antes de agir sobre ela, a correção é um passo concreto de validação ou uma trava que exige confirmação explícita antes de qualquer ação irreversível — não um "vamos confiar menos" vago.

Vale registrar o que NÃO é ação corretiva válida: "vamos ajustar o prompt para o agente ser mais cuidadoso", sem mudança estrutural de permissão ou verificação. Isso é esperança, não correção. Prompts são frágeis, contexto muda, e a mesma classe de erro volta numa variação sutil o bastante para escapar do ajuste feito. Ação corretiva de verdade muda o que é estruturalmente possível o agente fazer.

---

Cultura Blameless Aplicada (de Verdade) a Falhas de Agente

Cultura blameless em SRE já resolveu o problema de apontar o dedo para a pessoa errada: erro humano é sintoma de um sistema que permitiu aquele erro, e a pergunta produtiva é sempre sobre o sistema, não sobre quem errou. Esse princípio se transporta quase inteiro para postmortem de agente, mas com uma armadilha nova.

A armadilha é substituir "quem errou" por "o modelo é ruim" — trocar um alvo de culpa humano por um não-humano, repetindo o movimento que blameless existe para evitar. "O modelo alucinou" soa neutro, mas funciona como "o Fulano errou": encerra a investigação num nível superficial. Na esmagadora maioria dos casos, ao reconstruir a trajectory com cuidado, o padrão que aparece é sempre o mesmo: permissão além do necessário, ausência de verificação antes de ação irreversível, contexto ambíguo o bastante para mais de uma interpretação razoável, ou premissa de estado compartilhado que nunca foi de fato garantida.

Isso não significa que o modelo nunca tem limitação real — tem, e vale documentar quando o comportamento observado foge de qualquer interpretação razoável do contexto. Mas essa constatação isolada raramente é acionável: "o modelo vai errar menos na próxima versão" não é algo que você controla nem valida antes do próximo incidente. O que você controla é o raio de ação do agente e o quanto de verificação existe entre a decisão do modelo e o efeito real no mundo. Blameless aplicado a agente, na prática, é terminar todo postmortem com: "que combinação de permissão, contexto e ausência de checagem tornou esse erro possível — e o que muda estruturalmente para a próxima variação dessa classe não ter o mesmo raio de dano?"

Isso também muda a reunião em si. Sem uma pessoa para "confrontar", a discussão tende a virar filosófica — "será que devíamos confiar menos em agente" — em vez de concreta. O antídoto é ancorar tudo na trajectory real: qual span, qual prompt, qual chamada de ferramenta, e qual mudança de permissão ou verificação previne a recorrência. Postmortem que sai da sala sem um item de ação ligado a um controle técnico concreto não foi postmortem — foi filosofia de IA disfarçada de processo de confiabilidade.

---

Conclusão

Postmortem de agente não é postmortem tradicional com um substantivo trocado. A ausência de reprodutibilidade garantida, a ausência de uma pessoa para entrevistar, e a necessidade de investigar design de sistema em vez de intenção individual mudam o processo inteiro, da coleta de evidência até a ação corretiva — e tudo depende de uma pré-condição que muitos times ainda não têm: tracing estruturado da trajectory, capturado antes do incidente, não reconstruído às pressas depois.

As peças desta semana se encaixam aqui. Sem a observabilidade e o tracing que detalhei no início da semana, não existe trajectory para reconstruir. Sem bounded autonomy bem desenhado, o raio de dano de qualquer erro fica maior do que precisava ser. Sem tratar permissão excessiva como o risco central que ela é, você segue construindo agentes simultaneamente úteis e perigosos. E sem levar a sério que confiabilidade de agente em produção é uma disciplina de engenharia própria, você vai continuar escrevendo postmortems que terminam em "vamos melhorar o prompt" e vendo a mesma classe de incidente voltar meses depois com roupagem levemente diferente.

Se tem uma lição que atravessa observabilidade, bounded autonomy, permissão e confiabilidade, é essa: agente autônomo em produção não vai parar de errar, e essa não é a meta. A meta é garantir que, quando ele errar, o dano tenha teto conhecido, a causa seja rastreável até uma decisão de design específica, e a correção mude o que o sistema permite — não a esperança de que o próximo prompt seja mais cuidadoso.

---

Fontes:

• Google — Site Reliability Engineering: Postmortem Culture: Learning from Failure
• PagerDuty — Blameless Postmortems: A Guide to Learning from Incidents
• Honeycomb — Debugging Unknown Unknowns in Complex Systems