La boucle agentique est l’architecture fondamentale qui décrit le fonctionnement des agents IA.
Elle peut être programmée en une dizaine de lignes de code et paraît très simple. Pourtant, on peut encore améliorer son fonctionnement et surtout réduire son coût d’exécution grâce à un pattern de programmation agentique : le “dynamic direct return” (DDR).
Illustration du pattern “dynamic direct return” pour la boucle agentique (schéma repris de la documentation de LangChain), décrit en détail dans cet article
Une limite de la boucle agentique : l’appel LLM final est souvent inutile
La boucle agentique fonctionne ainsi :
- On fournit un prompt à une IA générative LLM avec un objectif à atteindre ;
- On lui fournit aussi des outils pour arriver à son but ;
- L’IA utilise les outils en boucle, jusqu’à avoir résolu le problème initial.
Quand l’IA appelle un outil, elle obtient un résultat, qu’elle interprète pour tirer une conclusion : soit le problème n’est pas résolu et il faut appeler un outil supplémentaire, soit le problème est résolu et une réponse finale est générée par le LLM.
En pratique, le dernier appel au LLM est en fait souvent inutile, voire contre-productif !
Il va générer un coût (tokens d’entrée pour lire le résultat de l’outil ; tokens de sortie pour générer une conclusion) et peut créer des hallucinations (l’IA répète parfois incorrectement le résultat de l’outil).
Exemple de l’ouverture de fichier
Par exemple, on peut demander à l’IA d’ouvrir un fichier et afficher son contenu, une tâche a priori extrêmement simple. L’intérêt d’utiliser un agent IA est qu’il peut chercher lui-même l’emplacement du fichier.
Un agent IA de type boucle agentique va :
- Chercher puis ouvrir le fichier via un outil ;
- Le lire entièrement via son LLM (étape inutile et coûteuse) ;
- Le répéter avec des ajouts (étape inutile, coûteuse et pouvant en plus générer une hallucination !).
Dans cet exemple, on demande pourtant simplement à l’IA d’appeler des outils pour accéder au fichier et l’afficher. Mais elle va aussi lire et réciter son contenu, ce qui fait augmenter notre facture en tokens d’entrée/sortie. Les plus attentifs remarqueront aussi le risque légèrement accru d’injection de prompt.
Démonstration avec Claude Code : le fichier contient le texte “Bonjour Éric !”, mais Claude code va ajouter un préambule long et inutile à la réponse finale. Le contenu du fichier est répété par l’IA, ce qui induit un risque d’hallucination et d’altération du contenu, surtout pour un long fichier.
Ce dernier appel LLM systématique est un reliquat de l’architecture ReAct, qui a été conçue dans une optique générative, pour produire des réponses textuelles de qualité (une forme de RAG), et non dans une optique agentique, où l’objectif est que l’agent IA réalise une action donnée sans forcément produire du texte en sortie.
Solutions palliatives : outils dédiés, architecture spécifique…
Créer un outil spécifique pour afficher un fichier peut éliminer le risque d’hallucination (le fichier n’est pas “répété” par le LLM dans ce cas, il est ouvert directement), mais ne suffit pas, car l’agent va tout de même ajouter une conclusion du type “Le fichier a bien été ouvert” et coûter quelques tokens de sortie additionnels.
Un développeur informatique peut bien sûr concevoir un agent sur mesure pour contourner ce problème, par exemple avec LangGraph. Mais cela n’est pas très efficace, car il faut imaginer et implémenter un nouvel agent pour chaque tâche spécifique, alors que ce qui fait la force de la boucle agentique est sa polyvalence.
Le pattern “dynamic direct return” résout ce problème tout en restant compatible avec le principe de la boucle agentique.
L’option “return_direct” de LangChain : une première amélioration mais qui reste trop rigide
L’option “return_direct” des outils LangChain permet d’interrompre la boucle agentique quand le résultat d’un outil doit être considéré comme final et n’a pas vocation à être partagé avec l’IA pour produire un dernier message.
Elle permet donc d’éliminer l’appel LLM inutile pour certains outils, par exemple ceux destinés à afficher un contenu auprès de l’utilisateur.
Sa limite est que cette option est statique, c’est-à-dire qu’un outil en mode “return_direct” provoque toujours une interruption, au lieu de laisser l’agent décider en fonction du contexte.
Pour reprendre l’exemple de l’ouverture de fichier, plusieurs situations sont possibles :
- Si je veux simplement voir le contenu du fichier, l’appel d’outil “open_file” doit provoquer une interruption de la boucle agentique et afficher le résultat.
- Si je veux par contre obtenir un résumé IA du contenu du fichier, il faut laisser le LLM lire le contenu et proposer une synthèse, et il ne faut donc pas provoquer d’interruption de la boucle agentique.
Il est donc nécessaire d’imaginer une version dynamique de ce “retour direct”, qui laisse le choix à l’IA de l’activer ou non.
Dynamic direct return : un pattern pour optimiser la boucle agentique
Le “dynamic direct return” est donc un nouveau pattern de développement agentique qui consiste à donner la possibilité à la boucle agentique de s’arrêter d’elle-même après un appel d’outil, sur décision du LLM.
En résumé, l’agent IA peut décider d’afficher un résultat d’outil directement, sans générer de message final avec le LLM.
À la clé, une réduction de la consommation de tokens et l’élimination du risque d’hallucination découlant du dernier appel LLM inutile.
J’ai proposé une implémentation de ce mécanisme sous forme de middleware LangChain, et soumis une feature request pour le projet Goose pour implémenter le dynamic direct return au sein de cet agent IA open source et polyvalent.
L’implémentation s’appuie sur un outil spécial qui déclenche l’arrêt de la boucle agentique lorsque le LLM l’utilise en parallèle d’un autre outil.
Par exemple, si le LLM appelle la liste d’outils [open_file(test.txt), return_direct()], le “dynamic direct return” se déclenche et affiche le résultat de la fonction “open_file”, c’est-à-dire le contenu du fichier test.txt, sans passer par le LLM.
On peut ainsi laisser l’IA décider si le dernier appel LLM est utile ou non selon le contexte : l’objectif visé est atteint !
L’implémentation du DDR est en théorie possible dans tous les frameworks agentiques qui permettent de contrôler (et stopper) la boucle agentique via des systèmes de “hooks”, comme cela est le cas pour LangChain.
Quand faut-il éviter le dynamic direct return ?
Une limite de ce pattern agentique est que le coût en tokens de l’ajout d’un outil peut dans certaines situations dépasser le gain obtenu, par exemple si cet outil est peu utilisé par l’agent.
Aussi, les LLM actuels, y compris les modèles agentiques comme Mistral Small par exemple, ne sont pas entraînés pour gérer les appels d’outils de contrôle d’une boucle agentique, ce pattern étant encore très peu courant. Une évaluation sur un banc d’essai réaliste serait nécessaire pour conclure avec des statistiques chiffrées.
Aller plus loin avec le DDR
D’autres variantes du “dynamic direct return” restent à imaginer. Des idées possibles sont l’introduction d’une forme de composition d’outils, l’utilisation d’un sous-agents avec une légère décidant de l’arrêt de la boucle agentique principale, etc.
Au-delà de ce pattern spécifique, le plus important pour un développeur IA agentique est de toujours rester conscient des étapes qui engendrent un appel à l’IA dans un système agentique, et de s’efforcer d’éliminer les inférences inutiles qui sont sources de surcoûts et de risque d’hallucination.
