Combien d’outils par agent

Lorsque vous donnez à un agent un ensemble d'tools, le modèle doit effectuer une tâche subtile à chaque tour : lire toutes les descriptions des outils et choisir celui qui convient à l'étape en cours.

Il s'agit d'une tâche de sélection. Plus vous ajoutez d'options, plus ce choix devient difficile. Un ensemble d'outils ciblé permet une sélection précise ; un ensemble surchargé fait hésiter le modèle, l'amène à faire un mauvais aiguillage ou à prendre le mauvais outil.

Cette leçon répond à une question en apparence simple : combien d'outils un agent doit-il avoir ?

Le juste équilibre pratique est de 4 à 5 outils par agent. Avec ce nombre, le modèle peut déterminer de manière fiable quel outil convient à chaque étape.

À mesure que le nombre augmente, la fiabilité de la sélection diminue. À partir d'environ 18 outils ou plus pour un seul agent, le modèle commence à confondre les options similaires et à faire de mauvais choix. Davantage d'outils ne signifie NOT pas davantage de capacités : passé un certain seuil, cela signifie des capacités moins fiables.

• 4 à 5 outils → sélection optimale
• 18 outils ou plus → fiabilité de la sélection dégradée

Voici un agent d'assistance doté d'un ensemble d'outils restreint et adapté à son rôle. Quatre outils, chacun ayant une fonction claire : vérifier le client, rechercher sa commande, traiter un remboursement et transmettre le dossier à un humain.

Le modèle n'a jamais à se demander lequel de vingt outils presque identiques appeler. Chacun correspond à une intention distincte.

Une nuance importante : le modèle sélectionne les outils principalement à partir de leurs descriptions, et non de leurs noms. Une bonne description indique la fonction de l'outil, ses valeurs de retour, les formats d'entrée avec des exemples, les cas particuliers et les limites d'applicabilité.

C'est pourquoi le nombre et la qualité des outils interagissent. Même 5 outils peuvent être mal aiguillés si leurs descriptions se chevauchent ou sont ambiguës. Plus vous accumulez les outils, plus il est probable que deux d'entre eux se ressemblent, et plus vous obtiendrez d'erreurs de sélection.

Imaginez que vous entassiez tout un service sur un seul agent : outils pour les clients, les commandes, la facturation, les stocks, les expéditions, l'analyse... plus de vingt entrées dans un tableau tools.

Plusieurs d'entre elles ont alors des noms similaires — lookup_order, find_orders, get_order_history, search_purchases. Le modèle doit lever l'ambiguïté à chaque tour, et sa précision diminue. Un trop grand nombre d'outils par agent est un anti-modèle reconnu, au même titre que les descriptions ambiguës.

La solution n'est pas de rendre les descriptions toujours plus longues, mais d'adapter les outils au rôle. Demandez-vous : quelle est la fonction de THIS agent et quel est l'ensemble minimal d'outils dont il a besoin pour l'assurer ?

Un agent chargé des remboursements a besoin d'outils d'identification, de commande, de remboursement et de transmission. Il n'a pas besoin de prévisions de stocks ni d'analyses marketing. Supprimer les outils non pertinents élimine les distractions et rend chaque sélection restante plus précise.

Lorsqu'une tâche nécessite réellement de nombreuses capacités, vous ne les placez pas toutes sur un seul agent. Vous utilisez une architecture multi-agents en étoile : un coordinateur décompose le travail et le délègue à des sous-agents spécialisés, chacun disposant de son propre ensemble d'outils restreint.

Vingt outils répartis entre quatre sous-agents (5 chacun) sont sélectionnés bien plus fiablement que vingt outils sur un seul agent. N'oubliez pas que les sous-agents n'héritent NOT pas de l'historique du coordinateur ; l'invite de chaque sous-agent doit donc transmettre explicitement son propre contexte.

Répartir les outils entre les sous-agents apporte un avantage supplémentaire : le principe du moindre privilège. Chaque AgentDefinition déclare uniquement les allowed_tools dont il a réellement besoin.

Un sous-agent de recherche en lecture seule ne reçoit jamais d'outil process_refund ou delete ; il ne peut donc pas les déclencher par erreur. Des ensembles d'outils plus restreints et adaptés au rôle sont à la fois plus fiables (meilleure sélection) et plus sécurisés (rayon d'impact plus limité). Une règle à retenir pour le coordinateur : son allowedTools doit inclure "Task" pour qu'il puisse déléguer.

Tout ce dont un agent a besoin ne doit pas nécessairement être un outil. Dans MCP, les primitives du serveur se répartissent en trois catégories :

• Outils — actions que le modèle déclenche
• Ressources — données ou contexte en lecture seule, comme des schémas ou des catalogues
• Invites — modèles réutilisables

Si le modèle a simplement besoin de lire un schéma ou un catalogue de produits, exposez-le comme une ressource plutôt que comme un outil. Votre tableau tools reste ainsi léger et réservé aux véritables actions — un autre moyen de rester proche de 4 à 5 outils opérationnels.

L'ensemble d'outils intégré de Claude Code est un bon exemple de définition rigoureuse des périmètres. Chaque outil a une fonction précise :

• Glob — trouver des fichiers selon un motif (par exemple **/*.test.tsx)
• Grep — rechercher dans le contenu des fichiers
• Read / Write / Edit — charger, créer et modifier précisément des fichiers
• Bash — exécuter des commandes shell

Aucun ne se chevauche. Le modèle les compose dans un flux progressif — rechercher les points d'entrée avec Grep, lire les fichiers, rechercher les utilisations avec Grep, lire les consommateurs — plutôt que de choisir entre des options redondantes.

Avant de déployer un agent, effectuez cette vérification :

• L'ensemble d'outils est-il proche de 4 à 5 outils et nettement inférieur à 18 ?
• Chaque outil correspond-il à une intention distincte, avec une description qui ne se chevauche pas avec les autres ?
• Les besoins en lecture seule sont-ils modélisés comme des ressources plutôt que comme des outils ?
• Si vous avez besoin de davantage de capacités, pouvez-vous répartir le travail entre des sous-agents dotés d'ensembles d'outils respectant le principe du moindre privilège ?

Si vous poussez un agent unique au-delà d'une douzaine d'outils, c'est le signal qu'il faut décomposer, et non rédiger des descriptions plus longues.

Points essentiels :

• 4 à 5 outils par agent est optimal ; la fiabilité diminue à mesure que le nombre augmente, et 18 outils ou plus nuisent sensiblement à la sélection.
• Le modèle sélectionne les outils à partir de leurs descriptions ; des outils qui se chevauchent ou sont ambigus provoquent donc un mauvais aiguillage, même en petit nombre.
• Adaptez les outils au rôle — supprimez les distractions plutôt que de rédiger des descriptions plus longues.
• Besoin de davantage de capacités ? Répartissez le travail entre des sous-agents (en étoile) dotés d'ensembles d'outils respectant le principe du moindre privilège ; transmettez explicitement le contexte, car les sous-agents n'héritent pas de l'historique.
• Modélisez les besoins en lecture seule comme des ressources MCP plutôt que comme des outils, afin de conserver un tableau tools léger.