Pourquoi chaque agent IA a besoin d'une pile, une architecture formelle pour maîtriser l'explosion des outils

Chaque agent IA rencontre le même problème de conception. Donnez-lui trop d'outils, et le modèle ne peut pas décider lequel utiliser. Donnez-lui trop peu, et les tâches complexes restent hors de portée. Un article de recherche de l'équipe derrière UPI Help, un produit d'assistance aux paiements numériques alimenté par l'IA, propose une solution basée sur une idée ancienne : l'automate à pile.

L'article, A Formal Hierarchical Architecture for Agentic Orchestration with Stack-Based Execution and Lazy Discovery, organise les capacités de l'agent sous forme d'un arbre enraciné. Les nœuds internes prennent des décisions de routage. Les nœuds feuilles exécutent des tâches déterministes. Une pile LIFO (Last-In-First-Out) gouverne la boucle d'exécution en une seule étape, donnant à l'agent une mémoire comme un automate à pile. Cela lui permet de gérer l'exécution imbriquée et de revenir proprement de n'importe quelle profondeur.

Le goulot d'étranglement que la hiérarchie résout

Les frameworks actuels d'agents LLM chargent généralement chaque outil disponible dans un registre plat. Lorsque le registre atteint des centaines ou des milliers d'API, le modèle doit toutes les évaluer à chaque étape de raisonnement. L'article appelle cela 'l'explosion de l'espace de décision'. Les fenêtres de contexte se saturent. La précision du routage chute. La latence augmente. Avec 256 outils et des schémas de 800 caractères, le routage plat dépasse les limites de contexte et obtient un taux de succès de 0 % dans les benchmarks de l'article.

L'alternative hiérarchique organise les capacités en un arbre de compétences. Lorsque l'agent entre dans un nœud de prise de décision, il charge uniquement les métadonnées des enfants immédiats via des manifestes JSON localisés. Ce protocole de découverte paresseuse signifie que la mémoire et les coûts de prompt s'adaptent au chemin exploré, et non au registre global. Avec 512 outils, le système hiérarchique utilise 2 875 jetons d'entrée par tâche et maintient un succès de routage de 100 %. La ligne de base plate atteint les limites de contexte à 256 outils avec près de 50 000 jetons.

Contrôle basé sur la pile pour les workflows imbriqués

La principale contribution architecturale de l'article est le remplacement de l'orchestration non structurée basée sur la conversation par une discipline de pile formelle. Chaque fois qu'un nœud de décision appelle une compétence enfant, le runtime pousse un cadre de contexte sur la pile. Lorsque l'enfant se termine, sa sortie est ajoutée uniquement à l'accumulateur localisé du parent. Ensuite, le cadre est dépilé et le contrôle revient au parent.

Cette structure empêche que les sorties d'une branche d'exécution ne débordent dans une autre. Cela est important pour les environnements réglementés en entreprise comme le support de paiement. 'Les cadres de mémoire localisés fournissent des garanties d'isolement structurellement indisponibles dans les systèmes à registre plat ou multi-agents conversationnels', écrivent les auteurs. 'Les sorties non fiables peuvent être contraintes à un traitement au niveau des feuilles.'

L'invariant de pile est mathématiquement formalisé : lorsqu'un appel de compétence en attente cible un nœud non racine, le sommet de la pile doit correspondre au parent de ce nœud. Le runtime, et non le LLM, gère le flux d'exécution, ce qui réduit les risques d'erreurs de navigation lors des traversées profondes.

Ce que les benchmarks révèlent

L'évaluation compare le routage plat et hiérarchique dans plusieurs scénarios, en gardant le LLM constant. Principales conclusions :

• Adaptabilité du prompt : Avec N=128 outils (schémas de 800 caractères), le routage hiérarchique utilise environ 1 733 jetons d'entrée par tâche contre environ 28 178 pour le plat, soit une réduction de 16x. Les jetons de schéma par appel passent de 17 791 à 277.
• Pression du workflow : Avec un historique de chat bruyant et des tâches en deux étapes, la hiérarchie maintient environ 0,73 de succès de tâche avec 5,3k caractères de prompt à N=128, contre 140k pour le plat. Les taux de mauvaise action et de mauvais choix sont proches de zéro pour le système hiérarchique.
• Routage agentique : À N=128 (schémas de 400 caractères), la hiérarchie atteint 0,70 de succès de tâche avec 3,6k caractères de prompt ; le plat utilise 87k. Les taux de mauvais argument sont de 0,05 par décision contre 0,40 pour le plat.

Le compromis : le routage hiérarchique utilise plus d'appels LLM séquentiels, environ 10 par tâche contre 2 pour le plat à N=128, mais maintient des jetons d'entrée totaux plus bas. L'article note que 'les prompts hiérarchiques restent d'un ordre de grandeur plus petits' même lorsque les deux architectures convergent vers des taux de succès de tâche similaires.

De la théorie aux paiements

L'architecture a été construite pour UPI Help, un produit d'assistance IA traitant les requêtes de transaction, la résolution de réclamations et la gestion des mandats pour l'interface de paiement unifiée de l'Inde. L'orchestration hiérarchique permet à l'orchestrateur racine de d'abord sélectionner un domaine (comme 'opérations de mandat'), puis d'exposer uniquement les sous-compétences de ce domaine pour le routage ultérieur.

L'article rapporte un succès de routage de 100 % sur les familles de requêtes de mandat et de paiement où l'arbre de compétences est entièrement peuplé, avec une latence par requête inférieure à celle d'une ligne de base terminale plate. Des contrôles de sécurité, y compris le cloisonnement des capacités, les cadres d'exécution localisés et les métadonnées de gouvernance au niveau du manifeste, maintiennent le système aligné sur les exigences des environnements de support de paiement de haute confiance.

Le tableau d'ensemble

L'article se place dans une lignée qui comprend Toolformer, Voyager, AutoGen et MemGPT. Ce qui distingue cette approche, c'est sa dette formelle envers la théorie des automates. La boucle de contrôle basée sur la pile fait passer l'agent d'une machine à états finis à un automate à pile, lui donnant une mémoire hors-contexte pour les workflows imbriqués.

Pour les équipes construisant des systèmes d'agents de production, l'architecture offre un chemin d'adaptation déclaratif. De nouvelles capacités peuvent être ajoutées en tant que compétences sœurs (adaptation horizontale) ou sous-orchestrateurs plus profonds (adaptation verticale) en ajoutant des entrées JSON au manifeste d'un parent, sans aucune modification de la boucle de routage centrale. Le contexte de production de l'article dans les paiements numériques montre également que ces modèles fonctionnent sous des contraintes réelles : auditabilité, limites de capacités et exécution contrôlée des flux sensibles.

L'article complet est disponible sur arXiv. À mesure que les systèmes agentiques passent des démos aux déploiements de production, les approches formelles de l'orchestration pourraient devenir aussi essentielles que les modèles eux-mêmes.