Graph engineering: el siguiente paso después del loop engineering

Diseñaste un bucle perfecto. El agente arranca solo, hace su trabajo, verifica el resultado y para cuando toca. Enhorabuena.

Ahora tienes cuarenta funcionando a la vez.

Cuarenta agentes que se pisan, que dependen unos de otros, que a veces tienen que esperarse y otras veces pueden ir en paralelo sin problema. ¿Sigues diseñando “un bucle”? No. Estás diseñando un grafo.

Ese salto tiene nombre y es el tema de hoy. Vengo a contarte qué es el graph engineering, por qué es la continuación lógica del loop engineering y cómo empezar a pensar en topología en lugar de en ciclos.

Esto es lo que vas a encontrar:

• Qué cambia cuando pasas de un bucle a un grafo (y por qué un bucle ya es un grafo, solo que pobre).
• Las piezas reales de un grafo de agentes: nodos, aristas, estado y joins.
• Un ejemplo práctico de bug fixing donde el grafo gana por goleada.
• Qué es el blast radius, el radio de explosión de un cambio, y cómo un grafo lo recorre y repara solo.
• Qué frameworks te dan esto hoy, sin humo.
• Los tres riesgos que casi nadie te cuenta antes de que te exploten en producción.
• Por qué un grafo también se engaña a sí mismo, y qué son las anclas que lo evitan.

Qué es el graph engineering (y por qué no es “loop engineering con esteroides”) ¶

El graph engineering es el diseño de la topología por la que se mueven tus agentes: qué unidades de trabajo existen (nodos), cómo se conectan y en qué orden se activan (aristas), qué se puede ejecutar a la vez y qué tiene que esperar.

Fíjate en la palabra clave: topología. En loop engineering el foco está en un ciclo que se repite. En graph engineering el foco está en el mapa completo.

Para situarte, esta es la escalera que llevamos subiendo desde 2023, peldaño a peldaño:

1. Prompt engineering: cómo redactas la petición.
2. Context engineering: qué información ve el modelo.
3. Harness engineering: en qué entorno ejecutable vive el agente (ficheros, herramientas, memoria).
4. Loop engineering: cómo el sistema observa, actúa, verifica y decide el siguiente paso sin ti.
5. Graph engineering: cómo se conectan y coordinan muchos de esos ciclos.

Cada capa envuelve a la anterior, no la sustituye. El prompt sigue importando. El contexto sigue importando. Lo que cambia es dónde está el trabajo difícil.

🔑 El loop engineering te enseñó a diseñar un bucle. El graph engineering aparece cuando tienes muchos y el problema ya no es el ciclo, sino cómo se conectan entre sí.

Voy a ser sincero contigo, porque aquí toca. “Loop engineering” es un término que se asentó en junio de 2026 con nombre y apellidos: lo bautizó Addy Osmani recogiendo lo que decían Peter Steinberger (creador de OpenClaw) y Boris Cherny (responsable de Claude Code en Anthropic). El post de Steinberger rozó los 6,5 millones de visualizaciones. “Graph engineering” todavía no tiene ese sello. En los papers académicos lo verás como flow engineering o graph-based orchestration. Es el mismo animal, y está cristalizando justo ahora.

Que el término no esté cerrado no lo hace menos real. La arquitectura de los agentes de IA ya empuja en esta dirección, y la industria de las tendencias de agentes de código lleva meses hablando de equipos multiagente y orquestación en paralelo sin ponerle todavía una etiqueta bonita. Si vienes de hacer bien vibe coding con un solo agente, el grafo es el siguiente terreno donde te vas a mover.

Curso gratis · paso a paso

Antes de dibujar topologías, dale método al agente

Si todavía le sueltas la tarea al agente sin plan, este es el escalón que te falta: instalas OpenSpec sobre un proyecto de juguete y recorres el ciclo entero de SDD —proposal, spec, diseño, tareas, apply y archivar— en modo asistido, viéndolo funcionar antes de coger tú el volante.

Entra en el curso gratis →

Por qué un bucle ya es un grafo, pero uno muy pobre ¶

Aquí está la idea que lo cambia todo, y viene de un paper delicioso titulado From Agent Loops to Structured Graphs.

Un bucle de agente es, técnicamente, un planificador de una sola unidad lista. En cada instante hay como mucho una cosa que ejecutar, y quién decide cuál es una inferencia opaca del modelo. En jerga del paper: la cardinalidad del conjunto listo es 1.

Traducido al castellano de currante: el agente en bucle hace una cosa, luego otra, luego otra. Siempre en fila india. Aunque dos de esas tareas no tengan nada que ver entre sí y pudieran ejecutarse a la vez, el bucle las pone en cola.

El grafo rompe esa fila. Puede tener varias unidades listas al mismo tiempo. Y ahí desbloqueas tres cosas que un bucle no te da:

• Paralelismo estructural: si el nodo A y el nodo B no dependen uno del otro, se lanzan a la vez. Garantizado por la topología, no por si al modelo le apetece.
• Ramas condicionales: según el estado, el flujo se bifurca a un nodo u otro.
• Caminos alternativos: prueba dos soluciones, quédate con la que funcione y descarta la otra.

Un dato que pone las cosas en su sitio: en un análisis de 70 proyectos open source de agentes, el 60% seguía el patrón de bucle clásico y solo un 5% usaba orquestación por grafo o flujo. La mayoría del mundo todavía va en fila india. Ahí tienes tu ventaja competitiva.

Míralo de un vistazo. Arriba, el bucle en fila india. Abajo, el grafo abriendo dos caminos a la vez:

BUCLE  ·  una unidad lista a la vez  (|U| = 1)

   ┌────────┐    ┌────────┐    ┌────────┐    ┌────────┐
   │ paso 1 │ ─► │ paso 2 │ ─► │ paso 3 │ ─► │ paso 4 │ ─► ...
   └────────┘    └────────┘    └────────┘    └───┬────┘
        ▲                                        │
        └────────────────────────────────────────┘
                     vuelve a empezar


GRAFO  ·  varias unidades listas  (|U| ≥ 1)

                 ┌────────┐
            ┌──► │ nodo B │ ──┐
   ┌────────┴┐   └────────┘   │   ┌──────────────┐
   │ nodo A  │                ├─► │ join (all_of)│ ─► ...
   └────────┬┘   ┌────────┐   │   └──────────────┘
            └──► │ nodo C │ ──┘
                 └────────┘
                (B y C van en paralelo)

💡 Un bucle es un grafo con una sola arista que apunta hacia atrás. El graph engineering generaliza esa idea: muchos nodos, ramas, paralelismo y ciclos controlados dentro del mismo mapa.

Ojo con un matiz importante. Un DAG puro (grafo dirigido acíclico) es acíclico por definición: una vez pasas por un nodo, no vuelves. Los bucles de agente, en cambio, vuelven a propósito. El graph engineering serio combina lo mejor de ambos: la estructura explícita del grafo con la posibilidad de reintentar mediante ciclos acotados. No es “grafo o bucle”. Es grafo que además sabe repetir cuando toca.

Cuando montas un equipo de subagentes que programan por ti, esto deja de ser teoría. Cada subagente es un nodo. Cómo los conectas es tu grafo. Y el error más caro casi nunca está en un subagente concreto, sino en cómo los cableaste: uno de los errores comunes al construir un agente de IA que más factura pasa en producción.

Las piezas de un grafo de agentes ¶

Vamos a lo concreto, que es donde se aprende. Un grafo de agentes tiene cuatro piezas que necesitas dominar.

Nodos.
Son las unidades de trabajo. Un nodo puede ser una llamada a una herramienta, una invocación al modelo, un subagente completo o incluso un punto de control humano (human-in-the-loop). La regla de oro: un nodo, una responsabilidad clara y un contrato de salida verificable.

Aristas.
Son el cableado que decide qué se ejecuta después. Hay dos tipos que te importan de verdad:

• Aristas normales: van de un nodo al siguiente sin condiciones. Flujo fijo.
• Aristas condicionales: llaman a una función que decide a qué nodo (o nodos) ir según el estado actual. Aquí es donde el grafo “piensa”.

Cuando un nodo tiene varias aristas de salida, esos destinos se ejecutan en paralelo. Ese es el mecanismo del paralelismo, y es estructural, sin más.

Estado.
El grafo arrastra un estado compartido que cada nodo lee y actualiza. Aquí entran los checkpoints: si guardas el estado tras cada nodo, puedes reanudar tras un fallo sin perder el trabajo hecho. Para un grafo que dura horas, esto no es un lujo, es supervivencia.

Joins.
Cuando varias ramas confluyen en un nodo, tienes que decidir la semántica de la unión. Hay dos que se usan a diario:

• all_of: el nodo espera a que todas las ramas entrantes terminen. Es el paralelismo constructivo (leer dos ficheros antes de analizarlos).
• any_of: el nodo arranca en cuanto una rama tiene éxito. Es el camino alternativo (prueba dos parches, sigue con el que funcione).

La diferencia entre los dos, dibujada:

   all_of  ·  espera a TODAS          any_of  ·  la PRIMERA que va bien

    A ──┐                              A ──┐
        ├──► C                             ├──► C
    B ──┘                              B ──┘

   C arranca cuando A y B             C arranca cuando A o B
   han terminado los dos.            tiene éxito; la otra rama
                                     se descarta sin reintentar.

Así se ve un grafo mínimo con un ciclo de verificación, al estilo de LangGraph:

from langgraph.graph import StateGraph, START, END

def research(state):
    # Genera una respuesta a partir de la pregunta
    ...

def verify(state):
    # Comprueba cada afirmación contra fuentes reales
    ...

def decide(state):
    # La arista condicional: ¿seguimos iterando o paramos?
    if state["verdict"] == "verified":
        return END              # objetivo cumplido
    if state["iterations"] >= MAX_ITERATIONS:
        return END              # nos rendimos con la mejor versión
    return "research"           # la arista hacia atrás = el bucle

graph = StateGraph(ResearchState)
graph.add_node("research", research)
graph.add_node("verify", verify)
graph.add_edge(START, "research")       # disparador
graph.add_edge("research", "verify")    # siempre verifica un borrador nuevo
graph.add_conditional_edges("verify", decide)

agent = graph.compile()

Ese add_conditional_edges con la arista que vuelve a research es, literalmente, tu bucle expresado como grafo. Ahora imagina que en lugar de dos nodos tienes doce, con tres ramas paralelas y un par de joins. Eso ya es graph engineering.

Del bucle al grafo: un ejemplo que se entiende ¶

Nada explica mejor la diferencia que un caso real. Imagina esta tarea: arreglar un bug de autenticación en un proyecto Python y, de paso, actualizar la documentación.

La tarea se descompone en diez pasos: buscar en el módulo de auth, buscar en utils, leer cada fichero, analizar la causa raíz, probar dos parches distintos, ejecutar los tests, actualizar los docs y generar un informe.

Así lo vive un bucle de agente, según el ejemplo del paper:

1. Busca ficheros de auth.
2. Busca en utils (secuencial, no en paralelo, aunque no dependan entre sí).
3. Lee el fichero de auth.
4. Lee el de utils.
5. Analiza ambos.
6. Escribe un parche.
7. Ejecuta los tests. Fallan dos.
8. Decide probar otro parche (ad-hoc, sin protocolo).
9. Ejecuta los tests otra vez. Pasan.
10. Actualiza docs.
11. Genera el informe.

Once turnos, todos en fila india. Y fíjate en los problemas: buscar en auth y en utils podrían ir a la vez, pero van uno detrás de otro. Actualizar docs podría solaparse con el ciclo de parches, pero se hace al final. Y cuando el primer parche falla, el modelo improvisa un segundo sin ningún límite formal de cuántas veces lo va a intentar.

Ahora el mismo trabajo como grafo:

• Ronda 1 (paralelo): buscar auth + buscar utils.
• Ronda 2 (paralelo): leer auth + leer utils.
• Ronda 3: analizar (con join all_of: espera a los dos ficheros de forma estructural, no porque el modelo se acuerde).
• Ronda 4 (paralelo): parche A + parche B + actualizar docs.
• Ronda 5: tests (con join any_of: sigue con el parche que funcione, descarta el otro sin desperdiciar reintentos).
• Ronda 6: informe.

Y el mapa completo, que es donde se ve la jugada de un golpe:

   ┌──────────────┐          ┌──────────────┐
   │ buscar auth  │          │ buscar utils │     ronda 1  (paralelo)
   └──────┬───────┘          └──────┬───────┘
          ▼                         ▼
   ┌──────────────┐          ┌──────────────┐
   │  leer auth   │          │  leer utils  │     ronda 2  (paralelo)
   └──────┬───────┘          └──────┬───────┘
          └───────────┬─────────────┘
                      ▼   join all_of (espera a los dos)
               ┌────────────┐
               │  analizar  │                     ronda 3
               └─────┬──────┘
         ┌───────────┼────────────┐
         ▼           ▼            ▼
   ┌──────────┐┌──────────┐┌──────────────┐
   │ parche A ││ parche B ││ actualizar   │       ronda 4  (paralelo)
   │          ││          ││   docs       │
   └────┬─────┘└────┬─────┘└──────┬───────┘
        └─────┬─────┘             │
              ▼ join any_of       │
        ┌──────────┐              │
        │  tests   │              │  (docs sigue por su lado)
        └────┬─────┘              │
             └──────────┬─────────┘
                        ▼   join all_of (tests + docs)
                 ┌────────────┐
                 │  informe   │                   ronda 6
                 └────────────┘

El join any_of de los dos parches es la clave: si el parche B funciona, el A se descarta sin gastar un reintento. Y analizar no arranca hasta tener los dos ficheros porque el all_of lo obliga, no porque el modelo se acuerde.

Diez despachos de nodos en seis rondas, cuatro de ellas con paralelismo. El tiempo de reloj baja en proporción al paralelismo disponible.

La diferencia no es solo velocidad. Es que en el grafo el paralelismo, las dependencias y el fin de los reintentos son propiedades de la estructura, no decisiones que el modelo tiene que recordar en cada turno. El join all_of garantiza que “analizar” no arranca hasta tener los dos ficheros. El join any_of garantiza que no malgastas presupuesto reintentando un parche cuando otro ya funcionó.

🛡️ Cuando un nodo falla en un grafo, el fallo está localizado: sabes exactamente qué nodo lo produjo, qué entradas tenía y qué nodos de abajo quedaron bloqueados. En un bucle largo, esa información se diluye en un contexto que crece sin parar.

Esto conecta con algo que ya vimos sobre cómo verificar lo que programan los agentes: cuanto más explícita es la estructura, más fácil es auditar dónde se rompió la cadena. Un grafo es, entre otras cosas, una máquina de trazabilidad.

El blast radius: hasta dónde llega la onda expansiva de un cambio ¶

Hay una pregunta que todo el que programa se ha hecho mil veces: “si toco esto, ¿qué más se rompe?”. El blast radius (el radio de explosión de un cambio) es esa pregunta convertida en concepto de grafo, y es una de las herramientas más útiles que te llevas de pensar en topologías.

El término viene de infraestructura: “si se cae este servidor, estos tres servicios se van con él”. Llevado al código, el blast radius de un cambio es el conjunto de nodos del grafo de dependencias que se ven afectados cuando modificas uno. Ni más, ni menos.

Y aquí está lo bonito: calcularlo no es adivinación, es un recorrido de grafo. Tu código es un grafo dirigido donde cada nodo es un fichero (o una función, o un módulo) y cada arista es un import o una llamada. Partes del nodo que cambias y avanzas hacia atrás por las aristas de quien depende de ti, un recorrido en anchura de toda la vida. Cada nodo que pisas en ese camino entra en el radio.

La profundidad importa, y mucho:

• Radio 1: los dependientes directos. Quien te importa sin intermediarios.
• Radio 2 y 3: los transitivos. Los que dependen de los que dependen de ti. Aquí viven los sustos, porque a simple vista no los ves venir.

Un análisis útil suele mirar entre 3 y 5 saltos. Y cuidado con la dirección: los dependientes (quién te usa) son los que se rompen cuando cambias; las dependencias (qué usas tú) son tus entradas. Para el blast radius te importan los primeros.

   ●  Epicentro   (el nodo que cambias)
   │
   ├──►  A  ──►  D
   ├──►  B
   └──►  C  ──►  E

   radio 1 (directos) :  A, B, C     ← se rompen ya
   radio 2 (transit.) :  D, E        ← los que no ves venir

Un ejemplo para aterrizarlo, de los que pasan un martes cualquiera. En el tipo Usuario cambias el campo email: string por contacto: { email: string; phone: string }. El epicentro es ese tipo. El radio directo son los sitios que leían usuario.email: la cabecera, el perfil, el checkout y el módulo que manda correos. Los reparas uno a uno. Pero al arreglar el módulo de correos cambias la firma de sendEmail(user), y eso rompe el de notificaciones y el de recuperación de contraseña. Acaban de aparecer dos nodos secundarios: el radio se expande.

Ese es justo el patrón que un grafo de agentes ejecuta de maravilla. No es un bucle único masticando el repositorio entero de una sentada: es un recorrido ordenado del subgrafo afectado, reparando nodo a nodo y creciendo solo cuando surgen grietas nuevas.

   Epicentro: el cambio que introduces
         │
         ▼
   [1] Traza el subgrafo afectado
       recorrido hacia atrás por las aristas de dependientes
         │   radio 1 → radio 2 → radio 3 …
         ▼
   [2] Recorre el radio nodo a nodo, respetando el orden de dependencias:
       ├─ pásale al agente el contexto de ESE nodo y nada más
       ├─ que arregle ahí el breaking change
       └─ comprueba en el sitio (tipos + tests de ese nodo)
         │
         ▼
   [3] ¿La reparación abrió grietas nuevas?
       ├─ Sí → mete esos nodos en el radio y vuelve a [2]
       └─ No → subgrafo en verde: cambio propagado

Fíjate en el paso 2, porque ahí hay una lección para quien empieza: al agente no le sueltas el repositorio entero, le das el contexto de un solo nodo. Un radio bien trazado es también un recorte de contexto. El agente repara con la vista puesta en una pieza, no ahogado en diez mil líneas que no le tocan.

Y fíjate en un detalle que separa un grafo que funciona de uno que alucina: el radio se calcula recorriendo el grafo, no preguntándole al modelo “¿qué crees que se rompe?”. Un modelo te dará una respuesta plausible que acierta el 80 % y se inventa el resto. El recorrido determinista no se deja ni un dependiente ni fabrica conexiones que no existen. Calcular el blast radius así, tocando el grafo real, es lo que lo vuelve fiable.

Y no es teoría de laboratorio. Con las herramientas de IA escupiendo PRs de 5.000 líneas a diario, nadie traza a mano las dependencias de un diff de ese tamaño. Hay quien cuenta que añadió un campo a un struct compartido y descubrió que 417 ficheros dependían de él. Incluso en Amazon llegaron a convocar una reunión obligatoria sobre incidentes en producción provocados por cambios de IA con un blast radius enorme. Saber hasta dónde llega la onda dejó de ser un lujo.

Qué frameworks te dan graph engineering hoy ¶

No necesitas construir el motor desde cero. El ecosistema de 2026 ya trae estas piezas de serie. Estas son las opciones que de verdad se usan, con su carácter.

Un apunte de madurez. LangGraph llegó a su versión 1.0 en octubre de 2025 sin romper compatibilidad, y Microsoft fusionó AutoGen y Semantic Kernel en su Agent Framework 1.0 en abril de 2026. No estamos hablando de juguetes experimentales, sino de infraestructura que ya mueve despliegues en producción.

Y luego está la capa clásica, que no debes ignorar. Motores de flujos como Airflow, Luigi o Prefect llevan una década haciendo scheduling por DAG con nodos deterministas. La diferencia con los grafos de agentes es que aquí los nodos son no deterministas: el mismo nodo con la misma entrada puede dar salidas distintas, porque dentro hay un modelo. Por eso un grafo de agentes necesita validación por contrato en lugar de simple type-checking, y protocolos de recuperación que distingan un fallo de red de una alucinación.

Construye agentes con criterio

Elegir framework es lo fácil; sostener el sistema en producción es lo otro

Verás los seis niveles de arquitectura de un agente —tools, guardarraíles, memoria, skills, MCP y orquestación— con código, Mastra y Open Code, hasta montar el sistema multiagéntico revisado por otro modelo.

Ver la arquitectura entera →

6 niveles de arquitectura, en directo · Acceso con Web Reactiva Premium

Librerías especializadas en grafos, más allá de los frameworks grandes ¶

Los frameworks de la tabla anterior son las suites completas. Pero si lo que quieres es la pieza de grafo sin arrastrar todo un ecosistema, hay librerías más pequeñas y afiladas que hacen justo eso. LangGraph domina el terreno (rozaba las 126.000 estrellas en GitHub en abril de 2026), pero no está solo.

La diferencia práctica entre elegir una de estas y montar la suite completa es la misma que hay entre importar una librería y adoptar un framework: la librería te deja el control del bucle principal en las manos, el framework te lo gestiona. Para un grafo pequeño y explícito, Burr o PocketFlow te dan claridad sin ceremonia. Para RAG con muchas piezas intercambiables, Haystack encaja como un guante.

Y hay una capa que casi nadie menciona hasta que un grafo se le cae a mitad de ejecución: la de ejecución durable. No define la semántica de tus agentes, pero mantiene el grafo vivo entre fallos.

• Temporal: se ha vuelto la capa de ejecución durable de facto bajo LangGraph para despliegues críticos. Sobrevive a caídas, reintenta y reanuda el grafo desde donde iba sin perder el estado.
• Dagster: el complemento orientado a activos, pensado para pipelines que producen datos tangibles y quieres versionar y auditar.
• Langflow, Flowise o n8n: si prefieres dibujar el grafo antes que escribirlo, estos constructores visuales te dan el lienzo. Útiles para prototipar y para que perfiles no técnicos vean la topología de un vistazo.

La regla para no perderte entre tanta opción es sencilla: una librería de grafo para tener el control fino, un motor durable debajo para que sobreviva a la realidad, y una capa visual encima solo si necesitas enseñar el mapa a otros.

Los tres riesgos que nadie te cuenta ¶

El graph engineering no es gratis. Si te lanzas sin mapa, estos son los tres agujeros donde vas a caer.

1. El planificador se equivoca al dibujar el grafo.
Alguien tiene que generar la topología, y muchas veces ese alguien es otro modelo. Puede olvidar una dependencia (y entonces un nodo arranca sin sus datos), añadir dependencias que sobran (y matas el paralelismo sin querer), elegir mal el join (all_of donde tocaba any_of) o descomponer demasiado o demasiado poco. Un all_of puesto donde debía ir any_of te obliga a que los dos parches funcionen, cuando solo uno era viable. Resultado: reintentos infinitos y tokens quemados.

2. La expresividad se come a la controlabilidad.
Es un intercambio brutal y conviene que lo mires de frente. En ese mismo estudio de 70 sistemas, los de mayor expresividad —los de orquestación por grafo y flujo— eran los que menos control ofrecían y más riesgo de implementación acumulaban. El comportamiento de bucle de fallo (recuperación sin fin) apareció en 3 de cada 4 sistemas de grafo, y en ninguno de los 7 basados en máquina de estados. Más libertad estructural, más formas de que la cosa se descontrole.

3. Orquestas de más.
Este es el clásico. No todo problema necesita cuarenta nodos. Un montón de tareas se resuelven con un solo agente y un buen bucle, y meter un grafo multiagente encima solo añade coste, latencia y superficie de fallo. Es exactamente uno de esos errores comunes al construir un agente de IA: complejidad de orquestación que no aporta nada.

⚠️ La regla que repiten los equipos en producción: empieza con la arquitectura más simple que funcione, instrumenta bien y añade complejidad solo cuando observes un fallo real, no uno que te imaginas.

Esto enlaza con algo que ya vimos con el vibe coding: el riesgo no está en la herramienta, sino en no saber cuándo parar de añadir piezas.

Un grafo también se engaña a sí mismo ¶

Y aquí viene la parte incómoda, la que casi ningún tutorial de orquestación te cuenta. El grafo también falla. Solo que más tarde, más caro y con muchas más luces verdes de camino al desastre.

Imagina que montas la red completa. Un subagente verifica a otro. Un bucle de auditoría revisa los números del bucle de operaciones. Un meta-bucle ajusta los umbrales leyendo los dashboards que salen de todo lo anterior. Precioso sobre el papel.

Pero fíjate en un detalle: cada bucle vigila a otro bucle, y ninguno toca el suelo.

Es un circuito de confirmación mutua donde todo encaja y nada está verificado. Va a reventar igual que reventaba el bucle único del principio, solo que con más ceremonia y más gente aplaudiendo el dashboard mientras el cliente se va.

La ley de Goodhart lo resume en una frase: una métrica que optimizas con suficiente fuerza deja de medir lo que medía. Un grafo de agentes encontrará todas las formas de mover el número, incluidas las que traicionan su propósito. No es que se estropee. Es que hace exactamente lo que le pediste, sobre un número que se soltó de la realidad hace rato.

¿La solución? No son más aristas. Son anclas. Y hay tres tipos que tienes que cablear a mano:

• Medidas que no se pueden discutir. Tests que se ejecutan de verdad (no “el agente dice que pasan”), el build que compila, el endpoint que devuelve un 200, el usuario que no vuelve a abrir el ticket. El blast radius calculado por recorrido del grafo, y no por corazonada del modelo, es otra de estas anclas. Nada de un subagente jurando que otro subagente hizo bien su trabajo.
• Nodos congelados. Reglas que el planificador no puede reescribir jamás, justo porque son las que el optimizador se sentiría tentado de aflojar: permisos, límites de gasto, el contrato de salida, el set de verificación que el implementador no llega a ver. Es el mismo principio que un buen held-out set: si quien escribe el código también evalúa su código, con su mismo contexto, la nota se la pone él.
• La definición de “mejor” viene de fuera. Los bucles optimizan hacia una referencia; los grafos gestionan y revisan esas referencias; pero qué merece la pena controlar, y dónde poner las reglas congeladas, no lo puede generar la propia maquinaria, porque todos sus bucles lo dan por hecho. Eso lo pones tú, a base de chocar con fallos reales.

Ese último punto es el que marca la frontera. La topología te compra sofisticación; no te compra contacto con la realidad. Un grafo sin anclas es un bucle único disfrazado de organigrama.

Cómo empezar hoy sin morir en el intento ¶

Nada de saltar a cuarenta nodos el primer día. La forma sana de entrar en graph engineering es de abajo arriba.

1. Parte de un bucle que ya te funcione. Uno de generar-y-verificar, del estilo que viste en el ejemplo de código. Si no tienes ninguno, ese es tu primer deber.
2. Añade una sola rama condicional. Que el grafo bifurque según el estado: si la verificación pasa, sigue; si no, vuelve. Ya tienes tu primera arista condicional real.
3. Mete una ola de paralelismo. Busca dos tareas de tu flujo que no dependan una de otra y lánzalas a la vez con un join all_of al final. Nota la diferencia en el tiempo de reloj.
4. Introduce un camino alternativo. Dos enfoques para el mismo problema, resueltos con any_of. El primero que funcione gana.
5. Persiste el estado. Añade checkpoints para poder reanudar tras un fallo. Sin esto, un grafo largo es una bomba de relojería.
6. Ancla al menos una medida. Antes de sumar el sexto nodo, comprueba que algo del grafo toca el mundo de verdad: un test que se ejecuta, un build que compila, una métrica que no depende de que otro agente la confirme.

Hazlo en ese orden. Cada paso es pequeño y verificable, y en seis iteraciones habrás pasado de “escribo prompts” a “diseño topologías” sin darte cuenta.

El cambio de mentalidad es el de siempre en esta profesión, solo que un peldaño más arriba. Antes escribías código. Luego prompts. Después bucles. Ahora dibujas el mapa por el que se mueven los agentes que escriben ese código.

Pero dibujar el mapa no basta. Un grafo precioso de bucles que se vigilan entre sí, sin una sola medida que toque el suelo, es teatro con buena asistencia. El eje que de verdad importa no es bucle contra grafo: es anclado contra sin anclar.

¿El tuyo toca el suelo?

Preguntas frecuentes ¶

¿Qué es el graph engineering en el contexto de los agentes de IA? ¶

Es el diseño de la topología por la que se mueven varios agentes o unidades de trabajo: qué nodos existen, cómo se conectan mediante aristas, qué se ejecuta en paralelo y qué debe esperar. Es la capa que aparece cuando ya no diseñas un único bucle, sino la red de bucles y tareas que se coordinan entre sí.

¿En qué se diferencia del loop engineering? ¶

El loop engineering diseña un ciclo que se repite: observar, actuar, verificar y decidir. El graph engineering diseña el mapa completo cuando tienes muchos de esos ciclos y tareas que dependen unas de otras. Técnicamente, un bucle solo tiene una unidad lista a la vez; un grafo puede tener varias, lo que desbloquea paralelismo y ramas.

¿Un bucle no es también un grafo? ¶

Sí, pero uno muy limitado. Un bucle equivale a un grafo con una sola arista que apunta hacia atrás y una única unidad ejecutándose en cada momento. El graph engineering generaliza esa idea con múltiples nodos, ramas condicionales, paralelismo y ciclos controlados dentro de la misma estructura.

¿Qué son los joins all_of y any_of? ¶

Definen qué pasa cuando varias ramas confluyen en un nodo. Con all_of, el nodo espera a que todas las ramas entrantes terminen (útil para reunir resultados antes de seguir). Con any_of, el nodo arranca en cuanto una rama tiene éxito (útil para caminos alternativos donde solo necesitas que uno funcione).

¿Qué framework me conviene para empezar? ¶

Si trabajas en Python y quieres el estándar más adoptado, LangGraph. Si vives en el stack de Microsoft, su Agent Framework. Si tu mundo es TypeScript, Mastra. Para asistentes acotados con delegación limpia, el Agents SDK de OpenAI. Empieza por el que ya encaje con tu lenguaje y despliegue.

¿El graph engineering sustituye al prompt y al context engineering? ¶

No. Cada capa envuelve a la anterior sin reemplazarla. Un grafo bien diseñado sigue necesitando buenos prompts en cada nodo y un contexto bien gestionado. Lo que cambia es dónde está el trabajo de ingeniería más difícil.

¿Cuándo NO debería usar un grafo multiagente? ¶

Cuando un solo agente con un buen bucle ya resuelve la tarea. Añadir orquestación por grafo a un problema simple solo suma coste, latencia y superficie de fallo. La recomendación en producción es empezar simple y añadir complejidad solo ante fallos reales observados.

¿Por qué los nodos de un grafo de agentes son más difíciles que los de Airflow? ¶

Porque son no deterministas. El mismo nodo con la misma entrada puede dar salidas distintas, ya que dentro hay un modelo de lenguaje. Eso obliga a validar la salida por contrato en lugar de comprobar tipos, y a tener protocolos de recuperación que distingan un fallo de infraestructura de una alucinación.

¿Está “graph engineering” reconocido como término oficial? ¶

Todavía no del modo en que lo está “loop engineering”. En la literatura académica lo verás como flow engineering o graph-based orchestration. Es un concepto que está cristalizando ahora mismo, pero la práctica que describe ya está muy extendida en frameworks como LangGraph.

¿Cómo sé si mi grafo está mal diseñado? ¶

Señales típicas: reintentos que no acaban, nodos que arrancan sin sus datos, paralelismo que no ocurre aunque las tareas sean independientes, o fallos imposibles de atribuir a un nodo concreto. Casi siempre el problema está en cómo cableaste el grafo, no en un nodo aislado.

¿Un grafo de bucles puede engañarse a sí mismo? ¶

Sí, y es su fallo más traicionero. Si cada bucle solo vigila a otro bucle y ninguno mide algo del mundo real, tienes un circuito de confirmación mutua: coherente por dentro y desconectado por fuera. Se evita con anclas: medidas que no se pueden discutir (tests que se ejecutan, builds que compilan), nodos congelados que el optimizador no puede tocar y una definición de “mejor” que pones tú desde fuera del grafo.

¿Qué es el blast radius de un cambio de código? ¶

Es el conjunto de nodos del grafo de dependencias que se ven afectados cuando modificas uno. Se calcula recorriendo el grafo hacia atrás desde el nodo que cambias, siguiendo a sus dependientes: el radio 1 son los directos, el radio 2 y 3 los transitivos. Responde a la pregunta “si toco esto, ¿qué más se rompe?” con una lista concreta en lugar de una intuición, y por eso conviene calcularlo por recorrido del grafo y no preguntándole al modelo.

Fuentes ¶

• Addy Osmani, “Loop Engineering”
• Hu Wei, “From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution” (arXiv)
• LangChain, “Graph API overview” (documentación de LangGraph)
• LangChain, “The best AI agent frameworks in 2026”
• Zylos Research, “Graph-Based Agent Workflow Orchestration in Production: The 2026 Landscape”
• Burr, documentación oficial (DAGWorks)
• PocketFlow, repositorio en GitHub
• Griptape, repositorio en GitHub
• Axiom Refract, “What Is Blast Radius in Code? — Understanding Change Impact”
• Loom AI, “What Is Blast Radius Analysis?” (glosario de code intelligence)
• Suman Das, “Loop Engineering with Agents”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter