U-10 · pruebas · julio de 2026

Harness, loop y graph engineering: tres formas de construir un agente

Hay un patrón que se repite en cualquier conversación sobre agentes en 2026: tres personas usan tres palabras distintas —loop, graph, harness— convencidas de estar discutiendo la misma decisión, y no lo están. Una habla de quién decide el siguiente paso. Otra, de cómo se dibuja el recorrido. La tercera, del suelo sobre el que se pisa.

No son tres opciones de un menú. Son tres capas, y confundirlas lleva a discusiones que no se pueden ganar. Este post separa las tres, dice qué falla en cada una, y trae la evidencia —que existe, y es más contundente de lo que esperaba— de cuál de ellas mueve más la aguja.

Todo empieza siendo un bucle

Antes de las tres palabras estaba ReAct (Yao et al., ICLR 2023), y su idea sigue siendo el esqueleto de casi todo lo que se construye hoy: intercalar razonamiento y acción en el mismo flujo, de manera que el pensamiento sirva para planificar la acción siguiente y el resultado de la acción sirva para corregir el pensamiento. En su momento eso les valió mejoras de 34 puntos absolutos de tasa de éxito sobre aprendizaje por imitación y refuerzo en ALFWorld, con uno o dos ejemplos en el prompt.

Reducido a código, un agente es esto y no mucho más:

def agente(objetivo, herramientas, max_pasos=20):
    contexto = [{"rol": "usuario", "contenido": objetivo}]

    for _ in range(max_pasos):
        respuesta = modelo(contexto, herramientas=herramientas)

        if not respuesta.llamadas_a_herramienta:
            return respuesta.texto              # el modelo cree haber terminado

        for llamada in respuesta.llamadas_a_herramienta:
            resultado = ejecutar(llamada)       # ← aquí vive el harness
            contexto.append(resultado)

    raise LimiteDePasos()                       # ← esto también es una decisión de diseño

Cuatro líneas de sustancia. Lo interesante es que casi todas las decisiones de arquitectura que importan están fuera de la llamada al modelo: quién decide cuándo parar, qué contiene herramientas, qué le pasa a contexto cuando crece demasiado, qué devuelve ejecutar cuando algo falla. De ahí salen las tres disciplinas.

Loop engineering: que decida el modelo

La primera opción es dejar ese bucle tal cual y trabajar sobre él: el modelo elige la siguiente acción en cada vuelta, y tú inviertes tu esfuerzo en el prompt, en el catálogo de herramientas y en las condiciones de parada.

Es lo que Anthropic llama sencillamente agente, en contraste con workflow, y su definición es la más limpia que conozco: los agentes son «sistemas donde los LLM dirigen dinámicamente sus propios procesos y uso de herramientas, manteniendo el control sobre cómo llevan a cabo las tareas» (Building Effective Agents, 2024).

Cuándo gana. Cuando no puedes predecir cuántos pasos hará falta ni en qué orden. La guía de Anthropic lo dice sin rodeos: los agentes son para «problemas abiertos donde es difícil o imposible predecir el número de pasos necesarios, y donde no puedes codificar un camino fijo». Depurar un fallo, explorar un repositorio, investigar una pregunta: tareas donde el paso cinco depende de lo que descubras en el cuatro.

Cómo falla. De tres maneras, y todas caras:

• Deriva. El modelo se desvía del objetivo poco a poco, sin que ninguna vuelta concreta parezca equivocada. Es el fallo más traicionero porque no lanza excepciones.
• Bucles. Repite la misma acción fallida esperando otro resultado, quemando tokens en cada vuelta.
• Errores que se componen. Es la advertencia explícita de Anthropic: «su naturaleza autónoma implica mayores costes y el potencial de errores que se acumulan». Un 95 % de acierto por paso son un 60 % a los diez pasos.

Ninguno de los tres se arregla con un prompt mejor. Se arreglan con estructura — y ahí entra la segunda disciplina.

Graph engineering: que decida el diseñador

La segunda opción es sacar el control del modelo y ponerlo en una topología explícita: nodos que hacen cosas, aristas que dicen qué puede seguir a qué, condiciones que eligen rama. Es lo que hace LangGraph, y lo que Anthropic llama workflow: «sistemas donde los LLM y las herramientas se orquestan a través de caminos de código predefinidos».

Su guía cataloga cinco patrones que cubren la mayoría de los casos reales: encadenamiento de prompts, enrutado, paralelización, orquestador-trabajadores y evaluador-optimizador — este último, por cierto, es exactamente el bucle de crítica y reescritura del que hablábamos en loop prompting.

Cuándo gana. Cuando puedes dibujar el flujo entero antes de escribirlo. Si el requisito es «si el paso B falla, vuelve a A, pero como máximo tres veces», eso en un bucle libre es una súplica en el prompt y en un grafo es una arista. Con topología explícita obtienes gratis lo que en un bucle cuesta sangre: reintentos acotados, puntos de aprobación humana, reanudación tras un fallo, y un diagrama que alguien puede revisar sin leer el prompt.

Cómo falla. También de tres maneras:

• Se queda encerrado. Si surge una condición para la que no hay arista, el agente no improvisa: se queda sin salida. La rigidez que te da garantías es la misma que te quita recursos ante lo imprevisto.
• Explosión de aristas. Cada caso raro nuevo es un nodo y unas cuantas aristas más. Llega un punto en que el grafo es más difícil de razonar que el bucle que sustituyó.
• Falso determinismo. El grafo es determinista; los nodos no. Tener el diagrama dibujado tranquiliza más de lo que debería cuando cada caja sigue siendo una llamada a un LLM.

La regla práctica más útil que he leído es también la más simple: si no puedes dibujar el flujo entero de antemano, el grafo no es tu herramienta. Y su recíproca: si sí puedes dibujarlo, probablemente no necesitabas un agente.

Harness engineering: el suelo

Y aquí está la capa que casi nadie nombra al empezar, porque no se parece a una decisión de arquitectura — se parece a fontanería.

El harness es la infraestructura determinista que rodea al modelo: el sandbox donde se ejecutan las acciones, las herramientas y cómo están descritas, la gestión del contexto, las trazas, los verificadores, los permisos. El modelo propone; el harness valida, autoriza, ejecuta, registra. En el código de más arriba, es todo lo que hay dentro de ejecutar() y todo lo que decide qué entra en contexto.

El Agent Harness Engineering: A Survey (Li et al., 2026 — un trabajo conjunto de CMU, Yale, Stanford, Tulane, Amazon y otros, que mapea más de 170 proyectos de código abierto) lo organiza en siete capas bajo el acrónimo ETCLOVG:

Lo llamativo es dónde caen loop y graph en esa tabla: dentro de una sola capa, la de Lifecycle. Toda la discusión de bucle contra grafo es una discusión sobre un séptimo del problema.

La evidencia

Aquí es donde esperaba encontrar opinión y encontré números. Manteniendo el modelo congelado y cambiando solo el harness:

Y no es un caso aislado: el mismo survey recoge un trabajo que modificó el formato de la herramienta de edición y el harness que la rodea en 15 modelos distintos, reportando mejoras en benchmarks de código de hasta 10× en uno de ellos.

Ahora la parte honesta, que el propio survey se encarga de escribir y que conviene no saltarse: «la evidencia controlada más fuerte viene por ahora de benchmarks de agentes de código, y estos resultados no establecen que el harness importe más que el modelo en todos los escenarios». La conclusión defendible no es «el harness importa más que el modelo». Es que el rendimiento de un agente no se puede atribuir limpiamente al modelo sin especificar el controlador que lo rodea — lo que, entre otras cosas, convierte en sospechosa cualquier comparación de modelos que no diga con qué harness se midió.

Pruébalo tú: la misma tarea, tres arquitecturas

Elige un escenario y ve qué hace cada arquitectura paso a paso. Los tres primeros son el día a día; el cuarto es el que separa a las dos primeras de la tercera:

El cuarto escenario es el que resume el post. Ante contenido hostil, la pregunta «¿bucle o grafo?» no tiene respuesta útil: ninguna de las dos topologías defiende de nada. Lo que defiende es no tener credenciales en el sandbox y exigir aprobación para las acciones con consecuencias. Eso es harness, y no aparece en ningún diagrama de flujo.

Entonces, ¿dónde vive el control?

Esa es la pregunta que de verdad separa las tres disciplinas:

La síntesis más práctica que conozco es el octavo de los 12-Factor Agents de Dex Horthy, «own your control flow»: el modelo puede elegir la siguiente acción, pero tu aplicación es la dueña del bucle, de las condiciones de parada, de los reintentos, de las puertas de aprobación y de los topes de presupuesto. Esa frase disuelve el falso dilema. No es «bucle o grafo»: es que el bucle sea tuyo y no una propiedad emergente del prompt.

La cuarta tentación: multiplicar agentes

Cuando un agente no llega, el reflejo es poner varios. Aquí el consenso se rompe, y merece la pena conocer las dos posturas antes de decidir.

Cognition publicó la más tajante, Don’t Build Multi-Agents: con varios agentes en paralelo, las decisiones se dispersan y el contexto no se comparte lo suficiente, así que el sistema se vuelve frágil. Su recomendación es de una sola línea de ejecución, con un LLM aparte dedicado a comprimir el contexto. LangChain, desde el otro lado, matiza el cuándo más que el si.

El punto en el que ambos coinciden, y que parece ser donde ha aterrizado el campo, es este: un agente principal es dueño del contexto continuo y lanza subagentes efímeros de solo lectura que devuelven un resumen comprimido. Sin canal entre iguales, sin estado mutable compartido. Los enjambres de agentes que escriben a la vez siguen siendo frágiles por la misma razón de siempre: el contexto se fragmenta y las decisiones se contradicen.

Fíjate en que este debate, otra vez, es sobre la capa Lifecycle. Y en que la solución de consenso —comprimir contexto, aislar, devolver resúmenes— es puro harness.

Los tres peajes que no se pueden esquivar

El survey cierra con tres tensiones que no se resuelven eligiendo bien, solo se administran. Me parecen la parte más útil de todo el trabajo:

Coste, calidad y velocidad. Sandboxes más fieles, memoria más rica, evaluación más profunda y observabilidad más detallada mejoran la calidad y empeoran las otras dos. No hay configuración que gane en las tres: hay que decidir qué comprobaciones son síncronas, cuáles corren en diferido y qué fallos justifican una recuperación cara.

Capacidad frente a control. Cada aumento de autoridad amplía el problema de control. Un catálogo de herramientas más grande cubre más tareas y a la vez aumenta el error de selección y la superficie de inyección de prompts. La memoria persistente ayuda en tareas largas y crea problemas de procedencia, obsolescencia y privacidad. Un sandbox permisivo hace útil la ejecución autónoma y agranda el radio de la explosión.

Acoplamiento. Las capas interactúan de formas que hacen frágil la optimización local. Las descripciones de herramientas consumen presupuesto de contexto y moldean el comportamiento del modelo; el entorno de ejecución cambia los resultados de la evaluación; el diseño de la evaluación realimenta la orquestación premiando unos bucles de recuperación y castigando otros. La conclusión operativa es incómoda pero clara: un cambio en el harness hay que probarlo como un cambio de sistema, no como un cambio local. Una herramienta, un verificador o una política de memoria pueden verse bien en aislamiento y degradar la ejecución completa al combinarse con el resto.

Lo que yo haría

Ordenado por lo que devuelve más por unidad de esfuerzo:

1. Empieza por el bucle más simple que funcione. La propia guía de Anthropic recomienda buscar la solución más sencilla posible y subir complejidad solo cuando haga falta — «lo que puede significar no construir sistemas agénticos en absoluto».
2. Invierte en el harness antes que en la topología. Es donde está la evidencia cuantitativa: mismo modelo, +13,7 puntos. Herramientas bien descritas, errores que vuelven al contexto con información útil, trazas desde el primer día, y un tope de presupuesto.
3. Pasa a grafo solo cuando puedas dibujarlo. Si el flujo tiene ramas que sabes enumerar, garantías que cumplir o aprobaciones humanas que insertar, la topología explícita se paga sola. Si no puedes dibujarlo, no lo fuerces.
4. Multiplica agentes al final, y de uno en uno. Un orquestador dueño del contexto, subagentes efímeros que devuelven resúmenes. Nada de enjambres que escriben en paralelo.
5. Mide el sistema, no el modelo. Si cambias el harness y el resultado sube, ya sabes lo que has aprendido. Si cambias el modelo sin fijar el harness, no has aprendido nada.

Y el resumen de todo, en una frase: loop y graph engineering deciden quién dibuja el camino; harness engineering decide si el suelo aguanta. Casi todo el mundo, yo incluido, empieza discutiendo lo primero.

Fuentes

• Yao, Zhao, Yu, Du, Shafran, Narasimhan y Cao — ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 2023). El bucle del que descienden todos los demás.
• Anthropic — Building Effective Agents (2024). La distinción workflow/agente y los cinco patrones de orquestación.
• Anthropic — Effective context engineering for AI agents. Compactación, context rot y el contexto como recurso finito.
• Li, Xiao, Zhang, Liu et al. — Agent Harness Engineering: A Survey (2026). La taxonomía ETCLOVG, el mapeo de más de 170 proyectos y las tres tensiones del cierre. La fuente principal de este post.
• Zhang, Wang, Ge, Xu, Hamm y Reddy — Stop Comparing LLM Agents Without Disclosing the Harness (2026). El corolario incómodo: comparar modelos sin declarar el harness no significa gran cosa.
• Trivedy (2026), recogido en el survey anterior: DeepAgents de LangChain, de 52,8 % a 66,5 % en Terminal-Bench 2.0 con el modelo congelado.
• Zhang et al. — The Interplay of Harness Design and Post-Training in LLM Agents (2026). Qué pasa cuando entrenas un agente sobre un harness pobre: se rompe al cambiar de herramientas.
• Cognition — Don’t Build Multi-Agents (2025). La postura fuerte contra el paralelismo entre agentes.
• LangChain — How and when to build multi-agent systems. El contrapunto.
• Horthy — 12-Factor Agents. En particular «own your control flow» y «compact errors into the context window».
• Anthropic — Model Context Protocol. El protocolo de la capa T de ETCLOVG; lo desmenuzamos en cómo interactúa un agente con un servidor MCP.

← volver al rack