Por Qué los Agentes en Producción Fallan Sin Infraestructura de Harness

La mayoría de los agentes de IA en producción fallan no porque los foundation models carezcan de capacidad de codificación, sino porque no existe la infraestructura de runtime para verificar y atribuir la salida del modelo. Este es el insight central de AI Harness Engineering, un framework desarrollado por los investigadores Hailin Zhong y Shengxin Zhu.

El framework plantea que el sistema modelo-harness-ambiente es la unidad de análisis, no el modelo aisladamente. El harness es el sustrato de runtime que controla la observación de tareas, selección de contexto, llamadas de herramientas, bucles de feedback, rastreo de estado y detección de conclusión. Sin un harness bien especificado, un agente opera en lazo abierto contra una base de código viva — donde los agentes visiblemente se quiebran.

El framework nombra once responsabilidades de componentes: especificación de tareas, selección de contexto, acceso a herramientas, memoria de proyecto, estado de tarea, observabilidad, atribución de fallas, verificación, permisos, auditoría de entropía y grabación de intervención. Los autores argumentan que la ausencia de estos componentes — no la capacidad del modelo — explica por qué el desempeño en benchmarks no se transfiere a repositorios en producción.

El framework define una escalera de capacidad de cuatro niveles: H0 a H3. H0 es la línea de base con entrada de tarea, parche de salida y sin soporte de runtime. Los niveles intermedios exponen progresivamente más soporte de runtime al agente. H3 es cobertura completa con logs de reproducción, verificaciones de requisitos deterministas y reportes de verificación estructurados. La escalera sirve tanto como escala de medición como hoja de ruta de despliegue: instrumente un pipeline existente, califique su nivel de harness e identifique qué componentes agregar a continuación.

La evaluación se basa en trazas. Cada ejecución de agente se convierte en un paquete de episodio, un artefacto auditable que contiene el parche y su cadena de evidencia. En H0, el paquete de episodio contiene solo el diff final. En H3, incluye logs de reproducción, atribuciones de falla por test y reportes de verificación legibles por máquina. La estructura de evidencia varía sistemáticamente con el nivel de harness, sirviendo como proxy para confiabilidad y auditabilidad.

Este es un paper conceptual y de framework. La validación controlada demuestra diferencias estructurales entre niveles de harness pero no reporta scores de SWE-bench, costo de inferencia o escala de despliegue. Los equipos que adopten el framework deben operacionalizar los once componentes en su propio stack y validar en sus propias tareas.

El paper describe el framework y programa de investigación pero no distribuye código de referencia. Mapear las once responsabilidades en una capa existente — LangGraph, AutoGen, OpenHands o un bucle de llamadas de herramientas personalizado — es la tarea del practicante. La auditoría de entropía y la grabación de intervención carecen de herramientas establecidas, requiriendo construcción personalizada. La escalera H0–H3 es diagnóstica, pero la transición H2-a-H3 requiere un verificador de requisitos determinista, que presume que la tarea es verificable por máquina — verdadero solo para bases de código con pruebas unitarias.

Deje de atribuir fallos de agentes a la calidad del modelo antes de haber calificado su pipeline en la escalera de harness. H0 es donde vive la mayoría de las configuraciones de agentes en producción, y los modos de fallo en H0 son problemas de infraestructura, no problemas de capacidad.