Failure Taxonomy of an Agent-Run Research Lab: 105 Documented Process Failures, Who Caught Them, and an Open Dataset

No cenário moderno da inteligência artificial, um novo tipo de laboratório surgiu, onde os principais trabalhadores não são humanos, mas agentes de software. Estes são programas autônomos projetados para realizar tarefas complexas como escrever código, analisar dados ou elaborar relatórios, muitas vezes trabalhando em frotas onde um agente constrói um projeto enquanto outro atua como crítico para encontrar erros. Durante anos, o foco da pesquisa neste campo tem sido o desempenho desses agentes em suas tarefas finais: o código rodou? O modelo respondeu à pergunta corretamente? No entanto, um ponto cego crítico permanecia. Os cientistas sabiam muito pouco sobre a maquinaria interna do próprio processo de pesquisa. Eles não tinham um mapa claro de onde essas equipes automatizadas tropeçam, que tipos de erros cometem com mais frequência ou, talvez o mais importante, quem ou o quê detecta esses erros antes que causem uma falha. Compreender as formas específicas pelas quais esses fluxos de trabalho digitais falham é essencial para construir sistemas que não sejam apenas poderosos, mas confiáveis e seguros.

Um relatório técnico recente de um grupo de pesquisa conhecido como 321 AI Labs aborda essa lacuna ao transformar suas próprias operações internas em um estudo de caso. Em vez de olhar para o resultado final de um único projeto, os pesquisadores passaram duas semanas em setembro de 2026 documentando meticulosamente cada falha ocorrida dentro de seu próprio laboratório de pesquisa gerido por agentes. Eles coletaram 105 registros distintos de coisas que deram errado, variando de um projeto de software local a um agente de candidatura de emprego. Cada registro foi tratado como uma peça de evidência, fixada a uma entrada de log ou arquivo específica, criando um conjunto de dados selado e legível por máquina. O objetivo não era esconder esses erros, mas categorizá-los com o mesmo rigor que um biólogo usaria para classificar uma nova espécie de inseto. Ao ordenar essas falhas em grupos específicos baseados em onde ocorreram no fluxo de trabalho, por que ocorreram e quem as encontrou, a equipe criou o primeiro conjunto de dados aberto deste tipo, oferecendo um olhar raro e sem filtros sobre a realidade operacional da pesquisa autônoma.

A análise desses 105 registros revelou um padrão claro de como essas equipes automatizadas operam. As falhas não estavam espalhadas aleatoriamente; elas se concentravam fortemente nas fases onde o trabalho é construído e verificado. O tipo mais comum de erro, representando quase metade de todos os incidentes, foi uma "lacuna de verificação". Este é um tipo específico de erro onde uma verificação de segurança ou um teste existia no papel, mas nunca foi realmente executado ou conectado ao sistema. É o equivalente digital de ter um extintor de incêndio montado na parede que ninguém jamais verifica para ver se funciona. A segunda e a terceira causas mais comuns foram mudanças ambientais, onde as condições em que o software rodava mudaram inesperadamente, e o desvio de especificação, onde os objetivos do projeto se afastaram lentamente do plano original. Curiosamente, os dados mostraram que o trabalho de detecção da frota foi realizado primordialmente pelos próprios agentes. Em 69 por cento dos casos (72 de 105), a falha foi detectada pelo agente que a gerou (rotulada como "self_caught"). Nos 31 por cento restantes, um agente revisor separado encontrou o erro. Crucialmente, o relatório encontrou zero instâncias onde uma falha passou por todas as camadas de defesa e escapou da detecção inteiramente durante este período. Além disso, zero instâncias exigiram que a camada "owner" (proprietário) interviesse para detectar uma falha, indicando que as camadas abaixo do proprietário lidaram com sucesso com os problemas documentados dentro desta janela.

Os pesquisadores não apenas contaram esses erros; eles submeteram seu próprio sistema de classificação a uma auditoria rigorosa para garantir que todos estivessem concordando com o que estavam vendo. Dois classificadores independentes, trabalhando cegamente sem conhecer as escolhas um do outro, rotularam uma amostra dos registros. Inicialmente, eles discordaram em aproximadamente metade das decisões relativas a onde uma falha ocorreu no processo. Através de uma série de revisões em suas definições e regras, eles refinaram seu entendimento até que o acordo se tornasse quase perfeito. Esse processo de auditar seus próprios rótulos é uma parte significativa da contribuição do relatório, provando que as categorias usadas para descrever essas falhas são estáveis e confiáveis. A equipe também fez questão de relatar o que os dados não podiam dizer. Embora tenham rastreado os tipos e locais de erros, a grande maioria dos registros não continha informações sobre o custo de corrigi-los. Como os documentos de origem não declaravam um custo, os pesquisadores recusaram-se a adivinhar ou estimar, deixando essas figuras em branco. Essa adesão a "resultados negativos" — relatar que algo é desconhecido em vez de inventar um número — foi uma escolha deliberada para manter a integridade do conjunto de dados.

O valor deste trabalho reside em sua transparência e utilidade para a governança futura. O conjunto de dados está agora disponível para outros pesquisadores utilizarem, com um formato claro que permite que adicionem seus próprios registros de falhas de diferentes laboratórios. Isso cria um censo crescente de falhas de processo que pode ajudar todo o campo a entender onde os sistemas automatizados são frágeis. O relatório sugere que a maior oportunidade de melhoria não está em tornar os agentes mais inteligentes, mas em corrigir as "lacunas de verificação" onde as verificações existem, mas não são exercidas. Ao saber exatamente onde as falhas se concentram, os operadores de laboratórios podem direcionar sua atenção para as partes específicas do pipeline que precisam de melhor monitoramento. O estudo conclui que, embora esses laboratórios geridos por agentes sejam capazes de detectar seus próprios erros, o sistema é atualmente mantido por um alto volume de autocorreção e revisão, e que a falha mais comum não é a falta de inteligência, mas uma falha em executar os testes que já haviam sido projetados. Essa mudança de adivinhar sobre a confiabilidade do sistema para medi-la com dados concretos marca um passo de amadurecimento para o campo da pesquisa autônoma.