Outils d’un agent IA : montrer ce qui aide vraiment à choisir

Un assistant dispose d'une recherche documentaire, d'un agenda et d'une messagerie. Faut-il lui présenter toutes leurs opérations pour répondre à chaque question ? Les descriptions prennent de la place et certains outils se ressemblent. Une sélection adaptée peut simplifier son travail, mais elle doit aussi lui permettre de trouver une capacité absente de la première liste.

Les descriptions d'outils font partie du contexte

Elle va dans le contexte : le texte que le modèle lit en entier à chaque appel. Un agent est un modèle de langage placé dans une boucle, à qui sont décrits des outils. Ce sont des fonctions qu'il peut demander à exécuter, chacune avec un nom, une description et le schéma de ses paramètres.

Le contexte peut réunir les instructions, l'historique retenu, les résultats des outils et leurs définitions. Selon l'interface, l'application renvoie ces éléments ou le service conserve une partie de la conversation. Dans les deux cas, les informations présentées au modèle occupent du contexte. La facturation dépend aussi du cache et du fournisseur.

Une description transmise pour un outil inutilisé occupe elle aussi de la place. Son coût dépend de sa longueur et de la manière dont elle est réutilisée. Le problème ne se limite pas à la facture : plusieurs actions mal distinguées peuvent aussi compliquer le choix.

Estimer la place occupée par les descriptions

L'étude How Many Tools Should an LLM Agent See?, publiée en 2026, utilise un ordre de grandeur d'environ 200 jetons par outil. Un jeton est une unité de texte traitée par le modèle, parfois un mot, parfois seulement un fragment. La taille réelle dépend de la description et du schéma des paramètres.

Les auteurs en tirent le compte : « une liste de 100 candidats consomme 20 000 jetons avant même que la requête ne soit traitée ». Et des agents branchés sur des milliers d'outils, rapporte Anthropic, « traitent des centaines de milliers de jetons avant de lire une requête ».

Un assistant interne raisonnablement équipé (recherche documentaire, agenda, tickets, messagerie, base clients) atteint vite une quarantaine d'outils en comptant chaque opération à part, soit 8 000 jetons de définitions.

Avec cette hypothèse, quarante outils représentent environ 8 000 jetons. S'ils sont présents dans vingt appels, ils représentent 160 000 jetons d'entrée cumulés. Ce volume ne correspond pas nécessairement à une facturation intégralement au tarif normal : le cache peut en réduire le coût.

Raccourcir une description aide si l'on retire des répétitions. Cela devient contre-productif si l'agent ne sait plus quand utiliser l'outil ou comment renseigner ses paramètres. Une description doit surtout lever les ambiguïtés utiles à la tâche.

Écrire dans quels cas appeler l'outil, et pas seulement ce qu'il fait, me paraît la meilleure dépense de ces deux cents jetons. Le levier reste de toute façon le nombre d'outils montrés, pas la maigreur de chacun.

La capacité maximale ne garantit pas une bonne utilisation du contexte

Rester sous la limite de contexte ne suffit pas à garantir la qualité. Selon le modèle, la tâche et la nature des informations ajoutées, une entrée plus longue peut rendre la recherche des éléments utiles moins fiable.

La fenêtre de contexte, la quantité maximale de texte qu'un modèle accepte, se compte en centaines de milliers de jetons, parfois en millions. Cette taille pousse à la gérer comme un disque : tant que le texte reste sous la limite, tout irait bien.

Anthropic demande de traiter le contexte « comme une ressource finie à rendement marginal décroissant ». La cause tient à l'architecture des modèles : chaque jeton peut être mis en relation avec tous les autres, soit n² relations pour n jetons. La capacité du modèle à les saisir ne grandit pas aussi vite que le texte.

L'étude Context Rot de Chroma a mis cette idée à l'épreuve sur dix-huit modèles de premier plan, dont GPT-4.1, Claude 4, Gemini 2.5 et Qwen3. Leur performance « devient de plus en plus incertaine à mesure que l'entrée s'allonge ».

Le bruit, surtout, n'est pas neutre. Un distracteur, c'est-à-dire un élément du contexte qui n'aide pas à répondre, entre en concurrence avec l'élément utile. Selon la même étude, « un seul distracteur dégrade la performance par rapport à la référence, et en ajouter quatre aggrave encore la dégradation ».

Une erreur de choix ne provoque pas toujours une erreur technique. Le modèle peut répondre normalement avec un résultat moins pertinent. Il faut donc mesurer la réussite de la tâche et la qualité des appels, en complément du coût et de la latence.

Des outils proches demandent des descriptions qui les distinguent

Et ces erreurs coûtent plus cher que les jetons consommés. Selon l'étude de Meta, « chaque candidat supplémentaire coûte des jetons et risque de troubler le modèle ».

L'étude s'appuie sur des travaux antérieurs, LongFuncEval puis Rabinovich et Anaby-Tavor. Ils montrent que « la justesse de l'appel de fonction se dégrade à mesure que les catalogues grossissent ou que des outils sémantiquement proches s'ajoutent ». Vingt outils qui font vingt choses bien distinctes posent donc moins de problèmes que huit outils dont trois se recouvrent en partie.

Anthropic compte un jeu d'outils trop large, ou qui laisse des choix ambigus, parmi les défaillances les plus courantes. Son test est simple : si un ingénieur humain ne peut pas dire avec certitude quel outil employer dans une situation donnée, un agent ne fera pas mieux.

Si l'agent confond deux outils, commencez par expliquer leur différence à partir d'un cas concret. Vous pouvez préciser leur périmètre, renommer une action ou regrouper des capacités qui font doublon. Ajouter des avertissements répétés sans clarifier ce choix risque surtout d'allonger les instructions.

Comparer une liste fixe à une sélection adaptée à la question

La mesure ne soutient pas le slogan « moins d'outils ». L'étude de Meta compare plusieurs façons de choisir les outils montrés, sur des registres de 20 à 3 251 outils.

Une politique adaptative, ici apprise, décide pour chaque requête combien d'outils montrer. La couverture est la part des requêtes pour lesquelles le bon outil figure dans la liste montrée.

Sur ToolBench, la liste fixe de cinq outils gagne en moyenne. Mais elle « ne trouve rien sur les requêtes difficiles », celles où le bon outil est classé entre la sixième et la vingtième place. La politique adaptative en résout 16,7 %. La liste fixe réussit donc les cas faciles, et échoue là où l'agent aurait été le plus utile.

À 370 outils, la politique apprise égale presque une liste de 50 outils en n'en montrant que 7 en moyenne.

Quand un modèle choisit réellement, les listes courtes adaptatives améliorent la sélection : 93,1 % de bons choix contre 87,1 % pour une liste fixe de cinq, et 76,8 % contre 60,9 % sur les requêtes de difficulté moyenne. Deux réserves, que l'étude pose elle-même. Ces chiffres viennent d'une politique réentraînée pour ce protocole, qui montre deux outils en moyenne et non sept. Et la justesse de sélection ne fait pas le résultat : de bout en bout, c'est la liste fixe de cinq qui l'emporte, 73,3 % contre 71,7 %.

Ce qui compte est le nombre d'outils montrés pour une requête donnée, pas la taille du registre. Montrer trois mille outils à chaque tour pose un problème ; n'en montrer que cinq, quelle que soit la question, en pose un autre.

Découvrir les outils utiles au fil du travail

Le registre complet reste hors du contexte, et seuls les outils utiles à la requête y entrent. Vous pouvez chercher dans le registre, router selon la similarité avec la requête, ou présenter les outils comme du code que le modèle lit au besoin.

Anthropic documente cette dernière approche : présenter les outils comme des fichiers « permet aux modèles de lire les définitions à la demande plutôt que de toutes les lire d'emblée ». Sur l'exemple travaillé de son billet, un enchaînement sur des serveurs qu'elle qualifie elle-même d'hypothétiques, le contexte passe « de 150 000 jetons à 2 000 ».

Une autre voie change la nature du catalogue : remplacer une collection d'outils métier par quelques outils génériques, que le modèle combine lui-même. Quelques outils combinables prennent moins de place qu'un catalogue et posent moins de choix ambigus.

Quatre ou cinq verbes génériques (découvrir, lire, agir, chercher) posés sur une API dont les réponses indiquent les liens à suivre remplacent ainsi des dizaines d'outils métier. L'enchaînement de plusieurs opérations passe alors par du code, et non par un outil supplémentaire à déclarer. L'argument est détaillé dans Outiller un agent : du code, pas des outils sur mesure.

La même logique vaut pour les procédures que vous voulez rendre disponibles. Les mettre dans le prompt système, les instructions permanentes du modèle, les fait payer à chaque tour. Les servir à la demande ne les fait entrer dans le contexte que lorsqu'un agent en réclame une.

La découverte à la demande ajoute aussi du travail : rechercher un outil, lire sa description, puis l'appeler. Une liste courte n'est intéressante que si ce parcours conserve une bonne couverture et un coût total acceptable.

Les résultats cités portent sur les modèles et les protocoles évalués en 2025 et 2026. Ils ne donnent pas un nombre universel d'outils à présenter. Pour votre application, comparez quelques stratégies sur des tâches représentatives, en mesurant le résultat final, les erreurs de sélection et le coût de la session.

Sources

• V. Repantis et al. (Meta), How Many Tools Should an LLM Agent See? A Chance-Corrected Answer, 2026.
• K. Hong, A. Troynikov et J. Huber, Context Rot, Chroma, 2025.
• Anthropic, Effective context engineering for AI agents, 2025.
• Anthropic, Writing effective tools for agents, 2025.
• Anthropic, Code execution with MCP, 2025.