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

En el panorama moderno de la inteligencia artificial, ha emergido un nuevo tipo de laboratorio donde los trabajadores principales no son humanos, sino agentes de software. Estos son programas autónomos diseñados para realizar tareas complejas como escribir código, analizar datos o redactar informes, trabajando a menudo en flotas donde un agente construye un proyecto mientras otro actúa como crítico para encontrar errores. Durante años, el enfoque de la investigación en este campo se ha centrado en qué tan bien realizan estos agentes sus tareas finales: ¿se ejecutó el código? ¿Respondió el modelo correctamente a la pregunta? Sin embargo, persistía un punto ciego crítico. Los científicos sabían muy poco sobre la maquinaria interna del proceso de investigación en sí. No tenían un mapa claro de dónde tropiezan estos equipos automatizados, qué tipos de errores cometen con más frecuencia o, quizás lo más importante, quién o qué detecta esos errores antes de que causen un fallo. Comprender las formas específicas en que estos flujos de trabajo digitales se rompen es esencial para construir sistemas que no solo sean potentes, sino también fiables y seguros.

Un informe técnico reciente de un grupo de investigación conocido como 321 AI Labs aborda esta brecha convirtiendo sus propias operaciones internas en un estudio de caso. En lugar de observar el resultado final de un único proyecto, los investigadores pasaron dos semanas en septiembre de 2026 documentando meticulosamente cada uno de los fallos que ocurrieron dentro de su propio laboratorio de investigación gestionado por agentes. Recopilaron 105 registros distintos de cosas que salieron mal, que iban desde un proyecto de software local hasta un agente de solicitud de empleo. Cada registro fue tratado como una pieza de evidencia, vinculada a una entrada de registro o archivo específico, creando un conjunto de datos sellado y legible por máquina. El objetivo no era ocultar estos errores, sino categorizarlos con la misma rigurosidad con la que un biólogo podría clasificar una nueva especie de insecto. Al clasificar estos fallos en grupos específicos basados en dónde ocurrieron en el flujo de trabajo, por qué ocurrieron y quién los detectó, el equipo creó el primer conjunto de datos abierto de su tipo, ofreciendo una mirada rara y sin adornos a la realidad operativa de la investigación autónoma.

El análisis de estos 105 registros reveló un patrón claro en cómo operan estos equipos automatizados. Los fallos no estaban dispersos al azar; se agrupaban fuertemente en las fases donde se construye y se verifica el trabajo. El tipo de error más común, que representaba casi la mitad de todos los incidentes, fue una "brecha de verificación". Este es un tipo específico de error donde una comprobación de seguridad o una prueba existía sobre el papel, pero nunca se ejecutó realmente o no se conectó al sistema. Es el equivalente digital a tener un extintor montado en la pared que nadie comprueba para ver si funciona. La segunda y tercera causas más comunes fueron los cambios ambientales, donde las condiciones en las que se ejecutaba el software cambiaron inesperadamente, y la deriva de especificaciones, donde los objetivos del proyecto se alejaron lentamente del plan original. Curiosamente, los datos mostraron que la labor de detección de la flota fue realizada principalmente por los propios agentes. En el 69 por ciento de los casos (72 de 105), el fallo fue detectado por el agente que lo generó (etiquetado como "self_caught"). En el 31 por ciento restante, un agente revisor distinto encontró el error. Crucialmente, el informe encontró cero instancias en las que un fallo se filtrara a través de todas las capas de defensa y escapara a la detección por completo durante este periodo. Además, cero instancias requirieron que la capa del "propietario" interviniera para detectar un fallo, lo que indica que las capas por debajo del propietario gestionaron con éxito los problemas documentados dentro de este intervalo de tiempo.

Los investigadores no se limitaron a contar estos errores; sometieron su propio sistema de clasificación a una auditoría estricta para asegurar que todos estaban de acuerdo en lo que estaban viendo. Dos clasificadores independientes, trabajando a ciegas sin conocer las decisiones del otro, etiquetaron una muestra de los registros. Inicialmente, discreparon en aproximadamente la mitad de las decisiones relativas a dónde ocurrió un fallo en el proceso. A través de una serie de revisiones de sus definiciones y reglas, refinaron su comprensión hasta que su acuerdo fue casi perfecto. Este proceso de auditar sus propias etiquetas es una parte significativa de la contribución del informe, demostrando que las categorías utilizadas para describir estos fallos son estables y fiables. El equipo también se tomó el punto de informar lo que sus datos no podían decirles. Aunque rastrearon los tipos y ubicaciones de los errores, la gran mayoría de los registros no contenían información sobre el coste de corregirlos. Debido a que los documentos de origen no indicaban un coste, los investigadores se negaron a suponer o estimar, dejando esas cifras en blanco. Esta adherencia a los "resultados negativos" —informar que algo es desconocido en lugar de inventar un número— fue una elección deliberada para mantener la integridad del conjunto de datos.

El valor de este trabajo reside en su transparencia y su utilidad para la futura gobernanza. El conjunto de datos está ahora disponible para que otros investigadores lo utilicen, con un formato claro que les permite añadir sus propios registros de fallos de diferentes laboratorios. Esto crea un censo creciente de fallos de proceso que puede ayudar a todo el campo a comprender dónde son frágiles los sistemas automatizados. El informe sugiere que la mayor oportunidad de mejora no radica en hacer a los agentes más inteligentes, sino en solucionar las "brechas de verificación" donde las comprobaciones existen pero no se ejercitan. Al saber exactamente dónde se concentran los fallos, los operadores de laboratorios pueden dirigir su atención a las partes específicas del proceso que necesitan un mejor seguimiento. El estudio concluye que, si bien los laboratorios gestionados por agentes son capaces de detectar sus propios errores, el sistema se mantiene actualmente unido por un alto volumen de autocorrección y revisión, y que el fallo más común no es la falta de inteligencia, sino un fallo al ejecutar las pruebas que ya estaban diseñadas. Este cambio de adivinar la fiabilidad del sistema a medirla con datos duros marca un paso de maduración para el campo de la investigación autónoma.