La fin du prompt géant unique : débuter avec le Graph Engineering sur ADK 2.0

La vidéo s'ouvre en rappelant pourquoi le Loop Engineering a échoué dans l'épisode précédent : toute tâche confiée à un agent qui boucle sur plan, action et vérification s'effondre dès que l'orchestration devient complexe. L'animatrice Annie fait alors entrer en scène le Graph Engineering et promet de définir l'idée en code qui s'exécute réellement. La question d'exemple est simple : un coureur qui se prépare pour un marathon demande comment courir cette course.

La définition du Graph Engineering est la suivante : le flux de travail du système est organisé sous forme de graphe, dont chaque nœud peut héberger un agent ou une fonction déterministe, tandis que les arêtes reliant les nœuds décident de l'ordre d'exécution. Le modèle et le code classique se retrouvent donc côte à côte dans une même liste, parlant un même langage de câblage. Cette approche refuse de réduire un système d'agents à un seul appel de modèle géant.

Puis la tentative numéro un apparaît à l'écran : un agent unique avec une instruction géante unique qui promet de récupérer la météo, examiner le parcours, évaluer la condition physique de l'athlète et construire une stratégie de course. Le résultat semble si confiant et détaillé qu'il convainc au premier regard. Mais il n'y a ni service météo ni données de parcours derrière ; chaque chiffre à l'écran est inventé. Quand chaque étape vit dans un seul appel de modèle, rien n'est réellement récupéré, rien n'est testé et rien ne peut être cru. La solution n'est pas une meilleure instruction, mais de la structure.

À ce moment, la vidéo énumère quatre couches d'ingénierie : le Prompt Engineering organise ce qu'on dit au modèle, le Context Engineering ce qu'on place autour du modèle, et le Loop Engineering la façon dont l'agent cycle entre plan, action et vérification. Le Graph Engineering est la couche suivante : de nombreuses tâches reliées entre elles, où les nœuds sont les tâches et les arêtes le câblage qui les relie.

Le plus petit graphe se construit avec deux nœuds : une simple fonction Python qui récupère d'abord les conditions du jour de la course, puis un agent qui lit ces conditions et rédige des conseils. La fonction n'utilise aucun modèle et ne coûte rien ; l'agent effectue exactement un appel de modèle. Les arêtes vont du départ à l'étape de récupération, puis à l'étape de conseils, et c'est toute l'orchestration. Le principe reste en mémoire : le travail prévisible va aux fonctions, le raisonnement va au modèle. De vraies données en entrée, de vrais conseils en sortie.

La forme suivante introduit trois concepts, le premier étant le fan-out : puisque les entrées météo, parcours et condition physique ne dépendent pas les unes des autres, pourquoi ne pas les récupérer en parallèle ? Trois arêtes quittent le départ et trois tâches de récupération s'exécutent simultanément. ADK 2.0 propose aussi un fan-out dynamique pour les tâches parallèles dont le nombre est inconnu à l'avance ; le code décide de cette partie du graphe à l'exécution.

Là où les trois branches se rejoignent se trouve le nœud join : il attend la branche la plus lente et rassemble les sorties des branches dans un dictionnaire unique indexé par nom de nœud. Aucun agent de fusion supplémentaire n'a besoin d'être écrit ; le graphe le fait tout seul. Le troisième concept est le router : avec trois agents stratèges spécialisés pour les jours chauds, froids et normaux, un nœud routeur choisit lequel répond. Un routeur basé sur un modèle est flexible mais consomme des jetons et peut se tromper ; un routeur déterministe à règles fixes est bon marché et fiable. La règle est simple : pour une entrée libre sans signal lisible, prenez le routeur à modèle ; pour un ensemble fermé avec le signal présent dans les données, prenez le déterministe. L'exemple de la course utilise le choix déterministe.

L'arithmétique des coûts surprend : trois récupérations parallèles, un join et un agent stratège totalisent toujours un seul appel de modèle, car aucun des nœuds logiques ne touche au modèle. La vidéo admet aussi que le graphe n'est pas une panacée : si le flux peut être dessiné avant l'arrivée de l'entrée, il doit être dessiné comme un graphe ; si la forme du flux dépend de l'entrée, comme dans un scénario de recherche approfondie, elle relève du flux dynamique façonné à l'exécution d'ADK 2.0.