Hay momentos en tecnología en los que uno siente que se quedó atrás durante un fin de semana. El viernes todavía estábamos tratando de entender una idea, el lunes aparece otra etiqueta que promete superarla y, antes de que podamos probar si algo cambió de verdad, ya hay cursos, diagramas, manifiestos y perfiles profesionales alrededor del nuevo término.
En inteligencia artificial esa sensación se volvió casi permanente. Pasamos de hablar de prompt engineering a context engineering, después de harness engineering, más tarde de loop engineering y ahora de graph engineering. Cada nombre intenta capturar una parte real del problema, pero la velocidad con la que se reemplazan también produce una confusión bastante menos útil: parece que cada cambio de vocabulario inaugura una disciplina completa y deja obsoleto todo lo anterior.
El 18 de julio de 2026, Peter Steinberger publicó en X una pregunta de apenas doce palabras:
“Are we still talking loops or did we shift to graphs yet?”
La frase se puede traducir como: “¿Seguimos hablando de ciclos o ya pasamos a los grafos?”. No presentó un framework, no describió un patrón nuevo y ni siquiera utilizó la expresión Graph Engineering. Sin embargo, alcanzó para empujar una conversación enorme. En pocos días aparecieron explicaciones, comparaciones y declaraciones sobre una nueva etapa de la ingeniería de agentes.
No me interesa discutir si el término es válido o si debería desaparecer. Esa pelea se vuelve vieja casi tan rápido como la etiqueta. Me interesa algo más cercano a nuestro trabajo: qué ocurre cuando el nombre de una práctica cambia más rápido que nuestra capacidad de entenderla, y cuánto cuesta tomar decisiones técnicas desde esa sensación de urgencia.
Porque detrás del ruido hay dos verdades que pueden convivir. Diseñar flujos con estado, bifurcaciones, ciclos y varios agentes no nació en julio de 2026. Pero los agentes actuales sí están volviendo más visible, más frecuente y también más difícil ese tipo de arquitectura. Si reducimos todo a “es puro humo”, podemos ignorar un problema real. Si aceptamos cada nombre como una revolución, podemos terminar reconstruyendo lo que ya sabíamos, solo que con menos memoria y más ansiedad.
Doce palabras y una disciplina nueva#
La velocidad de esta historia es parte del tema. Steinberger hizo una pregunta breve y ambigua. Se podía leer como una observación técnica, pero también como una broma sobre la rapidez con la que la industria cambia de vocabulario. La interpretación se volvió más grande que el mensaje original.
Eso no significa que la expresión haya nacido de la nada. Hay usos anteriores y, para cuando apareció aquel post, distintas personas ya venían describiendo la evolución desde agentes que repiten un ciclo hacia sistemas compuestos por varios nodos conectados. Lo que ocurrió ese fin de semana no fue la invención de una técnica. Fue la cristalización de un nombre.
Esta diferencia parece menor, pero es importante. Cuando una tecnología nueva obliga a desarrollar capacidades que antes no existían, tiene sentido revisar nuestras categorías. En cambio, cuando una etiqueta agrupa prácticas conocidas bajo un título atractivo, conviene separar el valor del vocabulario del valor de la arquitectura.
LangChain lo reconoció pocos días después desde un lugar difícil de ignorar: el equipo construye LangGraph, uno de los frameworks más asociados con esta conversación. En un artículo titulado “3 Years of Graph Engineering with LangGraph”, sus autores escribieron que la idea no era nueva y la describieron como el nombre más reciente para una forma ya establecida de construir agentes confiables.
Ese reconocimiento no invalida el término. Le devuelve proporción.
Las palabras son necesarias. Nos permiten señalar un conjunto de problemas sin explicarlos desde cero en cada conversación. Cuando alguien habla de un patrón Observer, una cola de mensajes o una máquina de estados, no está fingiendo haber inventado esos mecanismos; está usando un vocabulario compartido para pensar y trabajar con otros. El problema empieza cuando el nombre deja de ser un atajo para conversar y se convierte en la prueba de que estamos frente a una ruptura.
Entonces ya no preguntamos qué cambió en el sistema. Preguntamos si nuestro equipo “hace Graph Engineering”, si deberíamos contratar un “Graph Engineer” o si la arquitectura actual quedó vieja. La discusión se mueve desde el problema hacia la identidad, y ese desplazamiento tiene consecuencias.
Lo que ya sabíamos antes de los agentes#
Si le quitamos el nombre de moda, el dibujo resulta bastante conocido. Tenemos una serie de pasos que reciben información, realizan una tarea, modifican un estado y deciden qué debe ocurrir después. Algunos pasos pueden ejecutarse en paralelo; otros dependen de un resultado anterior. Puede haber condiciones, reintentos, caminos alternativos, pausas, intervención humana y una forma explícita de terminar.
La documentación actual de LangGraph lo explica con una sencillez que ayuda: los nodos hacen el trabajo y las aristas indican qué sucede después. El estado atraviesa ese recorrido y permite que el sistema conserve la información necesaria para continuar. Un nodo puede contener un modelo, un agente completo o código tradicional. La forma de grafo no obliga a que todo sea inteligente ni autónomo.
Nada de eso debería resultarnos extraño. En diciembre de 2016, casi una década antes de esta discusión, AWS presentó Step Functions como una forma de coordinar aplicaciones distribuidas mediante flujos visuales y máquinas de estados. Los estados podían ejecutarse de manera secuencial o paralela, tomar decisiones, manejar errores y definir transiciones. Azure Logic Apps, Google Cloud Workflows y muchas herramientas de automatización resolvieron variantes del mismo problema.
Tampoco es una novedad exclusiva de la nube. Quienes trabajamos con procesos de negocio, motores de workflows, pipelines de datos, sagas, orquestadores o interfaces con estados complejos venimos utilizando ideas parecidas desde hace años. Cambian las herramientas, las restricciones y el nivel de abstracción, pero persisten las preguntas: dónde vive el estado, quién decide la próxima transición, qué ocurre cuando un paso falla, cómo reanudamos el proceso y cómo entendemos lo que pasó después.
Por eso decir que pasamos “de ciclos a grafos” puede ser útil como explicación inicial, pero también puede confundir. Un ciclo ya puede formar parte de un grafo. De hecho, un agente que planifica, ejecuta, verifica y vuelve a intentar hasta alcanzar una condición de salida es una estructura cíclica dentro de un flujo mayor. No estamos reemplazando una figura por otra como quien descarta una tecnología antigua. Estamos ampliando el nivel en el que diseñamos la coordinación.
Un agente puede resolver una tarea dentro de su propio ciclo. Un sistema más complejo puede necesitar un nodo que investigue, otro que escriba, uno que revise, una validación determinista y una intervención humana cuando la confianza sea baja. Ese conjunto puede representarse como un grafo, pero el dibujo no resuelve por sí solo ninguno de los problemas difíciles. Solamente los hace visibles.
Hay algo nuevo, pero no está en la forma#
Sería cómodo terminar acá y decir que todo esto son máquinas de estados con otro nombre. También sería incompleto.
Lo que está cambiando no es el concepto matemático de grafo ni la idea de orquestar pasos. Está cambiando lo que podemos colocar dentro de cada nodo. Durante años, un nodo de un workflow representaba una función, una llamada a un servicio o una tarea relativamente acotada. Hoy puede contener un agente que usa herramientas, consulta distintas fuentes, toma decisiones intermedias y trabaja durante varios minutos antes de devolver un resultado.
Esa diferencia aumenta la capacidad del sistema, pero también introduce una incertidumbre nueva. Una función tradicional debería producir una salida razonablemente predecible para una entrada conocida. Un agente opera dentro de límites bastante más blandos: interpreta una instrucción, selecciona herramientas, administra contexto y puede recorrer caminos diferentes en dos ejecuciones parecidas.
LangChain describe esta evolución de una manera interesante: antes los nodos podían contener código determinista o una llamada a un modelo; ahora pueden contener una ejecución completa de un agente. Desde ese punto de vista, la novedad no está en conectar cajas con flechas, sino en que cada caja puede tomar decisiones más complejas y menos previsibles.
Microsoft muestra algo similar en la documentación de GraphFlow para AutoGen. Su flujo dirigido permite secuencias, trabajo en paralelo, bifurcaciones condicionales y ciclos con condiciones de salida. La propia documentación recomienda usarlo cuando hace falta controlar con precisión el orden de intervención de los agentes o cuando resultados diferentes deben conducir a pasos distintos. También advierte que la funcionalidad todavía es experimental.
Ese último detalle importa. En medio del entusiasmo es fácil mirar un diagrama de varios agentes y asumir que más especialización produce automáticamente un sistema mejor. Pero cada nodo agrega llamadas, contexto, costo, latencia y una nueva superficie de error. Cada transición necesita una regla. Cada resultado intermedio puede contaminar el siguiente. Y si varios agentes trabajan en paralelo, tarde o temprano alguien tiene que combinar sus respuestas, resolver contradicciones y decidir cuál merece confianza.
El grafo permite representar esa complejidad. No la elimina.
Quizás ahí esté el aporte más valioso de esta etapa: estamos empezando a discutir la arquitectura de los agentes más allá del modelo y del prompt. Hablamos de persistencia, observabilidad, recuperación, límites de autoridad, condiciones de salida, validaciones y puntos de intervención humana. Son temas viejos en ingeniería de software, pero adquieren una forma particular cuando parte del flujo puede razonar, improvisar y equivocarse con una respuesta convincente.
Negar esa diferencia porque la estructura general ya existía sería tan pobre como declarar que todo cambió porque apareció un nombre nuevo. La práctica técnica está evolucionando. Lo que no necesitamos es fingir que evoluciona sin historia.
El costo de renombrar el oficio cada seis semanas#
Podría parecer que esta discusión solo afecta a quienes pasan demasiado tiempo en redes sociales. Si mañana dejamos de decir Graph Engineering y aparece otra expresión, los sistemas van a seguir funcionando igual. Sin embargo, las etiquetas no se quedan en la conversación. Entran en las hojas de ruta, en los presupuestos, en las búsquedas laborales y en la forma en que los equipos evalúan su propio conocimiento.
Cuando cada patrón se presenta como una disciplina independiente, la identidad profesional empieza a pegarse a herramientas y términos cada vez más pequeños. Ya no alcanza con ser ingeniero de software y entender orquestación, sistemas distribuidos, estado, concurrencia y recuperación. Parece necesario convertirse en especialista del nombre que está circulando esa semana.
Esto produce una sensación rara: gente con años resolviendo procesos complejos puede sentirse atrasada porque no reconoce una etiqueta, mientras alguien que aprendió la etiqueta ayer puede parecer actualizado sin haber enfrentado nunca el problema en producción. El vocabulario, que debería ayudarnos a compartir conocimiento, empieza a ocultar la experiencia que importa.
También complica la contratación. Si una empresa publica que busca un “Graph Engineer”, ¿qué está pidiendo realmente? ¿Alguien que conozca LangGraph? ¿Una persona con experiencia en sistemas multiagente? ¿Un arquitecto capaz de diseñar workflows con estado? ¿Un ingeniero de datos que entienda grafos? ¿O simplemente alguien que pueda construir el producto que la empresa todavía no terminó de definir?
Una búsqueda así puede atraer perfiles por coincidencia de palabras y dejar afuera a personas que dominan los fundamentos. Peor aún, puede hacer que la empresa crea que su problema se resuelve incorporando una especialidad, cuando todavía no sabe si necesita más de un agente.
En “2025: el año en que la IA se volvió plural y el criterio se volvió escaso” planteaba que, cuando las herramientas se multiplican, el diferencial deja de ser el acceso y pasa a ser el criterio para elegir. Con las etiquetas ocurre algo parecido. Cuantos más nombres aparecen, menos valor tiene conocerlos todos y más importante se vuelve entender qué problema hay debajo.
La deuda técnica también puede empezar por una palabra. Un equipo ve una arquitectura de referencia, siente que un solo agente quedó anticuado y divide un flujo simple entre cinco agentes especializados. Aparecen routers, memorias compartidas, subgrafos, evaluadores y capas de coordinación. La demo se vuelve más impresionante, pero ahora hay que observar cinco comportamientos probabilísticos, pagar sus ejecuciones, depurar sus conversaciones y mantener reglas de transición que antes no existían.
Si esa complejidad permite resolver algo que el diseño anterior no podía, puede estar justificada. Si entró para demostrar que el equipo adoptó el paradigma del momento, se transforma en deuda impulsada por el miedo a quedar atrás.
Un grafo también puede organizar mejor nuestros errores#
Existe una tentación particular en los sistemas multiagente: confundir división del trabajo con calidad. Como cada agente tiene un rol claro —investigador, programador, revisor, tester— el conjunto se parece a un equipo y transmite una sensación de control. Pero poner nombres profesionales dentro de cajas no convierte automáticamente sus interacciones en un proceso confiable.
Un agente investigador puede encontrar una fuente incorrecta. El redactor puede usarla con seguridad. El revisor puede evaluar la coherencia del texto sin comprobar el origen. El agente final puede aprobar un resultado prolijo que conserva el error inicial. El grafo habrá funcionado exactamente como fue diseñado y, aun así, habrá producido algo equivocado.
En este sentido, el problema se conecta con “Lo que la IA no puede diseñar”. Allí la tensión estaba entre producir y entender: un sistema puede generar mucho material correcto en apariencia sin que nadie haya construido un modelo mental suficiente para sostenerlo. Un grafo de agentes puede aumentar esa distancia. Ya no delegamos solo la producción de código o texto; también delegamos partes de la coordinación, la revisión y la decisión sobre cuándo el trabajo está terminado.
Por eso una arquitectura de agentes no debería empezar por cuántos nodos tiene, sino por dónde necesita determinismo. ¿Qué resultado puede quedar librado al juicio de un modelo y cuál exige una regla verificable? ¿Qué acciones son reversibles? ¿Dónde debemos guardar el estado para poder reconstruir una ejecución? ¿Qué agente tiene permiso para actuar y cuál solamente puede sugerir? ¿Quién valida que una condición de salida representa éxito y no cansancio del sistema?
Estas preguntas no aparecen en el dibujo más vistoso. Aparecen cuando intentamos operar el sistema.
Un grafo bien diseñado puede ayudarnos justamente porque permite hacer explícitos esos límites. Puede separar la exploración probabilística de la validación determinista. Puede establecer una pausa antes de una acción sensible, guardar checkpoints, restringir herramientas por nodo y llevar un registro de las transiciones. También puede permitir que distintas tareas usen modelos diferentes según costo, capacidad o riesgo.
Pero para obtener esos beneficios necesitamos tratar el grafo como arquitectura y no como escenografía. Las flechas deben representar decisiones que podamos explicar. El estado tiene que tener dueño, forma y ciclo de vida. Los errores deben conducir a una recuperación pensada, no a un ciclo infinito de agentes intentando convencerse entre sí. Y la observabilidad tiene que permitir entender qué ocurrió sin leer una conversación interminable después del incidente.
La pregunta importante no es si el sistema parece una organización. Es si alguien puede hacerse cargo de él cuando la organización artificial se equivoca.
La objeción necesaria: los nombres también construyen conocimiento#
Hasta acá podría parecer que la solución es rechazar cualquier término nuevo y volver a hablar únicamente de patrones clásicos. No creo que alcance.
Un nombre puede ordenar una conversación dispersa. Context engineering, por ejemplo, ayudó a mover el foco desde la habilidad de escribir una instrucción ingeniosa hacia un problema más amplio: qué información recibe el modelo, cuándo la recibe, cómo se selecciona y qué se deja afuera. Muchas de esas prácticas ya existían, pero el nombre permitió verlas como parte de una misma responsabilidad.
Con Graph Engineering puede pasar algo parecido. La expresión puede servir para agrupar el diseño de nodos, transiciones, estado compartido, bifurcaciones, paralelismo, checkpoints y controles humanos en sistemas de agentes. Para alguien que llega desde el desarrollo de aplicaciones y nunca trabajó con un motor de workflows, esa etiqueta puede abrir una puerta hacia conceptos que de otro modo quedarían escondidos detrás de terminología académica o de infraestructura.
Además, los sistemas con agentes sí presentan problemas que merecen especialización. Evaluar salidas no deterministas, administrar contexto entre nodos, evitar que un error se propague y diseñar permisos para componentes autónomos no son detalles menores. Que sus fundamentos tengan historia no significa que podamos resolverlos de memoria.
El punto no es dejar de nombrar. Es pedirle al nombre que haga un trabajo útil.
Una etiqueta vale cuando reduce ambigüedad, reúne problemas relacionados y permite que dos personas entiendan de qué están hablando. Pierde valor cuando se usa para inflar una novedad, reemplazar la explicación o crear una identidad profesional antes de que exista un cuerpo de conocimiento relativamente estable.
Tal vez la prueba más simple sea intentar explicar la práctica sin usar su nombre. Si podemos decir que necesitamos coordinar varios agentes, conservar estado, ejecutar algunas tareas en paralelo, decidir rutas según resultados y detener el flujo frente a una acción sensible, ya tenemos una conversación técnica. Después podemos llamar a eso Graph Engineering para abreviar. Si solo podemos defender la arquitectura repitiendo la etiqueta, probablemente todavía no entendimos qué estamos construyendo.
Una forma más tranquila de mirar la próxima ola#
Los líderes técnicos no pueden ignorar todas las tendencias hasta que maduren. Parte del trabajo consiste justamente en mirar antes, experimentar y detectar qué puede cambiar el producto o la forma de construirlo. El problema no es prestar atención. Es convertir atención en adopción antes de pasar por una pregunta concreta.
Frente a una nueva “ingeniería”, conviene empezar por traducirla. ¿Qué problema resuelve en nuestro sistema? ¿Qué capacidad nos da que hoy no tenemos? ¿Qué complejidad agrega? ¿Podemos obtener el mismo resultado con una estructura más simple? ¿Seguiría teniendo sentido si mañana dejáramos de usar el nombre?
No hace falta convertir esas preguntas en un comité que bloquee cualquier experimento. Pueden ser un filtro liviano. Si queremos probar una arquitectura de varios agentes, armemos un caso acotado, midamos calidad, costo, tiempo y capacidad de recuperación. Comparemos contra un agente único o incluso contra un workflow mayormente determinista. Observemos no solo el caso feliz, sino también qué tan difícil resulta explicar un fallo.
Esta comparación es importante porque la sofisticación visual engaña. Un grafo con muchos nodos puede parecer más evolucionado que un ciclo simple, pero la arquitectura no es una escalera en la que siempre debamos subir al peldaño siguiente. A veces un agente con buenas herramientas, una condición de salida clara y una validación sólida resuelve mejor el problema. Otras veces ni siquiera necesitamos un agente: necesitamos código.
La decisión madura no es elegir la forma más nueva. Es usar la menor complejidad capaz de sostener el comportamiento que necesitamos.
Eso también cuida a los equipos. La fatiga no aparece solo por aprender herramientas nuevas; aparece por sentir que el conocimiento adquirido vence demasiado rápido. Cuando conectamos una tendencia con fundamentos conocidos, el aprendizaje deja de ser una carrera por memorizar nombres. Un desarrollador que entiende máquinas de estados, concurrencia, idempotencia, observabilidad, contratos y manejo de errores tiene una base para evaluar LangGraph, AutoGen o la herramienta que aparezca después. Tendrá que aprender APIs y particularidades, claro, pero no empieza de cero cada vez.
Esa continuidad devuelve algo de calma. Nos permite reconocer la novedad sin entregarle toda la agenda.
Lo que queda cuando el nombre desaparece#
Graph Engineering puede consolidarse como una disciplina reconocible o puede ser reemplazado pronto por otra expresión. No sabemos todavía cuánto va a durar la etiqueta. Lo que sí sabemos es que los sistemas de agentes van a necesitar coordinación, estado, límites, evaluación, recuperación y personas capaces de entender el conjunto.
Peter Steinberger no anunció una tecnología con aquella pregunta. Quizás por eso la reacción resulta tan reveladora. Doce palabras alcanzaron para que una parte de la industria sintiera que había comenzado una etapa nueva. Esa velocidad habla menos de los grafos que de nuestra necesidad de ordenar un campo que cambia demasiado rápido.
Los nombres pueden ayudarnos a hacerlo, siempre que no confundamos el mapa con el territorio. Un mapa nuevo puede mostrar caminos que antes no veíamos, pero no cambia las montañas, los riesgos ni la distancia que hay que recorrer. En software, esas montañas siguen siendo bastante conocidas: sistemas que fallan, estados que se pierden, decisiones que nadie puede explicar, dependencias que se multiplican y equipos que terminan sosteniendo lo que una demo no mostró.
La ingeniería empieza cuando bajamos de la etiqueta a esas consecuencias.
Por eso, frente al próximo término, quizás no necesitemos correr a cambiar nuestros títulos ni reconstruir la arquitectura. Podemos hacer algo menos espectacular y bastante más útil: preguntar qué problema nombra, qué parte es realmente nueva y qué fundamentos siguen siendo los mismos.
Si después de quitarle el nombre la idea todavía mejora nuestro sistema, vale la pena aprenderla. Si solo queda la urgencia de no quedar afuera de la conversación, tal vez no estemos frente a una nueva ingeniería. Tal vez estemos frente al viejo miedo de siempre, esta vez dibujado como un grafo.
Fuentes consultadas#
- Peter Steinberger, “Are we still talking loops or did we shift to graphs yet?”, X, 18 de julio de 2026.
- Sydney Runkle y Harrison Chase, “3 Years of Graph Engineering with LangGraph”, LangChain, 22 de julio de 2026.
- LangChain, “Graph API overview”, documentación de LangGraph, consultada el 27 de julio de 2026.
- Jeff Barr, “New – AWS Step Functions – Build Distributed Applications Using Visual Workflows”, AWS News Blog, 1 de diciembre de 2016.
- Microsoft, “GraphFlow (Workflows)”, documentación de AutoGen, consultada el 27 de julio de 2026.