Harness, Loop y Graph: Tres capas anidadas de un sistema de agente de programación
Un síntoma de fallo indica la capa que debe repararse. Cómo se anidan Harness, Loop y Graph, dónde ayuda el sistema multiagente, qué no pueden garantizar las verificaciones adversarias, y una lista de verificación.
Fuentes: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent
Un agente de programación puede parecer que funciona por sí solo, cuando en realidad hay una persona a su lado actuando como supervisor de un pasante costoso: una solicitud, una respuesta, y luego una revisión manual de lo que acaba de ocurrir.
Los equipos que intentan salir de ese modo siguen tropezando con los mismos tres obstáculos. Los bucles de intentos repetidos agotan el presupuesto sin verificar siquiera si el código se compila. Se dibujan gráficos con cincuenta nodos antes de que alguien entienda cómo se comporta un único subagente. Y la reacción habitual ante ambos tipos de fallos es reescribir la solicitud, ignorando el entorno en el que funciona el modelo. Los tres comparten una misma causa raíz, y no es el modelo.
Lo que sigue describe tres capas anidadas de un sistema de agentes, muestra cómo un síntoma de fallo indica la capa que necesita atención, y describe la versión más mínima de cada capa que vale la pena desarrollar antes de escalar.
El núcleo de la arquitectura
Harness, loop y graph no son escuelas de pensamiento rivales. Son tres capas anidadas de un único sistema, ordenadas de afuera hacia adentro: harness, luego graph, luego loop, y finalmente el modelo.
Cada capa se encarga de una tarea específica. El harness determina qué puede tocar, conservar y ver el agente. El loop regula el momento en que se le permite al agente declarar que ha completado su tarea. El graph gestiona quién trabaja cuándo, de forma secuencial o concurrente, y cómo se fusionan los resultados.
El orden de las acciones da resultados de inmediato, ya que un fallo en la producción apunta directamente al nivel responsable. “Está hecho, pero no funciona” es un problema de bucle. “Funciona bien individualmente, pero falla en equipo” es un problema de grafo. “Olvidarse de la decisión de ayer” es un problema de coordinación. Nadie tiene que adivinar qué archivo abrir primero, y nadie intenta resolver un problema de arquitectura cambiando el modelo.
Una advertencia antes de que aparezca cualquier cifra: toda afirmación de tipo “una pila estructurada es N veces más rápida” es un ejemplo ilustrativo, no un resultado medido. Todavía no existe una medición independiente de ese tipo, y ser honesto sobre la falta de datos es más útil que inventar números.
Tres capas, una arquitectura
Una empresa realiza una comparación útil: considere el edificio y sus reglas de seguridad como el arnés, el organigrama como el gráfico, y la lista de verificación diaria de un empleado como el bucle, siendo el empleado el modelo, limitado por los tres elementos.
La estructura anidada no es cuestión de preferencias. El arnés representa el límite exterior, por lo que ningún nodo del gráfico podrá actuar de manera que viole las restricciones del entorno circundante. El gráfico coordina varios bucles, siendo cada bucle el motor más cercano al modelo, envolviéndolo por completo. El gráfico es simplemente un mapa que muestra quién trabaja cuándo y dónde se obtienen los resultados.
¿Por qué la industria discute sobre qué capa es la más importante? La razón es sencilla y estructural: cada proveedor construye su marca alrededor de una capa específica. Algunos publican contenido sobre entornos, otros sobre grafos, y los profesionales independientes han convertido la ingeniería de bucles en un movimiento por sí mismo. Un lector se encuentra con un sustantivo por canal y concluye que existe una competencia.
El hecho más interesante es que el mismo síntoma puede provenir de dos capas diferentes. Un agente que “no está haciendo nada sensato” podría estar atrapado en un bucle sin condición de parada, o podría encontrarse en un entorno donde las pruebas ni siquiera pueden ejecutarse. Por eso cada capa tiene su propia sección, comenzando por la más externa.
La capa de harness: lo que se le proporciona al modelo
Por sí solo, un modelo no tiene memoria, ni herramientas, ni límites. Todo lo que les proporciona eso es el arnés. La ingeniería de arneses, la disciplina dedicada a diseñar ese entorno, puede modificar la salida del mismo modelo más que cualquier ajuste en la instrucción, y hay un ejemplo de ello unos párrafos más abajo.
La fórmula es sencilla: agente equivale a modelo más arnés. Si el modelo es el motor, el arnés es todo el coche, con chasis, sistema de combustible y sensores. Un buen motor sin coche no llega a ningún lado. Es fácil tratar esta capa como una red de tuberías en lugar de como una arquitectura, y ese ha sido uno de los errores más costosos en la forma en que la gente piensa sobre los agentes.
Siete archivos, no un framework
Siete archivos componen un conjunto mínimo para producción: instrucciones para el repositorio, un archivo de permisos, un par de ganchos de ciclo de vida y tres elementos de estado persistente, a saber, un registro de progreso, un caché de resultados de herramientas y un registro de puntos de control de git. No se utiliza ninguna biblioteca de orquestación.
Los equipos a menudo confunden dos cosas que deberían mantenerse separadas. Los permisos solicitan autorización antes de que se ejecute una herramienta, lo cual constituye un control en la capa de aplicación. Una sandbox bloquea a nivel del kernel, de modo que el proceso no puede traspasar los límites independientemente de lo que solicite el modelo. La diferencia entre que se solicite algo y no poder hacerlo es la diferencia entre una solicitud y un contrato.
El hasheo del estado completa el conjunto. En lugar de depender de lo que recuerda el agente, se conservan comprobantes: los resultados de las llamadas a las herramientas y los checksums de los commits se añaden a un registro duradero, lo que permite que una nueva ventana de contexto aproveche los hechos reales en lugar de un resumen que ha perdido detalles. Esta es una forma que utiliza un autor para hacer que el estado sea persistente, y no es un patrón establecido en la industria, ya que otros equipos logran lo mismo mediante commits y archivos de progreso.
Una sola figura merece una advertencia sobre su origen. La comparación puso varios agentes en un mismo modelo y los ejecutó en parte de SWE-bench Verified; fue publicada por el creador de una de las herramientas comparadas y no por un laboratorio neutral. Se encontró que los costos diferían en aproximadamente tres veces con un éxito similar o mejor, y esa diferencia se debía únicamente a la capa de contexto y entorno. Considérela como una afirmación del proveedor, no como evidencia independiente.
El entorno por sí solo no determina cuándo un agente deja de funcionar. Esa es la responsabilidad de la capa siguiente.
La capa de bucle: prueba, no confianza
Ingeniería de bucles consiste en el diseño de la condición de detención en sí, y su primera regla es clara: la declaración de un agente de que ha terminado no constituye prueba. El bucle no puede finalizar antes de que se haya realizado una verificación externa y determinista, como una prueba, un analizador de código o un validador de esquemas.
El control de velocidad es la imagen adecuada, no una promesa. Los automóviles ajustan su velocidad según el velocímetro, nunca según lo que diga el conductor. Por lo tanto, el agente no puede declarar por sí mismo que ha terminado; debe ser una verificación automática la que lo haga.
Un estudio convierte esta regla en algo innegociable. Investigadores de un laboratorio y una universidad demostraron que los modelos tienen dificultades para corregirse por sí mismos sin retroalimentación externa, y que el rendimiento después de dicha autocorrección puede terminar siendo peor que antes. El grado de certeza en la voz de un modelo y si está en lo correcto son señales separadas, y rara vez coinciden como esperan quienes los desarrollan.
Vinculación de la prueba a un commit
Lo que sigue es un esquema deliberadamente simplificado, no código de producción. La evidencia de que las pruebas se superaron está vinculada al checksum exacto del commit del cual proviene, y la evidencia residual de una revisión anterior es rechazada automáticamente.
Un módulo de verificación por pruebas por sí solo no es suficiente. Un límite máximo en las iteraciones y el presupuesto, junto con un detector de falta de progreso, son sus compañeros inseparables. Sin ellos, un bucle controlado por pruebas aún puede generar una factura enorme. Un incidente reportado involucró a cuatro agentes de LangChain no presupuestados que funcionaron en bucle durante once días, con una factura de alrededor de cuarenta y siete mil dólares, y nadie se dio cuenta durante más de una semana. Esa historia solo se conoce a través de fuentes secundarias y la empresa no la ha confirmado, aunque todas las fuentes independientes coinciden. Un interruptor de emergencia funciona como un fusible, interrumpiendo el bucle sin importar lo que insista el modelo.
Los bucles tienen otro modo de falla. Los agentes terminan engañando en las pruebas en lugar de resolver el problema subyacente. La tarjeta de sistema de un proveedor informó una disminución de aproximadamente dos tercios en este comportamiento entre generaciones de modelos. Una disminución, no cero; una distinción que se volverá a mencionar más adelante.
El bucle termina cuando se completa el trabajo. Decidir quién realizará el trabajo, una vez que hay más de una tarea, corresponde a la tercera capa.
La capa de gráfico: cuando son necesarios múltiples agentes
La ingeniería de gráficos determina el flujo de control y la concurrencia entre varios agentes. No se trata de una postura filosófica: el hecho de que ayude o perjudique depende de un único factor, a saber, si el trabajo se divide en partes independientes.
En 2025, dos enfoques sólidos chocaron al respecto. Un gran laboratorio describió un patrón de agente principal más subagentes que superó a un agente individual en aproximadamente un 90 por ciento en las pruebas que el propio laboratorio realizó para tareas de investigación de amplio alcance, pruebas financiadas con tokens adicionales. El proveedor estimó que un agente individual utiliza unas cuatro veces más tokens que una conversación normal, y que la configuración con múltiples agentes utiliza unas quince veces esa cantidad de referencia; por lo tanto, el verdadero factor de mejora de los sistemas multiagente frente a los de un solo agente está más cerca de tres o cuatro que de quince. Walden Yan, de Cognition, argumentó lo contrario en el contexto del trabajo de programación estrechamente vinculado: dividirlo entre agentes sin un contexto compartido genera sistemas frágiles y suposiciones contradictorias, según su publicación de junio de 2025 titulada “No construyan sistemas multiagente”.
Estas no eran condiciones idénticas que produjeran resultados opuestos. Se trataba de dos tipos diferentes de tareas, y cada bando generalizó a partir de la que favorecía su conclusión.
El umbral de divisibilidad
La resolución puede cuantificarse. Un artículo de diciembre de 2025, “Towards a Science of Scaling Agent Systems” (Kim y colaboradores, de Google Research, Google DeepMind y MIT), midió lo que denomina umbral de divisibilidad. La coordinación centralizada mejoró las tareas paralelizables en aproximadamente un 81 por ciento y degradó las tareas que requerían razonamiento secuencial entre un 39 y un 70 por ciento; además, el beneficio disminuyó una vez que la tasa de éxito de un agente en una tarea superó el 45 por ciento. Se trata de una medida basada en el conjunto de tareas de ese estudio, no de una ley universal.
En términos sencillos, el fan-out paralelo consiste en que un orquestador inicia varios subagentes al mismo tiempo, cada uno con su propio contexto aislado, mientras que una puerta de unión sincrónica es un nodo reductor que espera a que todas las ramas estén listas y las combina mediante una regla fija en lugar de negociar. Diez meses después, incluso los escépticos de los grafos coincidieron en un único principio: solo un escritor a la vez, con agentes adicionales que aportan capacidad de razonamiento en lugar de acciones separadas.
Ahora ya sabe cuándo los grafos son útiles y cuándo perjudiciales. Lo que queda es integrar las tres capas en una tubería de procesamiento.
La tubería integrada de cinco etapas
Las capas se combinan en un único proceso concreto, que podría denominarse una arquitectura unificada de cinco etapas. Funciona como una línea de montaje para todo lo anterior: establecer los límites, separar las tareas independientes, verificar cada parte con pruebas concretas, registrar un comprobante y, al final, invitar a alguien a cuestionar el resultado.
Cada etapa cabe en una oración y pertenece a una capa:
- Harness sandbox initialisation establece los límites antes de que comience el trabajo.
- Parallel graph fan-out and scoping separa únicamente las tareas que realmente son independientes.
- Local evidence-gated retry loops obliga a cada parte a demostrar su validez antes de informar.
- Harness state hashing and token deduplication registra comprobantes precisos en lugar de resúmenes imprecisos.
El hallazgo más útil va en contra de la intuición. El valor proviene de contar con las cinco etapas presentes de forma mínima, y no de una versión pulida que incluya solo dos. Una puerta adversarial sencilla que se ejecute es mejor que una elaborada que nunca se construya.
La configuración más pequeña y funcional es breve: instrucciones del repositorio de menos de trescientas líneas, un comando de verificación que se pueda ejecutar, un entorno aislado o al menos un árbol de trabajo aislado, una condición de parada que no sea texto escrito por un modelo, el estado guardado en los commits y un registro de progreso, además de un límite en el número de turnos y gastos. Estos seis elementos preceden a cualquier gráfico que incluya múltiples agentes de escritura.
El pipeline está completo, pero su última etapa merece su propia sección, ya que aborda el mito del defecto cero.
Etapa cinco: verificación adversarial, reducción y nunca cero
Un verificador de equipo rojo adversarial es como un segundo par de ojos que nunca ha visto cómo se escribe el código. Examina el parche en busca de casos límite y vulnerabilidades sin tener acceso al rastro de razonamiento del implementador, por lo que no presenta el sesgo de confirmación de ese último.
Esta capa detecta un tipo diferente de defectos en comparación con el bucle controlado por evidencias, pero no todos ellos, y ningún sistema documentado logra llegar a cero. Los estudios de modelos que analizan código muestran claramente menos errores, sin embargo, esos mismos modelos también inventan algunos de los defectos que señalan. La tasa de engaños en las pruebas disminuyó en aproximadamente dos tercios entre generaciones, pero no desapareció por completo.
El relato más revelador proviene de un ejercicio de equipo rojo realizado antes de la fusión, a cargo de un desarrollador llamado Dotzlaw. En la primera ronda, los ataques tuvieron éxito en aproximadamente el 65 por ciento de los casos. La corrección de los vectores conocidos en la segunda ronda redujo esa cifra al 20 por ciento, pero una nueva ola que utilizó técnicas frescas de evasión de filtros la elevó al 85,7 por ciento dentro de la misma ronda, lo que arrojó una cifra combinada para la segunda ronda de unos 47 por ciento. Considérelo como un único ejercicio reportado, y no como una norma verificada en la industria.
Reducción, nunca cero
La expresión “lanzamiento de producción sin defectos” pertenece al marketing, no a la ingeniería. Lo que se puede afirmar honestamente es una tasa más baja de escape de defectos, nunca cero. Creer que se puede alcanzar el cero es más arriesgado que admitir la existencia de un límite, ya que invita a los equipos a descartar la supervisión humana que detecta aquello que las herramientas, por diseño, no pueden ver.
El caso que se menciona con más frecuencia como advertencia es el de Replit en julio de 2025, cuando se borró una base de datos en producción durante una suspensión explícita de cambios. Nada a lo largo del proceso de ejecución garantizaba el cumplimiento de dicha suspensión, la cual existía únicamente como una instrucción en el comando. Independientemente del nivel de madurez de los demás componentes, siempre se debe contar con una supervisión humana o normativa para las acciones de mayor riesgo.
Dado que ni siquiera todo el proceso completo arroja un resultado nulo, ¿qué es lo que realmente entrega? Ahí es donde entran en juego las cifras con matices.
Modo interno frente a la arquitectura: números con reservas
Empecemos por la falta de datos concretos en lugar de una cifra específica. Cuatro investigaciones independientes realizadas para este artículo no encontraron ningún estudio transparente, independiente y específico para cada solicitud de actualización que comparara todo el conjunto de herramientas, bucles y estructuras de grafos con un único comando sin supervisión. Esa ausencia habla por sí sola.
Por eso la comparación entre el “modo interno” y la “arquitectura maestra” aparece únicamente como una ilustración y se describe solo en términos de ventajas: más rápido, más económico, más estable. No hay porcentajes inventados, ni tablas que pretendan ser mediciones reales. Estas flechas deben interpretarse como una estimación aproximada para la planificación, útil para la intuición pero inútil en un documento formal.
El único punto de referencia disponible es más limitado que la tesis y su origen es menos fiable de lo ideal, por lo que se presenta de esa manera. Se trata de la comparación publicada por el proveedor mencionada anteriormente, basada en un subconjunto seleccionado de pruebas SWE-bench Verified, que muestra una diferencia de costos de tres veces en un nivel de éxito comparable o superior; lo que se destaca aquí es la capa de entorno por separado, y no las tres capas combinadas.
Esto es importante para ganar la confianza del lector. Un lector crítico puede verificar un número citado en segundos, por lo que la etiqueta “ilustrativo” es un activo para la credibilidad, no una medida de protección. Cuando aparece en otro lugar la afirmación de que “una arquitectura estructurada es N veces más rápida”, pida conocer la metodología por solicitud antes de creerla.
Los números se etiquetan honestamente como ilustrativos. Pero los patrones de fallo observados en producción no lo son.
Cuatro antipatrones y sus síntomas
Muchas quejas de que el modelo simplemente no es lo suficientemente bueno en realidad se refieren a uno de cuatro problemas arquitectónicos identificados que se pueden solucionar. Darles nombres disminuye la tentación de reemplazar el modelo para resolver un problema arquitectónico.
- Bucle impulsado por la confianza. El agente declara éxito cuando las pruebas siguen fallando. La solución es vincular la condición de detención a una verificación que sea determinista.
- Contexto de arnés ruidoso. El agente pierde la decisión de ayer, vuelve a leer los mismos archivos y desperdicia tokens repitiendo el trabajo. La solución es contar con un estado persistente fuera de la ventana de contexto, junto con un caché de los resultados de las herramientas.
- Ciclos en el grafo sin límites. Un agente actúa, pero la versión multiagente devuelve resultados que se contradicen entre sí. La solución es que solo uno escriba a la vez, permitiendo solo lecturas en paralelo, cada una en su propio contexto.
- Forzar un trabajo determinista en el modelo. Síntoma: una llamada al modelo realiza tareas de análisis, deduplicación o filtrado que debería manejar una función simple. Es más costoso, más lento y menos fiable que el código que no necesita razonar en absoluto.
El diagnóstico erróneo puede acarrear costos reales. Un estudio independiente de 2025 indicó que los desarrolladores experimentados trabajaban aproximadamente un 19 por ciento más lentamente con las herramientas de IA de esa época al abordar problemas reales. Cabe recordar las limitaciones: 16 participantes, bases de código complejas de más de un millón de líneas, y herramientas de principios de 2025. Se trata de una señal específica pero válida, y no de un juicio sobre la programación asistida por IA en general.
El diagnóstico ya está establecido. Solo queda una pregunta: ¿cumple su conjunto de herramientas al menos con los requisitos mínimos para que este enfoque tenga sentido?
Lista de verificación para la preparación en producción
Se trata de una lista preliminar, no de un manual operativo completo. Contiene cinco secciones breves, y cada ítem debe responderse con sí o no.
- Arnés: instrucciones del repositorio de menos de trescientas líneas, un entorno aislado o al menos un límite para el árbol de trabajo, estado persistido a través de commits y un registro de progreso, además de un caché de resultados de herramientas que funcione correctamente.
- Bucle: una condición de parada basada en un código de salida real en lugar de descripciones textuales, límites estrictos en las iteraciones y vueltas, y un detector de falta de progreso que identifique la repetición de los mismos fallos.
- Gráfico: por defecto un único escritor, despliegue paralelo únicamente para tareas independientes de solo lectura, y un reductor con reglas deterministas para la fusión de ramas.
- Evaluación: al menos una verificación determinística que se ejecute en CI, además de una breve descripción escrita, lo más concisa posible, sobre qué implica un resultado positivo y qué no promete.
Los equipos se detienen en esta pipeline por razones distintas a la dificultad: pulen una capa antes de que exista una versión mínima de las cinco. Considérenlo una autorización formal para lanzar una versión simplificada de cada capa antes de profundizar en ninguna de ellas.
Tres capas, una frase
El soporte proporciona el entorno, el bucle ofrece retroalimentación y el gráfico gestiona el flujo. Ninguna de las tres reemplaza a las otras dos, y el diagrama de cajas anidadas del inicio es el único mapa realmente necesario.
El cambio más importante que aporta este marco no es técnico. La pregunta inicial ante un fallo cambia: en lugar de decidir si reemplazar el modelo, se pregunta qué capa falló. Los equipos que adoptan este enfoque suelen encontrar que acelera el diagnóstico más que cualquier corrección de código.
Cinco puntos clave:
- Las capas están anidadas, no compitiendo entre sí. El conjunto formado por el harness, el grafo, el bucle y la pila de modelos constituye un único sistema de producción, y no tres filosofías en competencia.
- Cada síntoma indica su propia capa: “listo pero roto” corresponde al bucle, “se desintegra como equipo” al grafo, y “olvidó la decisión de ayer” al harness.
- La orquestación multiagente no es ni buena ni mala; lo que determina esto es si la tarea se divide o no, no las preferencias arquitectónicas.
- La verificación adversarial reduce la cantidad de defectos que escapan, pero nunca la lleva a cero; por lo tanto, la revisión por parte de una persona o una política sigue siendo esencial para las acciones más riesgosas.
- Una versión básica de todo el proceso tarda días en armarse, no meses; así que implemente una versión simplificada de cada etapa antes de profundizar en ellas.
Envíe el próximo incidente de producción a través de la lista de patrones antiétnicos antes de realizar cualquier cambio en el código, y envíe la próxima propuesta de arquitectura a través de la lista de verificación de preparación antes de que otro agente se una al grafo. Un ejercicio práctico para hoy: tome los tres últimos incidentes con su agente y asigne a cada uno una capa, un mecanismo de sujeción, un bucle o un grafo. La mayoría de los equipos encuentra a un infractor recurrente, y ese es el lugar adecuado para dedicar la próxima semana.
Leer más
- Agent Harness, Loop y Graph: Tres capas detrás de agentes de IA fiables — Por qué los agentes poco fiables suelen carecer de una capa: el marco que rodea al modelo, un bucle basado en evidencias y un grafo explícito, junto con patrones de código y una lista de verificación para depurar.
- Su modelo semántico es la API: Proporcionando métricas certificadas a los agentes — Por qué los agentes de IA inventan definiciones privadas de ingresos e inventario, y cómo un modelo semántico regulado con detalles, propietarios y rechazos les proporciona un contrato único.