Graph Engineering · AI Agents · 2026
El término nació de un tweet de 12 palabras. El patrón tiene años. Y yo ya lo tenía grabado corriendo: las 5 olas de la ingeniería de IA, qué es un grafo de agentes sin humo, y tres demos en vivo con sistemas reales.
El veredicto honesto
Nadie lanzó un producto, nadie publicó un framework: una pregunta en X y de un día para otro todo el mundo hablaba de grafos. Pero que el nombre sea humo no significa que abajo no haya nada. Yo ese patrón lo tenía grabado desde antes de que la palabra existiera — y en este video está funcionando: tres agentes ruteando en vivo, un nodo fallando por falta de estado y siete construyendo un IDP completo, solos.
En los últimos años te vendieron cinco olas, una tras otra. Tres echaron raíces como disciplina. Dos explotaron como nombres nuevos para patrones que ya existían. Y ninguna mató a la anterior: conviven.
2020-21 → Prompt Engineering ✓ echó raíces (hoy absorbida)
jun 2025 → Context Engineering ✓ echó raíces (tweet → disciplina)
2025-26 → Harness Engineering ✓ echó raíces (la que importa)
2026 → Loop Engineering ✗ nombre nuevo, bash loop de siempre
jul 2026 → "Graph Engineering" ← nombre nuevo, grafo de siempre2020-2021 · Prompt Engineering
Cómo escribirle los prompts al modelo para que haga lo que tú quieres. Fue algo real — tiene estudios académicos — aunque hoy quedó absorbida por las olas siguientes. Echó raíces.
Junio 2025 · Context Engineering
Nació de un tweet de Tobi Lütke (CEO de Shopify) y Karpathy lo amplificó a los pocos días. Pero esta sí echó raíces de verdad: administrar qué entra en la ventana del modelo terminó teniendo revisión académica y una guía propia de Anthropic. Nombre nuevo, oficio nuevo.
2025-2026 · Harness Engineering
La que marca la diferencia. Anthropic publicó su trabajo de arneses a finales de 2025, OpenAI a comienzos de 2026, y hay una taxonomía formal en MartinFowler.com escrita por Birgitta Böckeler (Thoughtworks). Tres frentes distintos apuntando al mismo lugar: el entorno y los controles que le armas al agente para que trabaje de manera confiable.
2026 · Loop Engineering
¿Sabes qué es por debajo? Un bash loop: un ciclo que repite una tarea y verifica, algo que existe hace décadas. Ya hice un video entero sobre esto y mi veredicto fue claro: el nombre es humo, el cambio de abajo es real.
Julio 2026 · "Graph Engineering"
Nació de un tweet de 12 palabras de Peter Steinberger: "¿seguimos hablando de loops o ya nos pasamos a los grafos?". Nadie lanzó un producto, nadie publicó un framework. Por debajo: grafos de ejecución con nodos, aristas y estado — LangGraph los construye desde enero de 2024, incluyendo grafos con ciclos.
La vara correcta
La pregunta que de verdad importa no es si el nombre es nuevo: es si ese nombre le pone el dedo a un problema de ingeniería que antes no sabíamos separar bien. Context, sí. Harness, bastante. Loop, menos. Y graph, muy discutible: topología, routing, estado y orquestación existen hace décadas. Pero que el nombre sea humo no significa que abajo no haya nada real.
Tres piezas. Nada más.
Las unidades de trabajo. En mis demos cada nodo es un agente, aunque técnicamente podría ser una función o hasta otro grafo.
Las reglas que deciden qué nodo se ejecuta después. Pueden ser fijas (una cadena) o decidirse en vivo según la tarea (routing dinámico).
Lo que el sistema sabe mientras recorre el grafo. La decisión más importante: cómo la info de un nodo llega al siguiente.
LOOP → la política de REPETICIÓN
(cuándo repite algo y cuándo para)
GRAPH → la TOPOLOGÍA
(qué unidades hay, cómo se conectan,
qué camino toma la ejecución)
No son niveles, uno arriba del otro: son dos cosas
distintas del mismo sistema. Un grafo puede tener loops
adentro, y un loop puede recorrer varios nodos.Acá es casi donde todos se enredan. Por eso no tiene ningún sentido decir que el graph reemplazó al loop: LangGraph metía loops dentro del grafo hace más de dos años. Mira Loop Engineering ›
Si alguna vez conectaste dos procesos para que se pasaran trabajo, ya hiciste algo de esto. No tenías el nombre, pero sí tenías el patrón.
Dos nodos y una arista. La estructura más chica que ya puedes dibujar como grafo.
Dispara un proceso y deja un archivo para el siguiente. Eso es estado viajando por una arista.
Varios pasos conectados: nodos, aristas, estado. Un grafo con interfaz bonita.
Y ojo que eso mismo prueba el punto: si conectar dos procesos ya fuera graph engineering, entonces Jenkins, Airflow y cualquier motor de workflows llevan décadas haciéndolo. El patrón es viejo, el nombre es nuevo. La diferencia es que ahora tienes el nombre y el mapa para hacerlo a propósito, y no por accidente.
Cuando el grafo empieza a hacer trabajo real, aparece la pregunta clave: ¿cómo la info de un nodo llega al siguiente? No hay una sola forma correcta — en el video se ven las dos.
Estrategia 1 · Demo A2A
El orquestador le manda la tarea a un nodo, ese responde, y el orquestador le pasa esa respuesta al siguiente. De nodo en nodo, sin filesystem compartido. Así funcionan los 7 agentes en Cloud Run.
Estrategia 2 · Demo IDP
Cada nodo escribe un archivo y el siguiente lo lee del disco, como APIs internas. El de infraestructura no recibe parámetros: activamente lee lo que el arquitecto guardó.
La regla
Lo que importa no es dónde vive el estado — mensajes, archivos o base de datos: las dos estrategias son grafos. Lo que importa es que cada nodo reciba lo que necesita. Diseñar qué necesita cada nodo, quién se lo produce y qué pasa si nunca le llega: ese es el problema de ingeniería real debajo del nombre. Y no lo inventó ningún tweet — es arquitectura de software de siempre, aplicada a agentes.
Todos explican graph engineering con dibujos. Acá hay agentes de verdad, hablándose entre ellos, sin que yo toque nada. Grabado antes de que la palabra existiera.
Un orquestador que no tiene ni una herramienta propia: solo lee la tarjeta de cada agente y decide a quién delegar. Le pido registros DNS y rutea al nodo DNS, que le pega directo a la API de Cloudflare. Le pido un health check y rutea al de monitoreo. Cambié la tarea y cambió la ruta — el grafo decide el camino en vivo. Eso es lo que un diagrama estático no te puede enseñar.
Llamé al nodo de seguridad solo, saltándome la cadena, sin las decisiones que los nodos anteriores tendrían que haberle pasado. Quedó atado de manos. Y fíjate en el porqué: no falló por un bug ni porque el modelo sea malo — rompí la cadena y con eso rompí la condición que ese nodo necesitaba para arrancar. Ese es el problema de ingeniería real debajo del nombre: diseñar qué necesita cada nodo, quién se lo produce y qué pasa si nunca le llega.
El grafo más fácil de razonar: una cadena. Arquitecto, infraestructura, seguridad, CI/CD, observabilidad, DevEx y portal. Cada nodo escribe un archivo y el siguiente lo lee del disco — el estado se propaga por la cadena sin que nadie pase variables a mano. Siete nodos, cero clics. Y una confesión: con el modelo equivocado, los nodos se quedaban conversando entre ellos sin ejecutar nada. Un grafo no es magia, es ingeniería.
La pieza que casi nadie menciona. El graph decide quién trabaja después — pero qué hace ese nodo cuando le toca, eso ya es otra capa.
Dice a quién llamar: qué nodo sigue, por qué arista, con qué estado. La topología del trabajo.
Decide qué puede hacer ese nodo cuando le toca: sus tools, sus permisos, su sandbox. Sus límites.
Por qué importa
Porque va a ejecutar tareas perfectamente lógicas que tú nunca autorizaste: borrar una tabla porque estaba duplicada, reescribir un archivo porque había un error. Que el nodo de DNS no pueda borrar no es una instrucción amable tipo "no me borres por favor" — es que el tool de borrar literalmente no existe. La capacidad real de un nodo no se impone con un prompt: se impone en las tools, los permisos y el sandbox. Y esa, la tercera ola, es la que de verdad cambió mi trabajo.
El harness completo lo desarmé en otro video. Mira Harness Engineering › — y el enforcement por tools, en Agent Skills ›
¿Graph engineering es el fin del loop, como decía la pregunta viral? Esta es la frase que te llevas — la que ahora puedes decir tú.
LOOP → gobierna la REPETICIÓN (cuándo se repite algo)
GRAPH → gobierna las RELACIONES (y el camino de ejecución)
HARNESS → gobierna el ENTORNO (los controles que lo hacen confiable)
No son tres generaciones que se reemplazan.
Son tres dimensiones del mismo sistema — y pueden vivir
las tres a la vez: un grafo con loops adentro
y un harness alrededor.El término es humo
Topología, routing, estado y orquestación existen hace décadas. Si alguien te dice que esto lo inventaron esta semana, te está vendiendo algo.
Lo de abajo es real
Si sabes construir, hay algo real: nodos especializados, aristas que rutean y estado que fluye. Lo acabas de ver corriendo. Mi vara es la misma para todo: no te vendo la palabra, te muestro el sistema.
Las fuentes primarias del video, verificadas.
Peter Steinberger · 18 julio 2026
El tweet de 12 palabras que hizo explotar el término: 575K vistas en horas. Sin producto, sin framework — solo la pregunta.
LangGraph (LangChain) · Enero 2024
Nodos, aristas y estado en producción desde mucho antes del tweet — incluyendo grafos cíclicos: loops dentro del grafo desde el día uno.
Data Science Dojo · 2026
El artículo que pone la lista sobre la mesa: LangGraph, Google ADK, Microsoft Agent Framework — años construyendo nodos, aristas y estado.
Anthropic · Noviembre 2025
El trabajo de arneses de Anthropic: la capa que decide qué puede hacer cada nodo cuando le toca trabajar. La ola que sí echó raíces.
Birgitta Böckeler (Thoughtworks) · Abril 2026
La formalización del harness: tres frentes institucionales (Anthropic, OpenAI, Thoughtworks) convergiendo en la misma disciplina.
Tobi Lütke + Andrej Karpathy · Junio 2025
La prueba de que "nació de un tweet" no descalifica: context también nació así — y echó raíces con revisión académica y guía de Anthropic. La vara es otra.
Cada pieza de este grafo ya la mostré corriendo en otro video. Estos son los que aparecen en los clips.
La secuela directa: el loop es la política de repetición que vive dentro de los nodos de este grafo. Mi veredicto sobre la ola anterior.
La ola que sí importa: el harness decide qué puede hacer cada nodo cuando le toca trabajar. El graph coordina, el harness impone.
Los 7 nodos en producción: cada agente con su propia URL y el estado viajando en mensajes, de nodo en nodo.
El IDP de la demo: el arquitecto decide el stack y 7 agentes lo construyen en cadena, comunicándose por archivos compartidos.
El enforcement del nodo: que borrar no exista como tool no es una instrucción amable, es una capacidad recortada.
Otro grafo real: 4 instancias de Claude debaten y 3 subagentes ejecutan tareas acotadas. Topología de equipo.
Lo esencial sobre graph engineering.
Es diseñar el grafo en el que corren tus agentes: qué nodos especializados existen, qué aristas rutean el trabajo y qué estado viaja por esas aristas. El término explotó por un tweet de Peter Steinberger en julio de 2026, pero el patrón — nodos, aristas y estado — existe hace años: LangGraph lo construye desde enero de 2024 y cualquier motor de workflows lleva décadas haciéndolo.
No, y la pregunta misma es el error. El loop es la política de repetición: cuándo un agente repite algo y cuándo para. El graph es la topología: qué unidades hay, cómo se conectan y qué camino toma la ejecución. No son niveles uno arriba del otro — son dos cosas distintas del mismo sistema, tan distintas que un grafo puede tener loops adentro y un loop puede recorrer varios nodos. LangGraph metía loops dentro del grafo hace más de dos años.
El loop gobierna la repetición: cuándo se repite algo. El graph gobierna las relaciones y el camino de ejecución. Y el harness gobierna el entorno y los controles que hacen que todo eso sea confiable. No son tres generaciones que se reemplazan: son tres dimensiones del mismo sistema, y pueden vivir las tres a la vez — un grafo con loops adentro y un harness alrededor.
Nadie lanzó un producto ni publicó un framework. El 18 de julio de 2026, Peter Steinberger tuiteó "¿seguimos hablando de loops o ya nos pasamos a los grafos?" — 12 palabras que amplificaron un término para un patrón viejo. El substrato real lleva años: LangGraph (enero 2024), Google ADK y Microsoft Agent Framework ya construían grafos de agentes con nodos, aristas y estado mucho antes del nombre.
Es lo que el sistema sabe mientras recorre el grafo — lo que cada nodo necesita recibir para trabajar. Y no hay una única forma correcta: puede viajar en los mensajes entre agentes (como en la demo A2A), vivir en archivos compartidos que cada nodo lee y escribe (como en el IDP de 7 agentes), o estar en una base de datos. Lo que importa no es dónde vive: es que cada nodo reciba lo que necesita. En el video se ve un nodo fallar en vivo exactamente por eso.
Estructuralmente sí: nodos, aristas y estado que puedes dibujar. Un cron que deja un archivo para el siguiente proceso ya es un grafo. Y eso prueba el punto: si conectar dos procesos fuera graph engineering, los motores de workflows llevan décadas haciéndolo. La diferencia con un grafo de agentes es que los nodos razonan — el routing puede decidirse en vivo según la tarea, no solo seguir un diagrama fijo.
Es cuando el grafo decide el camino en vivo: el orquestador mira la tarea, lee la tarjeta de cada nodo disponible y elige a quién delegar. Las aristas ya existen; lo que cambia es cuál se toma, y eso se decide según la tarea. En la demo del video, un orquestador sin ninguna tool propia delega DNS al nodo DNS y health checks al de monitoreo — cambias la tarea y cambia la ruta.
Comunidad
Los 7 agentes que construyen el IDP solos (Google ADK + protocolo A2A) y el patrón completo para que lo levantes tú — paso a paso, con repos reales. Acceso gratis a la comunidad; los cursos completos van en el tier Premium.
Únete a Agentic Engineers →Canal YouTube
@NicolasNeiraGarcia
ADK · A2A · Claude Code · Automatización · Infraestructura