¿Qué es el graph engineering? La explicación corta y la letra pequeña

Un compañero me escribió el viernes por la noche con una captura y tres palabras: «¿esto qué es?». En la captura, alguien anunciaba con mucha seguridad que el prompt engineering estaba muerto y que ahora lo que se llevaba era el graph engineering. Le mandé un audio de dos minutos. Esta es la versión escrita, y va primero la respuesta, que es lo que uno quiere encontrar cuando busca un término.

La explicación corta

Graph engineering es organizar varios agentes de IA como una máquina de estados. Cada nodo del grafo es un agente con una tarea concreta y acotada; cada arista es el contexto que ese agente le pasa al siguiente. El trabajo avanza por pasos definidos de antemano, con ramas, condiciones y, si hace falta, vueltas atrás a un nodo anterior.

Lo que sustituye es el patrón contrario: un único agente que recibe la tarea entera y da vueltas en un bucle —piensa, llama a una herramienta, mira el resultado, vuelve a pensar— hasta que él mismo decide que ha terminado. En ese modelo, el modelo carga con toda la conversación acumulada y toma cada decisión sobre la marcha. En el grafo, buena parte de esas decisiones las tomó antes una persona al dibujar las aristas, y cada nodo ve solo el trozo de contexto que le corresponde. Menos libertad, más control, resultados más repetibles.

Un grafo que se puede ver

Abstracto suena a nada, así que pongamos uno encima de la mesa. Entra una incidencia de soporte de una tienda online. El grafo podría ser este:

• Nodo 1 — Clasificador. Lee el mensaje del cliente y devuelve una etiqueta: pedido, devolución, incidencia técnica o «esto es un humano quejándose, sácalo de aquí». Es lo único que hace. Su salida es una palabra.
• Nodo 2 — Recolector. Recibe solo la etiqueta y el número de pedido. Consulta el sistema, saca el estado del envío, el histórico y la política aplicable. No ha leído el mensaje original y no le hace falta.
• Nodo 3 — Redactor. Ahora sí recibe las dos cosas: el mensaje del cliente y los datos. Escribe la respuesta.
• Nodo 4 — Revisor. Comprueba que la respuesta no promete nada que no esté en la política. Si pasa, sale hacia el envío. Si no pasa, la arista vuelve al nodo 3 con el motivo del rechazo.

Esa arista de vuelta del 4 al 3 es la parte interesante, y también la que se lleva el dinero. Volvemos a ella en un momento.

Ahora la letra pequeña

El término se puso de moda de la forma habitual: un tuit que circuló mucho, una tanda de artículos escritos en los días siguientes y, de repente, un montón de gente segurísima de que esto lo cambia todo. La historia de origen se cuenta sola porque encaja con el guion: había un patrón, alguien le puso nombre, el nombre viajó más rápido que el patrón.

Y ese patrón lleva por aquí bastante tiempo. LangGraph, la librería de LangChain, se llama así precisamente porque su modelo mental es un grafo de estados con nodos y aristas; existe desde antes de que nadie hablara de disciplina alguna. Make y n8n llevan años dejándote dibujar exactamente esto con el ratón, con ramas condicionales, reintentos y todo, y últimamente con nodos que son llamadas a un modelo. Y las máquinas de estados finitos son anteriores a casi todo lo demás que hay en tu ordenador: se estudian en segundo de carrera y se usaban para diseñar centralitas telefónicas.

Lo nuevo, entonces, es el nombre. Que no es poco: los nombres son lo que permite que dos personas discutan un diseño sin dibujar en una servilleta. Pero conviene saber qué se está comprando.

Prompt, context, harness, loop, graph

Merece la pena mirar la serie entera, porque el patrón salta a la vista. Primero fue el prompt engineering: escribir bien la instrucción. Después el context engineering: decidir qué información entra en la ventana y en qué orden. Luego el harness: el andamiaje alrededor del modelo, las herramientas que puede llamar, los límites. Después el agent loop: el ciclo de razonar y actuar. Y ahora el graph.

Cinco nombres en tres años para cinco capas del mismo problema, y cada uno anunciado como el entierro del anterior. Ninguno ha enterrado a nadie, por cierto: sigues escribiendo prompts dentro de cada nodo de tu grafo precioso. Lo que ocurre es que la industria bautiza como disciplina lo que técnicamente es un patrón de diseño, porque «disciplina» se vende mejor en una charla y cabe mejor en un perfil de LinkedIn.

Por qué sale caro

Volvamos a la arista que iba del revisor al redactor. Cada nodo es una llamada independiente al modelo, y cada llamada arrastra su propio contexto. Como los nodos se solapan —el redactor necesita el mensaje original que ya leyó el clasificador—, ese mismo texto se paga dos veces, o tres. Añade el bucle de revisión: si el revisor rechaza dos veces, has pagado tres redacciones y tres revisiones para una sola respuesta.

El bucle de un solo agente tiene el problema contrario: una conversación larguísima que crece sin parar y que se reenvía entera en cada iteración. Ninguno de los dos es barato, pero el grafo distribuye el gasto en muchas facturas pequeñas y eso lo hace más difícil de ver hasta que llega el recibo. Si lo montas, mide el coste por nodo desde el primer día, y usa caché de contexto donde el proveedor te la ofrezca.

Cuándo compensa

Con todo lo anterior, el patrón es bueno. Cuando la tarea tiene pasos que siempre son los mismos, cuando necesitas poder auditar en qué punto se torció algo, o cuando un agente suelto con veinte herramientas se lía y elige mal, dibujar el grafo te devuelve el control. Cuando la tarea es exploratoria y no sabes de antemano qué pasos harán falta, el bucle abierto sigue ganando.

Mi compañero, después del audio, me contestó que entonces lo que él tenía montado en n8n desde el año pasado ya era graph engineering. Pues sí. Ahora ya sabe cómo llamarlo en la próxima reunión.