¿Es real el 'graph engineering'? Del loop engineering al debate sobre grafos de agentes

Por Turing Post · 20 de julio de 2026.

El editorial de esta edición de FOD analiza un fenómeno muy reciente en la conversación pública sobre IA agéntica: la aparición del término 'graph engineering' apenas seis semanas después de que se popularizara el término 'loop engineering', y cómo en cuestión de días la comunidad ya está dando por muerto el segundo para sustituirlo por el primero.

El origen del debate se sitúa el 18 de julio, cuando Peter Steinberger preguntó en X: '¿Seguimos hablando de loops o ya hemos pasado a grafos?'. Pocas horas después, Hamel Husain publicó lo que el newsletter describe como el 'obituario' del loop engineering, con un post titulado 'Loop Engineering Is Dead. Enter Graph Engineering'. Según Turing Post, en el fin de semana siguiente ya habían surgido cursos, roadmaps, stacks de herramientas e hilos explicando que Microsoft, Stanford y Anthropic habrían 'descubierto' el graph engineering simultáneamente.

El término 'loop engineering' había sido acuñado y popularizado por Addy Osmani en un ensayo publicado el 7 de junio, que a su vez se apoyaba en un eslogan anterior de Steinberger y en una declaración del creador de Claude Code, Boris Cherny, quien afirmó: 'Ya no prompteo a Claude'; su trabajo, explicaba, consistía en escribir los loops que lo hacen por él. La idea central del loop engineering es no guiar al agente turno a turno, sino darle un objetivo, una forma de comprobar su propio trabajo y un ciclo que pueda repetir hasta completar la tarea, algo con precedentes en ciencia e ingeniería de software.

El artículo explica que un loop describe el ciclo básico de un agente (buscar el siguiente paso, planificar, actuar, comprobar el resultado, continuar o detenerse), pero que este esquema deja de ser suficiente cuando la tarea se complica: partes que pueden ejecutarse en paralelo, pasos que requieren modelos distintos (uno de código, otro de búsqueda), un agente que produce una respuesta mientras otro intenta refutarla, o decisiones que necesitan aprobación humana frente a otras que pueden automatizarse. En ese punto, diseñar el loop deja de ser suficiente y hay que decidir cómo se conectan las distintas piezas: esa estructura mayor es lo que se llama grafo, compuesto por nodos (una unidad de trabajo: un agente, una llamada a un modelo, código ordinario o una decisión humana), aristas (qué ocurre después) y estado (la información que pasa de un paso a otro). El texto señala, con cierta ironía, que un loop ya es en sí mismo un grafo: simplemente uno cuyo camino vuelve a un nodo anterior.

Según el editorial, nada de esto es nuevo para la ingeniería de software (máquinas de estados, DAGs, motores de workflow y sistemas de orquestación llevan décadas haciendo versiones de esto), y recuerda que LangChain lanzó LangGraph en enero de 2024 específicamente para ayudar a construir workflows de agentes con estado. Lo que sí estaría cambiando es el rol que se le asigna al modelo dentro de ese sistema: los primeros sistemas de agentes pedían al modelo que hiciera casi todo (decidir qué pasa después, elegir herramienta, interpretar el resultado, actualizar el plan, decidir si detenerse), lo que resultaba vistoso en una demo pero generaba fallos igualmente generales en producción: loops innecesarios, saltos de lógica de negocio, pérdida de estado y contextos saturados de salidas de herramientas.

El artículo cita dos ejemplos concretos de esta tendencia. Por un lado, Google habría hecho explícito este problema al presentar Agent Development Kit (ADK) 2.0, defendiendo que el código debe controlar el enrutamiento predecible mientras los modelos se encargan de los pasos que requieren interpretación o juicio. Por otro lado, Anthropic abordaría el mismo problema desde otro ángulo: los 'dynamic workflows' de Claude Code permiten que Claude escriba un script de orquestación en JavaScript que coordina subagentes en paralelo, de forma que, al codificar el workflow, el modelo gasta menos tokens decidiendo repetidamente qué hacer a continuación. Para Turing Post, esta sería una versión práctica de 'graph engineering': el modelo opera dentro de un sistema de ejecución más amplio, donde la fiabilidad depende también de cómo se enruta el trabajo, se preserva el estado, se verifican las salidas y se gestionan los fallos.

El texto advierte además de que buena parte de la confusión actual viene de que la palabra 'grafo' se usa para cosas distintas, y propone una distinción en cuatro categorías: (1) grafo de control, la estructura del workflow y las reglas sobre qué se ejecuta después, usado para orquestar workflows de agentes, con ejemplos como LangGraph y ADK; (2) grafo de conocimiento, información almacenada como entidades y relaciones, usado para mejorar la recuperación y el razonamiento sobre documentos, con GraphRAG de Microsoft como ejemplo; (3) traza de ejecución, lo que ocurrió durante una ejecución concreta de un agente, usado para depuración y observabilidad; y (4) grafo de mejora, un concepto propuesto durante el fin de semana por Carlos Perez, consistente en loops que se optimizan, verifican y auditan entre sí (un loop optimiza una métrica, otro vigila la contramétrica, y otros auditan si esas métricas siguen representando el objetivo real), relevante para sistemas que se automejoran, ya que un loop de optimización sin un loop de verificación puede volverse muy bueno en producir el resultado equivocado.

Finalmente, el editorial desmiente de forma explícita una afirmación que se habría viralizado durante el fin de semana: que el 'graph engineering' habría sustituido al RAG en Microsoft, Stanford y Anthropic, logrando un 18% más de precisión y un 85% menos de coste. Turing Post afirma tajantemente que 'eso, sencillamente, no es cierto', y precisa que esas cifras de rendimiento procedían en realidad de un paper que aplicaba Grap[...] (el cuerpo del correo se corta aquí, por lo que no se dispone del resto de la explicación).

El correo incluye también, fuera del editorial principal, una sección 'This Week in Turing Post' con enlaces a piezas de la propia publicación (viernes: 'Global AI Affairs' sobre las limitaciones de los rankings globales de IA; domingo: 'Library' sobre protocolos de IA que todo builder debería conocer) y un bloque patrocinado por MongoDB sobre infraestructura para agentes en producción, que cita una predicción de Gartner según la cual el 40% de los proyectos de IA agéntica serán cancelados para 2027, no por el modelo sino porque fallan primero la seguridad, el coste y la evaluación.