Procedural Graphs: saber qué hacer después

Le pides a un agente que consulte el precio de un vuelo. Encuentra la tarifa, tiene la respuesta y podría terminar ahí. Pero sigue. Intenta autenticarse, accede a operaciones de tarjeta y acaba entrando en el proceso de reserva. Ha entendido cómo se usan las herramientas. Lo que ha perdido de vista es para qué las estaba usando.

El ejemplo aparece en el apéndice F de este paper. En esa ejecución, tanto el agente base como el agente guiado encuentran un precio de 220 dólares. El segundo lo comunica y se detiene. El primero continúa hasta hacer una reserva que el usuario no había pedido, y falla la evaluación.

Me parece una buena forma de entrar en el problema porque no exige imaginar una IA incapaz. Al contrario, el agente sabe hacer bastantes cosas. El fallo está en encadenarlas y en reconocer cuándo ya ha hecho suficiente.

Procedural Graphs: Self-Evolving Execution Structures for LLM Agents, publicado el 8 de septiembre de 2026 por Yuxing Lu, Yicheng Chen, Shanchan Wu y Sercan Ö. Arık, propone hacer explícito ese conocimiento sobre cómo proceder. Los cuatro autores tienen afiliación con Google; Lu también con Georgia Tech y la Universidad de Pekín. Su propuesta consiste en guardar los procedimientos en un grafo, consultarlo durante la ejecución y revisarlo a partir de los resultados.

Recordar lo ocurrido no basta

Muchos agentes siguen un bucle de tipo ReAct: razonan sobre la tarea, eligen una acción, observan el resultado y vuelven a decidir. Si buscan en una base de datos, la respuesta se añade al historial. Si llaman a una API, también. El siguiente paso se genera a partir de ese contexto acumulado.

El historial cuenta lo que ha pasado, pero el modelo tiene que reconstruir qué significa para lo que viene después. ¿Falta comprobar algo? ¿Esta operación depende de otra? ¿Tiene sentido repetir la consulta? Cuanto más se alarga la tarea, más cosas hay que mantener presentes a la vez.

Una memoria de experiencias ayuda. Puedes guardar que «la última vez solicitamos financiación demasiado tarde» y recuperar esa lección en otra ejecución. Aun así, queda trabajo por hacer: relacionar esa advertencia con el estado actual y decidir en qué momento debe cambiar la conducta del agente.

Un flujo de trabajo fijo resuelve parte de esto al definir los pasos de antemano. El problema aparece cuando la situación no encaja bien en el recorrido previsto. Procedural Graphs busca un punto intermedio: representar el orden y las condiciones de los procedimientos, dejando al modelo margen para decidir.

Un grafo de lo que conviene hacer

Un grafo es, en lo esencial, un conjunto de nodos unidos por relaciones. En un grafo de conocimiento podrías guardar «Madrid —es capital de→ España». Aquí los nodos representan procedimientos: una llamada a una herramienta, una habilidad, un paso de razonamiento o un estado de la tarea. Las relaciones describen las transiciones entre ellos.

El paper formaliza cada conexión como una tripleta (procedimiento, relación, procedimiento). Además de señalar un posible paso siguiente, cada conexión incorpora tres campos de texto: condition, cuándo se aplica; guidance, cómo proceder; y pitfalls, qué errores evitar.

La conexión contiene algo más útil que «recuerda vigilar el dinero». Relaciona una comprobación con una decisión, dice bajo qué circunstancia tiene sentido tomarla y recoge una precaución concreta. Al conectar varias de estas piezas se obtiene una estructura de procedimiento que puede inspeccionarse y editarse.

Todo esto vive fuera de los pesos del LLM. Cambiar el grafo no implica volver a entrenar la red neuronal. Se modifica el conocimiento externo que se utiliza para orientarla, de una forma parecida a revisar un manual de operaciones después de detectar un fallo.

Cómo llega esa estructura al agente

Tener el grafo guardado no basta. Hay que convertirlo en algo útil justo cuando el agente va a actuar. Los autores lo hacen en tres pasos: localizar, extraer y generar.

1. Localizar. El sistema busca una coincidencia exacta entre el procedimiento más reciente del agente y un nodo del grafo. La primera decisión parte de un nodo Start.
2. Extraer. Desde ese nodo recupera las transiciones salientes hasta dos saltos de distancia. Es decir, ve posibles pasos siguientes y las continuaciones de esos pasos. Si no encuentra una coincidencia, utiliza el grafo completo.
3. Generar. Un LLM recibe ese fragmento conectado, la petición del usuario y una ventana con los tres últimos pasos de la trayectoria. Con ello redacta una guía específica para la siguiente decisión.

Esa guía se añade al prompt del solver, el agente que resuelve la tarea y selecciona la acción. El solver sigue recibiendo la petición y su trayectoria completa; la ventana de tres pasos corresponde al modelo que prepara la guía. Son dos funciones distintas, aunque en los experimentos utilizan el mismo LLM base. También lo usa el componente que revisa el grafo.

¿Por qué recuperar un fragmento conectado en vez de unas cuantas reglas parecidas a la consulta? Porque las conexiones conservan la continuidad del procedimiento. Una recomendación sobre una acción, aislada de lo que debe ocurrir antes o después, puede resultar incompleta. Aquí el modelo lee las instrucciones junto con las transiciones que las relacionan.

Hay un detalle importante: el grafo orienta la elección, pero no bloquea por código las acciones que se salen de él. La integración es mediante texto en el prompt. Eso preserva flexibilidad, aunque también significa que el agente puede equivocarse o no seguir la recomendación. No es una garantía de ejecución correcta.

La parte que evoluciona

Hasta aquí podríamos tener un manual bastante elaborado, pero escrito a mano. La segunda mitad de la propuesta consiste en revisarlo automáticamente a partir de la experiencia.

Durante una tarea el grafo permanece fijo. Los cambios se proponen entre tandas de tareas de entrenamiento, en un bucle separado de la ejecución. Algunas tablas lo llaman online evolution, pero el apéndice D.2 aclara que se refiere a actualizaciones incrementales entre tandas: el grafo tampoco cambia durante la evaluación de test.

Primero se ejecutan tareas con el grafo actual y se guardan las acciones, las observaciones y las puntuaciones. Después, un LLM que actúa como refiner compara las trayectorias con mejores y peores resultados. Busca errores repetidos, comprobaciones ausentes o secuencias que hayan funcionado bien, y propone modificaciones.

Puede añadir o eliminar nodos y conexiones. También puede revisar sus instrucciones; en la implementación, cambiar los atributos de una conexión se expresa eliminándola y añadiéndola con el texto nuevo. Evolucionar no tiene por qué hacer el grafo más grande. A veces la mejora consiste en quitar un camino que distraía al agente.

La propuesta se aplica a una copia. Si supera las comprobaciones estructurales, se evalúa en un conjunto de validación separado de las tareas usadas para diagnosticar los fallos. La regla de aceptación es sencilla: conservar el candidato si su puntuación media de validación iguala o supera la del grafo retenido. Si empeora, se mantiene el anterior.

Además, las propuestas rechazadas por esa evaluación se guardan con sus cambios y resultados. Esa memoria de rechazos se entrega al refiner en rondas posteriores para disuadirlo de repetir modificaciones que ya salieron mal. No las vuelve imposibles; le da evidencia de por qué conviene buscar otra solución.

El punto de partida puede ser un grafo diseñado por humanos o algo tan pequeño como Start → End. Partir «desde cero» se refiere a esa estructura inicial: el sistema sigue contando con un LLM preentrenado, herramientas y tareas evaluables. Lo que aprende a construir es el procedimiento externo.

Qué dicen los resultados

La tabla principal compara el método con siete alternativas, desde ReAct sin memoria hasta sistemas que recuperan experiencias, reglas o flujos de trabajo. Comparten el mismo solver ReAct y las alternativas que aprenden reciben las mismas trayectorias de entrenamiento. Se prueban cuatro modelos: Claude Sonnet 4.6, Gemini 3.1 Pro, Gemini 3.5 Flash y Grok 4.1 Fast.

Las seis evaluaciones de esa tabla cubren preguntas que exigen combinar búsquedas, seguimiento de instrucciones en conversaciones, tareas profesionales, acciones domésticas simuladas y uso de herramientas. De las 24 combinaciones de modelo y benchmark, PG queda primero o empatado en 21: son 19 victorias, dos empates y tres derrotas frente a la mejor alternativa de cada caso.

BFCL mide la corrección de llamadas a funciones; τ-bench, el éxito al usar herramientas siguiendo políticas durante una interacción; GDPval puntúa trabajos profesionales mediante rúbricas; HotpotQA evalúa respuestas que combinan información de varias fuentes. Sus números no son intercambiables. En BFCL la mejora mostrada es de nueve puntos porcentuales, mientras que en GDPval son 7,41 puntos de su escala de evaluación.

He incluido una derrota porque también cuenta. La ventaja no es igual en todas partes, y la tabla original presenta intervalos de confianza que en muchos casos se solapan. El balance general es favorable; cada diferencia pequeña no debe leerse como una victoria concluyente por separado.

Cuando el manual está equivocado

Para mí, uno de los experimentos más interesantes es el que sale mal al principio. En el estudio de construcción de grafos sobre MultiChallenge, el agente sin guía alcanza un 87,50 % de éxito. Añadir el grafo escrito por expertos lo baja al 58,93 %. Una única actualización automática lo deja todavía peor: 53,57 %.

El grafo estaba orientando mal la tarea. El apéndice muestra un caso en el que el agente debía contestar al usuario respetando instrucciones previas, pero acababa evaluando si la conversación cumplía esas instrucciones. Su procedimiento le llevaba a responder a la pregunta de evaluación en lugar de atender la petición.

Con revisiones sucesivas y validación entre rondas, la configuración que parte de ese grafo llega al 92,86 % de éxito en test. La que evoluciona desde una estructura mínima alcanza el 91,07 %. Son resultados del experimento específico de construcción, con Gemini 3.5 Flash y 56 ejemplos de test, no de la tabla principal anterior.

La lectura que me interesa es bastante práctica: una instrucción bien redactada puede seguir siendo una mala instrucción. Si la estructura que guía al agente también puede ponerse a prueba y corregirse, deja de depender por completo de que acertemos al diseñarla. Este experimento muestra que es posible reparar un punto de partida defectuoso, no que cualquier grafo vaya a arreglarse solo.

Decidir a tiempo, no solo decidir bien

El séptimo entorno es EnterpriseArena, un simulador de gestión financiera. El agente toma decisiones mensuales durante un máximo de 132 meses y se enfrenta a tres crisis cuyo calendario desconoce. La restricción decisiva es que el dinero solicitado tarda entre uno y seis meses en llegar.

Esto cambia el significado de una buena decisión. Pedir financiación cuando la caja ya está vacía puede ser razonable como reacción, pero inútil para sobrevivir. Hace falta relacionar el estado actual, la previsión de liquidez y el retraso de la financiación. Es precisamente el tipo de dependencia temporal que el ejemplo de grafo anterior intenta representar.

En el estudio de diez rondas de evolución con Gemini 3.5 Flash, el grafo finalmente devuelto alcanza un 85 % de supervivencia en test, frente al 0 % del agente sin guía en ese experimento. Durante la búsqueda hubo un grafo intermedio que marcó un 95 %, pero los autores no lo presentan como resultado final: escogerlo por su puntuación de test sería usar el examen para elegir la solución.

Es una mejora grande, con una escala que conviene tener presente: hay 20 episodios por partición en este estudio de evolución. Un solo episodio cambia cinco puntos porcentuales. El resultado pertenece a ese simulador y a esa configuración; no equivale a demostrar una capacidad general para dirigir empresas.

Una guía útil también tiene coste

Generar una recomendación en cada paso añade llamadas al modelo. Aunque el agente necesite menos acciones para completar una tarea, el sistema puede consumir más tokens en total. El paper mide ambas cosas, y la diferencia importa.

En la evaluación de eficiencia con Gemini 3.5 Flash, la guía local reduce los pasos medios del solver de 28,20 a 18,57 en GDPval, y de 21,84 a 18,80 en ALFWorld. Sin embargo, el consumo total de tokens sube un 33,4 % y un 55,4 %, respectivamente, frente al agente sin grafo.

Recuperar solo el vecindario del nodo ahorra tokens respecto a generar la guía con el grafo completo. Pero ese ahorro es contra otra configuración de PG, no contra el agente base. Además queda el coste de las ejecuciones de entrenamiento, las propuestas de edición y su validación.

La validación tampoco convierte la evolución en una mejora garantizada. Se acepta una puntuación observada, con variabilidad del entorno y de la ejecución. Igualar o superar esa cifra no demuestra que el candidato sea mejor en cualquier tarea futura. Los propios autores señalan que algunas decisiones de aceptación o rechazo dependen de uno o dos episodios.

Queda también por estudiar hasta qué punto un procedimiento aprendido se conserva al cambiar de modelo o de interfaz de herramientas. Es una pregunta relevante si queremos reutilizar estos grafos fuera de la configuración en la que se construyeron; el trabajo la deja como una línea futura.

Lo que me llevo del paper

En la entrada sobre Hyperagents hablábamos de sistemas que modifican código para mejorar. Aquí la pieza editable es más concreta: el grafo de procedimientos que acompaña al agente. Eso permite examinar qué se ha añadido, qué transición se ha quitado y qué advertencia ha cambiado, aunque explicar exactamente cuánto aporta cada edición siga requiriendo experimentos.

Me interesa esa posibilidad porque muchos fallos de un agente están a la vista. Repite una consulta que no aporta nada. Omite una comprobación. Sigue actuando cuando ya ha respondido. Podemos reconocerlos en una traza, pero convertir esa observación en un comportamiento mejor sigue siendo un trabajo bastante manual.

Procedural Graphs ofrece una forma de cerrar parte de ese recorrido: observar las ejecuciones, proponer cambios en una estructura explícita y comprobar si ayudan en otras tareas. Los resultados son prometedores, incluso cuando la estructura inicial estorba. Y también dejan claro que añadir instrucciones, por sí solo, no es suficiente. Hay que acertar con cuáles, con cómo se conectan y con cuándo se presentan.

Los avances más importantes son los que permanecen latentes, tan asumidos como inevitables que nadie los cuestiona.

De eso va este blog.