Agentes autônomos alucinam sua própria história. Não da maneira dramática com que os grandes modelos de linguagem inventam fatos a partir de dados de treinamento, mas da maneira silenciosa e insidiosa com que um sistema convence a si mesmo de que o mundo corresponde às suas notas. ALICE, um agente autônomo construído para gerenciar fluxos de trabalho complexos, sofria exatamente disso. Ela acordava a cada dia com habilidades, um senso de propósito e uma memória de onde havia deixado as coisas. O problema começou quando a memória e a realidade divergiram.

Em cada sessão, ALICE lia um arquivo de transferência (handoff) escrito por sua versão anterior. Ele continha ponteiros para diretórios, tarefas pendentes e suposições de estado. Frequentemente, o arquivo insistia que um diretório existia. ALICE acreditava. O sistema de arquivos discordava. Isso não era um erro de programação no sentido tradicional. Nenhuma exceção era lançada onde deveria ter sido capturada. Era uma falha de epistemologia: ALICE assumia que suas próprias notas eram a verdade absoluta (ground truth).

Por que um Linter não poderia ajudar

Ferramentas tradicionais não conseguiam detectar isso. Um linter verifica o fechamento de parênteses ou colchetes. Um analisador estático busca por ponteiros nulos. Nenhum deles questiona se toda uma arquitetura de agente deve confiar em seu estado interno. O problema residia acima da camada de código, nas suposições de design sobre como um sistema autônomo sabe o que sabe. Não se pode eliminar o excesso de confiança com um linter.

Então, o autor recorreu a uma IA inteiramente diferente.

Fable 5, rodando como Claude Code, compartilhava o mesmo silício e o mesmo modelo base que ALICE. O hardware e os pesos eram idênticos. As regras não eram. Enquanto ALICE persistia através das sessões, acumulando contexto e rituais, Fable 5 começava cada tarefa com uma folha em branco. Ele não conhecia ALICE. Ele não tinha lealdade ao design dela. Ao final de cada auditoria, ele desligava completamente, sem levar nenhuma memória consigo. Essa ignorância era o objetivo. Olhos frescos veem rachaduras diferentes, e um avaliador sem interesse no sistema questionará partes que seu criador há muito deixou de notar.

A Configuração da Auditoria

A auditoria foi estruturada como uma revisão técnica humana, exceto que todo o painel de especialistas vivia dentro de uma única sessão. Fable 5 dividiu sua atenção em seis avaliadores distintos, cada um ignorando os outros até que as notas brutas estivessem completas:

  • Lacunas Funcionais: Quais capacidades estavam faltando quando comparadas a sistemas concorrentes ou expectativas comuns dos usuários?
  • Fluxo de UX: Com que elegância ALICE lidava com erros, becos sem saída e estados vazios? Ela confundia a si mesma ou ao seu usuário?
  • Segurança: Havia atalhos de autenticação, violações de permissão ou suposições de confiança que um estranho poderia explorar?
  • Desempenho: Onde ocorriam vazamentos de memória, colisões de threads ou escalonamento ineficiente de computação?
  • Operações: Existiam backups? Havia monitoramento implementado? O sistema conseguia fazer deploy e se recuperar sem intervenção manual?
  • Ciclo de Vida de Dados: Como ALICE lidava com exclusão, limpeza e consistência de estado ao longo do tempo?

Cada perspectiva analisava arquivos idênticos e retornava com preocupações diferentes. O avaliador de desempenho poderia sinalizar um risco de concorrência na mesma rotina que o avaliador de operações criticaria por falta de lógica de rollback. Essa sobreposição não era redundância. Era cobertura. Quando o avaliador de segurança concordava com o avaliador de ciclo de vida de dados sobre um particular