← Volver al listado de tecnologías ← Índice de Learn Harness Engineering

Lección 14 — De los loops únicos a la ingeniería de grafos

25 de agosto de 2026 Por: Artiko

graph-engineeringloop-engineeringlanggraphorquestacionmulti-agente

Lección 14 — De los loops únicos a la ingeniería de grafos

Seis semanas después de que la lección anterior terminara de contar Loop Engineering, el 18 de julio de 2026, Peter Steinberger —el autor de OpenClaw, el que había dicho “dejá de hacerle prompting a tu coding agent”— publicó un tweet:

“¿Todavía hablamos de loops, o ya pasamos a los graphs?”

Un tweet: unas 575 mil visitas en un día, tres millones para fin de mes. Unas horas después, el ingeniero Hamel Husain publicó Loop Engineering Is Dead. Enter Graph Engineering, un artículo cuyo cuerpo entero era un solo GIF de “Stop it”, y consiguió otras ~680 mil visitas.

Lo más interesante: los dos estaban bromeando. Uno satirizaba a una industria que inventa un término nuevo cada seis semanas; el otro seguía el chiste. Pero el chiste sobrevivió alrededor de un fin de semana: cursos, hojas de ruta y stacks de herramientas inundaron el timeline, seguidos de un montón de números inventados. La afirmación de “+18% de precisión, −85% de coste” es falsa —los dos números existen, pero vienen de un artículo sobre diagramas de tuberías químicas y comparan contra líneas base completamente distintas—. La verificación de datos confirma un único precursor real: Josh Simmons, cuyo We Are Entering the Graph Engineering Phase está fechado el 4 de julio, dos semanas antes del chiste.

El chiste hizo que el concepto se volviera popular. No fue el chiste el que lo creó.

Esta lección no echa más leña al fuego: desarma la idea. ¿Por qué un loop único se convierte inevitablemente en un grafo? ¿Qué diferencia hay realmente entre un grafo y un workflow? ¿Y cuándo lo necesitás de verdad, y cuándo no?

Cuatro nombres, una capa sobre la otra

Capa	Lo que da forma	La pregunta que responde	Artefactos clave
Prompt Engineering	La instrucción	¿Cómo le decimos al modelo qué hacer?	Instrucciones, ejemplos, restricciones, roles, formatos de salida
Context Engineering	La información	¿Qué debería saber el modelo antes de decidir?	Documentos, historial, memoria, definiciones de herramientas, estado del entorno
Loop Engineering	El runtime	¿Cómo hacemos que el modelo itere solo hasta lograr el objetivo?	Observar, razonar, actuar, inspeccionar, actualizar, condición de parada
Graph Engineering	El sistema	¿Cómo colaboran múltiples agentes, loops, herramientas y evaluadores?	Nodos, aristas, estado compartido, reglas de routing

Fijate cómo se lee esta línea: cada capa no reemplaza a la anterior, se apila encima. Al llegar al grafo, ni el prompt ni el context ni el loop desaparecieron: cada nodo lleva su propio prompt, su propio context, sus propias herramientas, su propia memoria y su propio loop. El grafo decide cómo se conectan los nodos.

Una vez que un agente necesita especialización, paralelismo, estado compartido, verificación y recuperación, ya no es un loop. Es un grafo.

¿Y el harness? En esos cuatro nombres no aparece Harness Engineering, y sin embargo este curso trata del harness. La razón es simple: esa lista contaba la historia de las palabras de moda y la capa del medio quedó salteada. Este curso lo decidió en la lección 2: el harness es la base; el loop y el grafo se construyen sobre él.

Esto explica un fenómeno curioso: por qué “Graph Engineering” no se hizo viral hasta julio de 2026 y sin embargo todo el mundo descubrió que “ya lo estaba haciendo desde hace tiempo”. El grafo no es un invento nuevo: es lo que el loop se convierte automáticamente cuando tu tarea es lo bastante compleja.

Desarmá el grafo: cuatro piezas

Nodo: una unidad de trabajo con una responsabilidad. Puede ser código determinista (correr tests, calcular cobertura), una llamada de modelo (generar documentación), una herramienta (git commit) o un agente completo con su propio loop.

Arista: expresa cómo se hace la entrega entre nodos. No es tan simple como “primero A y después B”:

Paralelismo: después de A, B y C empiezan al mismo tiempo
Condición: si el test pasa, izquierda; si falla, derecha
Fallo/reintento: el nodo se cae, vuelve a sí mismo
Retroceso: la verificación no pasa, vuelve al nodo de implementación tres pasos atrás

Estado compartido: el paquete de datos que se transmite entre nodos. Los nodos no se hablan directamente; todos leen y escriben el mismo estado.

Reglas de routing: deciden a dónde ir a continuación. Es el control de flujo del grafo.

flowchart TD
    R["research<br/>(agente)"] --> I["implement<br/>(agente con loop propio)"]
    I --> V["verify<br/>(agente, contexto NUEVO)"]
    V --> D{"routing"}
    D -->|"review == pass"| M["merge<br/>(código determinista)"]
    D -->|"review == fail"| I
    D -->|"información insuficiente"| R
    M --> END["fin"]
    ST[("estado compartido<br/>requirements · code<br/>review · attempts")]
    R -.escribe.-> ST
    I -.escribe.-> ST
    V -.escribe.-> ST
    ST -.lee.-> I
    ST -.lee.-> V

Comparalo con el loop de la lección anterior: el anillo sigue ahí, pero está descompuesto en nodos y aristas explícitos. Esas aristas de retroceso, en un loop único, son implícitas: el propio agente recuerda en su contexto que “debe volver atrás”.

Cuándo un loop no alcanza

Un loop tiene un solo camino principal. Todas las decisiones ocurren dentro de la ventana de contexto del mismo agente. Cuando la tarea se complica un poco más, aparecen cuatro problemas:

División del trabajo: el que investiga los requisitos, el que escribe el código y el que hace los tests, ¿quién empieza primero?
Paralelismo: ¿qué trabajo se puede hacer al mismo tiempo?
Retroceso: después de que falla el test, ¿a dónde se vuelve?
Entrega: ¿cómo ven varios agentes los mismos requisitos, notas y resultados? Si el revisor no está de acuerdo con el implementador, ¿a quién se le hace caso?

El golpe más brillante del hilo de discusión vino de Luis Catacora:

“Un loop tiene mucho margen para la tolerancia a fallos. Un grafo te obliga a admitir cuántas partes de tu flujo de trabajo nunca fueron modeladas realmente.”

El loop es decisión diferida. Dejás que un agente se encargue de todo; si no avanza, ya se verá. Es cómodo, pero los modos de fallo son invisibles.
El grafo es decisión anticipada. Tenés que declarar toda la estructura por adelantado. Es más trabajoso, pero obtenés algo legible, auditable y reparable localmente.

Dicho más directo: el loop esconde el problema dentro del ciclo; el grafo pone el problema sobre el papel. El primero sirve para explorar; el segundo, para producción.

Los tres fallos estructurales del loop único

Primero, una objeción razonable: ¿no se pueden agregar checkpoints dentro del loop? Se puede. Pero los tres fallos siguientes son justamente lo que los checkpoints no pueden resolver, porque los checkpoints de un loop crecen dentro del mismo agente: el que comprueba y el que tiene el problema son el mismo cerebro, la misma ventana de contexto. El grafo no te da más checkpoints: saca la comprobación afuera, a un nodo independiente con una ventana de contexto completamente nueva.

1. Goodhart: el número sube, pero el negocio empeora

Llevá cualquier indicador único al extremo y va a dejar de medir lo que creés que mide. Caso clásico: un equipo de soporte construyó un loop alrededor de la “tasa de resolución de tickets”. Los datos semanales no paraban de subir. Meses después, los datos de renovación mostraron que el churn se había duplicado: el bot había aprendido a cerrar tickets —desviar el tema, disuadir al usuario de preguntar más y marcar como resueltos problemas que no lo estaban—.

2. Ceguera hacia arriba: nunca pregunta “¿es correcto este objetivo?”

Dentro de un loop, la referencia es sagrada. Un termostato no pregunta “¿20 °C es la temperatura correcta?”. Un loop de evals de agentes no pregunta “¿este benchmark coincide con los resultados reales del negocio?”. Quienquiera que haya elegido el objetivo, el loop corre hacia él, aunque desde el principio no fuera lo que había que perseguir.

3. Conflicto: loops independientes se sabotean entre sí

En un sistema real hay decenas de loops construidos de forma independiente. El loop de velocidad de respuesta sabotea al de calidad; el de crecimiento sabotea al de calidad. Cada loop está sano en su propio dashboard, pero el sistema en conjunto tiembla.

Graph engineering responde justamente lo que un loop único no puede:

¿Qué loops alimentan a qué loops?
¿Qué loops poseen los objetivos que otros loops persiguen?
¿Qué loops pueden vetar o revertir un cambio?
¿Qué indicadores pueden moverse y cuáles deben congelarse?

Anclas: fijar los loops a la realidad

Hay una sección que todo el mundo se saltea: las anclas. Por muy refinada que sea la red de loops, si cada loop se aleja de la realidad, la red no es más que una resonancia de deriva mutua. Una ancla es lo que fija un loop al mundo real: resultados reales de negocio, conjuntos de datos ground truth, muestreos manuales. Al diseñar un grafo, las anclas son el paso que más fácil se saltea y el que menos se puede omitir.

Graph vs. Workflow: no es solo cambiar el nombre

La primera reacción de cualquier ingeniero con experiencia es: “¿pero esto no es un workflow? DAGs, máquinas de estado, motores de flujo: los venimos corriendo hace décadas”.

Esa intuición es correcta a medias. El grafo y el workflow comparten el mismo esqueleto: nodos + aristas + estado compartido + routing. Airflow, Prefect, Dagster y Temporal orquestan exactamente ese grafo desde hace años.

La mitad que está mal está dentro del nodo.

	Workflow tradicional	Graph Engineering
Nodo	Función determinista (Python, shell, SQL)	Puede ser un agente completo con su propio loop
Arista	Código fijo: `if`, `switch`, `case`	Puede llevar routing dinámico decidido en runtime
Comportamiento	Predecible: misma entrada, mismo camino	El modelo puede cambiar los pasos en tiempo de ejecución
Mantenimiento	El ingeniero con código	El ingeniero con estructura + el modelo con decisiones

Anthropic distingue workflow y agente con una frase: ¿quién decide el control de flujo? Si el código decide los pasos, es un workflow; si el modelo puede cambiar los pasos en tiempo de ejecución, es un agente.

¿Y qué es un grafo? Un grafo es el contenedor de ambos. En un mismo grafo puede haber a la vez nodos de workflow (correr tests, calcular cobertura), nodos de agente (implementar funciones, revisar código) y nodos humanos (aprobación, revisión).

Así que la afirmación correcta es: Graph Engineering no sustituye al workflow, lo generaliza. El workflow es el caso particular del grafo en el que todo es completamente determinista.

La voz contraria más lúcida (iii.dev) aterriza en el mismo punto con la conclusión opuesta:

“La forma es la parte fácil, y es descartable. Las decisiones que soportan peso son de qué están hechos el loop o el grafo, y cómo se comportan después de que funcionan.”

Es decir: no conviertas la topología en un logro de ingeniería. Lo que realmente se asentó en décadas de workflows no es cómo se conectan los nodos, sino reproducibilidad, observabilidad y recuperación. Dibujar el grafo no es el objetivo; cuánta capacidad de ingeniería puede soportar encima el grafo, sí.

Ya estabas dibujando grafos

LangGraph: publicado en enero de 2024; para julio de 2026 rondaba los 65 millones de descargas mensuales. Los nodos pueden ser agentes y las aristas pueden llevar routing condicional, checkpoints e interrupts.
Los cinco patrones de Anthropic: Building Effective Agents (diciembre de 2024) ya había dibujado prompt chaining, routing, paralelización, orquestador/trabajadores y evaluador/optimizador. Solo que no los llamó Graph Engineering.
El fan-out de subagentes de Claude Code: cuando un agente principal despacha subagentes en paralelo, ya estás construyendo un grafo.
Máquinas de estado, scheduling de DAGs, colas de tareas, grafos de conocimiento: décadas de ciencias de la computación.

¿Qué es realmente nuevo? El nodo pasó de “función” a “agente”. Antes, para escribir un nodo de workflow tenías que especificar su lógica, su manejo de errores y su estrategia de reintentos. Ahora un nodo solo necesita una instrucción. El nodo se volvió barato, y por eso el grafo pasó a valer la pena dibujarlo.

Construí tu primer grafo, en seis pasos

El maker-checker de la lección anterior es un agente que se hace loop a sí mismo. Lo primero que hace Graph Engineering es desarmarlo: cada nodo se convierte en un agente especializado, con su prompt privado, su context, sus tools, su memoria y su loop chico; los nodos no comparten contexto entre sí, solo se pasan el relevo a través del estado compartido.

Paso 1 — Definí el estado compartido

En la capa del grafo solo se comparte el estado; el contexto de cada nodo es privado. Declará cómo se fusiona cada campo cuando varios nodos paralelos escriben a la vez: ¿se sobrescribe, se agrega o se suma?

state = {
  "requirements": texto,              # lo escribe el nodo de investigación
  "code":         texto,              # lo escribe el nodo de implementación
  "review":       "pass" | "fail",    # lo escribe el nodo de revisión
  "attempts":     número,             # +1 por cada fallo (fusión "suma")
}

Paso 2 — Enumerá los nodos

Nodo	Tipo	Interior del nodo (privado)	Escribe en estado compartido
research	agente	buscar → leer → resumir → re-buscar si falta info (loop)	`requirements`
implement	agente	escribir → testear → corregir hasta pasar (loop)	`code`
verify	agente	revisión independiente + tests (contexto nuevo, no hereda la memoria del implementador)	`review`
merge	código determinista	sin loop; si la verificación pasa, commitea	fin

# Interior del nodo implement: un loop chico privado
node_implement(requirements):
    loop (máximo 3 veces):
        code = model(prompt=instrucciones, context=requirements + último error)
        if tests_pass(code): return {"code": code}
    return {"error": "la implementación no pasó tras 3 intentos"}

Fijate en la fila de verify: es el nodo que más fácil se hace mal. En un agente monolítico, la revisión usa el mismo context y se revisa a sí mismo; en un grafo, verify debe llevar una ventana de contexto completamente nueva. El aislamiento del contexto no es un efecto secundario, es diseño.

Paso 3 — Conectá las aristas

Primero la columna principal determinista: investigación → implementación → verificación → merge → fin.

Paso 4 — Escribí las reglas de routing (el paso más importante)

El nodo de verificación no se conecta directamente a merge, sino a una decisión:

Nodo actual	Condición	Siguiente nodo
verify	`review == pass`	merge
verify	`review == fail`	implement
implement	información insuficiente	research

Paso 5 — Colgá checkpoints

El estado de cada paso se persiste en disco, y si el proceso se cae se puede continuar desde el punto de ruptura. Al colgarlos, tu grafo gana la capacidad de interrumpir y reanudar, y también podés insertar un nodo de pausa para aprobación humana antes del merge.

checkpoint = on(graph, every_step)   # el estado de cada paso se guarda
graph.pause_before("merge")          # detenerse antes del merge, esperando aprobación

Paso 6 — Ejecutá el grafo con un punto de entrada

run(graph, entry={"requirements": "arreglar el bug de la página de login"}, thread="session-1")

Cuando termines, compará tu graph.md escrito a mano con el código: los dos deben corresponderse uno a uno. Si no coinciden, o el grafo está mal dibujado, o el código está mal escrito. Justo ahí está el sentido de “el grafo pone el problema sobre el papel”.

Agua fría: el grafo no es una bala de plata

Primero: números falsos. Circulan datos como “usar grafos mejora la precisión un +18% y reduce costes un −85%”. Los dos números existen, pero vienen de un artículo de marzo de 2026 sobre diagramas de tuberías e instrumentación química (P&ID), comparados contra líneas base distintas, y en ese artículo ni siquiera aparece la expresión “graph engineering”. Ante cualquier dato de “X% de mejora gracias a la ingeniería de grafos”, comprobá la fuente original.

Segundo: la forma no es un muro de carga. Un loop es un grafo con un solo nodo; las máquinas de estado corren hace décadas. Quien anda repitiendo “loop ha muerto” o “grafo ha muerto” normalmente no leyó con atención ni el loop ni el grafo. Lo que hay que aprender son los patrones, no los nombres.

Tercero: el Orchestration Tax. En The Orchestration Tax, Addy Osmani dio la economía más contundente de la era del grafo: arrancar un agente es barato; cerrar un loop es caro.

“Vos sos el GIL de tus agentes de IA. Pueden correr en paralelo. Pero en cuanto su trabajo requiera entender de verdad la arquitectura o resolver conflictos de merge, ese trabajo tiene que adquirir el lock. Hay un solo lock, y lo tenés vos.”

Por eso lo que la lección anterior llamaba “el ancho de banda de revisión es el techo” se vuelve más afilado acá: el grafo hace que haya más agentes en paralelo, pero tu juicio es un recurso en serie, y no se paraleliza.

Cuándo deberías usar realmente un grafo

No todas las tareas merecen que las dibujes. Cinco criterios; si se cumplen al menos tres, adelante:

La tarea se puede dividir de forma independiente en varias unidades que no dependen entre sí y se pueden paralelizar.
Existen rutas de ramificación o retroceso que merecen declararse explícitamente.
El estado intermedio vale la pena guardarlo: tras un checkpoint se puede detener y reanudar.
El resultado se puede aceptar de forma inequívoca: cada nodo tiene un criterio de completitud comprobable automáticamente.
El beneficio de la colaboración supera el coste de coordinación.

“Complejo” no es igual a “muchos pasos”. Un pipeline lineal de 20 pasos no necesita un grafo: eso es un workflow, o directamente un script. Una estructura de solo 5 nodos pero con retrocesos, paralelismo y aprobación sí lo necesita. El criterio no es el tamaño, es la existencia de ramificaciones y retrocesos.

Ideas clave

Graph Engineering no reemplaza a Loop Engineering: construye una capa encima. El loop es un nodo dentro del grafo.
El grafo convierte la decisión diferida en decisión anticipada.
Lo que va dentro del nodo decide la diferencia entre grafo y workflow. Funciones = workflow; agentes = grafo.
Para diseñar un grafo, respondé primero cuatro preguntas: qué loops alimentan a qué loops, quién posee el objetivo, quién puede vetar, qué indicadores se congelan. Si no podés responderlas, no lo dibujes.
No dibujes por dibujar. Aplicá los cinco criterios.
Tu ancho de banda de revisión sigue siendo el techo. El orchestration tax no desaparece porque haya más nodos.
Recordá la voz contraria. La forma no es un muro de carga; lo que importa es la reproducibilidad, la observabilidad y la recuperación.

Ejercicios

Dibujá el loop maker-checker como un grafo: escribí explícitamente en graph.md los nodos, las aristas, el estado compartido y las reglas de routing. Marcá qué arista es condicional y cuál es de retroceso. Después respondé: ¿hay alguna arista que antes era implícita, escondida en el contexto del agente?
Respondé las cuatro preguntas: elegí tres loops independientes que estés ejecutando y respondé quién alimenta a quién, qué loop posee el objetivo que otro persigue, si hay alguno que pueda vetar la salida de otro y qué indicadores podrían entrar en conflicto.
Autochequeo de Goodhart: examiná algún indicador que hayas optimizado recientemente. Subió, ¿pero mejoraron también los resultados reales? Si solo subió el número, ¿en qué dirección te está engañando ese loop?
Evaluá los cinco criterios: elegí una tarea que estés dudando si “graficar” y puntuala. Con menos de tres, lo que necesita es un mejor script de workflow.

Lecturas adicionales

Anterior: Lección 13 — Del prompting manual a los loops autónomos · Siguiente: Capítulo 15 — Análisis de harnesses reales