El agente llevaba cuarenta minutos trabajando solo. Había leído la documentación interna, había abierto media docena de ficheros, había redactado un borrador, se había arrepentido a mitad de camino y había vuelto a empezar. En la pantalla, la traza crecía sin parar. Cuando por fin devolvió un resultado aceptable, el responsable técnico que lo vigilaba se quedó con una pregunta incómoda: ¿en qué punto exacto se había torcido? La respuesta estaba enterrada en varios miles de líneas de registro, y nadie tenía la tarde libre para ir a buscarla.
Esa escena se repite en muchas empresas que llevan un año probando agentes, y es el origen práctico de una discusión que ha llegado hasta los comités de dirección con nombre nuevo: graph engineering. Conviene separar el nombre de la cosa antes de decidir si su equipo tiene que aprendérselo esta semana.
Qué se está proponiendo en realidad
El modelo habitual hasta ahora es el bucle: un único agente recibe un objetivo, dispone de un conjunto de herramientas y da vueltas —pensar, actuar, observar— hasta que considera que ha terminado. Funciona sorprendentemente bien para tareas cortas y se rompe con elegancia dudosa en cuanto la tarea se alarga: el contexto se llena de basura acumulada, el agente pierde el hilo de lo que ya había decidido y el registro se vuelve ilegible para un humano.
La alternativa que se está popularizando consiste en dejar de tratar el proceso como una conversación larga y modelarlo como una máquina de estados. Cada nodo es un agente con un encargo estrecho y sus propias instrucciones. Cada arista define qué información concreta viaja de un nodo al siguiente. El sistema avanza por transiciones explícitas, con condiciones, bifurcaciones y puntos de vuelta atrás que están escritos en algún sitio y no dependen del criterio del modelo en ese instante.
Un ejemplo reconocible: una redacción. Alguien propone temas y los prioriza. Otra persona escribe. Una tercera edita, recorta y verifica. Una cuarta publica y mide. Nadie propondría fundir esos cuatro papeles en una sola persona que va y viene hasta que el artículo esté bien; y sin embargo, eso es exactamente lo que hacemos cuando le pedimos a un agente único que se ocupe del proceso entero.
El nombre es nuevo; el patrón tiene décadas
Aquí es donde recomendamos bajar el volumen del entusiasmo. Las máquinas de estados finitos son un formalismo de mediados del siglo pasado y están en la base de compiladores, protocolos de red y sistemas de control industrial. Orquestar tareas encadenando pasos con condiciones es lo que llevan años haciendo herramientas de automatización como Make o n8n, con la diferencia de que ahora algunos nodos llaman a un modelo de lenguaje. Y en el terreno específico de los agentes, LangGraph plantea desde hace tiempo justo esto: grafos con estado, nodos, aristas y persistencia entre pasos.
Lo verdaderamente nuevo es la etiqueta, que se ha extendido a partir de un mensaje afortunado en redes y ha corrido más rápido que la idea. Para un directivo esto tiene una consecuencia práctica: si su proveedor le presenta el graph engineering como una tecnología emergente que exige contratar perfiles nuevos, está vendiendo un envoltorio. Si se lo presenta como una forma de diseñar procesos que ya conocía con otro nombre, va bien encaminado.
Lo que se gana de verdad
- Trazabilidad. Se puede ver qué agente hizo qué, con qué información de entrada y qué devolvió. Cuando el resultado sale mal, la pregunta «¿dónde falló?» tiene una respuesta señalable en lugar de una expedición arqueológica por el registro.
- Especialización por etapa. Cada nodo recibe solo el contexto que necesita y unas instrucciones cortas. Un agente al que se le pide una única cosa la hace mejor que un agente al que se le piden ocho, y además permite ajustar modelo, coste y nivel de razonamiento etapa por etapa: lo mecánico con un modelo barato, la revisión crítica con uno caro.
- Reanudación. Si el proceso se cae en el paso siete, se retoma desde el siete. En un bucle largo, un fallo tardío obliga a repetirlo todo, con lo que eso significa en tiempo y en factura.
- Puntos de control humanos. Un grafo hace natural lo que en un bucle es un parche: parar antes de publicar, antes de enviar, antes de tocar producción, y esperar a que alguien apruebe.
Lo que cuesta
El consumo de tokens sube, y no poco. Cada nodo vuelve a recibir su contexto, cada transición añade una llamada más y el trabajo intermedio que un agente único resolvía sin salir de su memoria de trabajo pasa a viajar de un lado a otro escrito de forma explícita. A esto se suma la latencia: un proceso de siete etapas tarda más en cerrar que uno que improvisa. Quien ya haya echado la cuenta del coste real de un caso de uso sabe que estas multiplicaciones no son detalles.
El coste mayor, sin embargo, es de mantenimiento. Un grafo es una pieza de ingeniería con su diseño, su gestión de estado, sus reintentos y sus pruebas. Tiene dueño o se pudre. Para un proceso de tres pasos que un agente resuelve razonablemente bien, montar toda esa maquinaria multiplica la superficie de fallo sin mejorar el resultado.
El criterio para decidir
Nuestra regla es sencilla y no requiere entrar en el debate terminológico: si el proceso no está ya dividido en etapas con un responsable distinto en cada una, modelarlo como grafo es sobreingeniería. Los procesos que piden esta forma son los que ya la tienen en la organización: una redacción, un circuito de alta de proveedores, una revisión de contratos con validación legal, un ciclo de soporte con escalado. En todos ellos hay entregas entre manos, criterios de aceptación por etapa y un punto en el que alguien firma.
Para el resto, la recomendación es esperar. Dejar que el equipo trabaje con un agente único hasta encontrarse con el límite —el momento en que nadie sabe explicar por qué salió mal— y usar ese límite como disparador. Cuando llegue, el diseño del grafo saldrá casi solo del proceso que ya existía en la empresa, y la conversación con el proveedor será mucho más barata.