El fin del prompt gigante único: primeros pasos con Graph Engineering en ADK 2.0

El video abre recordando por qué el Loop Engineering se estancó en el episodio anterior: cualquier trabajo dejado a un agente que itera entre planificar, actuar y verificar se derrumba en cuanto la orquestación se vuelve compleja. La presentadora Annie saca entonces a escena el Graph Engineering y promete definir la idea en código que realmente se ejecuta. La pregunta de ejemplo es simple: un corredor que se prepara para un maratón pregunta cómo correr esa carrera.

La definición de Graph Engineering es esta: el flujo de trabajo del sistema se configura como un grafo, en el que cada nodo puede albergar un agente o una función determinista, mientras que las aristas que conectan los nodos deciden el orden de ejecución. El modelo y el código clásico quedan así lado a lado en una misma lista, hablando un mismo lenguaje de cableado. Esta visión se niega a reducir un sistema de agentes a una única llamada de modelo gigante.

Luego aparece en pantalla el intento número uno: un agente único con una única instrucción gigante que promete obtener el clima, revisar el recorrido, evaluar la condición física del atleta y construir una estrategia de carrera. El resultado parece tan seguro y detallado que convence a primera vista. Pero no hay ningún servicio meteorológico ni datos del recorrido detrás; cada cifra en pantalla está inventada. Cuando cada paso vive dentro de una sola llamada al modelo, nada se obtiene realmente, nada se prueba y nada se puede creer. La solución no es una mejor instrucción, sino estructura.

En este punto el video enumera cuatro capas de ingeniería: el Prompt Engineering organiza qué decirle al modelo, el Context Engineering qué colocar alrededor del modelo, y el Loop Engineering cómo el agente cicla entre planificar, actuar y verificar. Graph Engineering es la siguiente capa: muchas piezas de trabajo conectadas entre sí, donde los nodos son las piezas y las aristas el cableado entre ellas.

El grafo más pequeño se construye con dos nodos: una función simple de Python que primero obtiene las condiciones del día de la carrera, y luego un agente que lee esas condiciones y escribe consejos. La función no usa ningún modelo y no cuesta nada; el agente hace exactamente una llamada al modelo. Las aristas van del inicio al paso de obtención y de ahí al paso de consejos, y esa es toda la orquestación. El principio se queda grabado: el trabajo predecible va a las funciones, el razonamiento va al modelo. Datos reales de entrada, consejos reales de salida.

La siguiente forma introduce tres conceptos, el primero siendo el fan-out: como las entradas de clima, recorrido y condición física no dependen entre sí, ¿por qué no obtenerlas en paralelo? Tres aristas salen del inicio y tres trabajos de obtención se ejecutan a la vez. ADK 2.0 también ofrece fan-out dinámico para trabajos paralelos cuyo número se desconoce de antemano; el código decide esa parte del grafo en tiempo de ejecución.

Donde las tres ramas se encuentran está el nodo join: espera a la rama más lenta y reúne las salidas de las ramas en un único diccionario indexado por nombre de nodo. No hay que escribir ningún agente de fusión adicional; el grafo lo hace por sí solo. El tercer concepto es el router: con tres agentes estrategas especializados para días calurosos, fríos y normales, un nodo router elige cuál responde. Un router basado en modelo es flexible pero gasta tokens y puede equivocarse; un router determinista de reglas fijas es barato y confiable. La regla es simple: para entradas de formato libre sin señal legible, usa el router de modelo; para un conjunto cerrado con la señal presente en los datos, usa el determinista. El ejemplo de la carrera usa la opción determinista.

La aritmética de costos sorprende: tres obtenciones en paralelo, un join y un agente estratega siguen sumando una sola llamada al modelo, porque ninguno de los nodos de lógica toca el modelo. El video también admite que el grafo no es una cura universal: si el flujo puede dibujarse antes de que llegue la entrada, debe dibujarse como un grafo; si la forma del flujo depende de la entrada, como en un escenario de investigación profunda, pertenece al flujo dinámico moldeado en tiempo de ejecución de ADK 2.0.