Anti-Pattern Too Many Tools : trop d’outils

Idée en 30 secondes

Too Many Tools est un anti-pattern où un agent reçoit trop d'outils sans frontières claires par type de tâche.

Le résultat est un bruit de sélection d'action : l'agent choisit plus souvent un outil non pertinent et consomme des étapes à re-sélectionner. Cela augmente la latency, le cost et l'instabilité de la réponse.

Règle simple : pour chaque scénario, l'agent ne doit voir que l'ensemble minimal d'outils réellement nécessaires.

Exemple de l'anti-pattern

L'équipe construit un agent support pour les demandes liées aux commandes, retours et paiements.

Au lieu d'un ensemble réduit, l'équipe donne à l'agent une grande liste d'outils "pour tous les cas".

response = agent.run(
    "User: Pourquoi le paiement de la commande #8341 échoue ?"
)

Dans ce schéma, l'agent a des dizaines d'options et peut partir dans la mauvaise direction :

tools = ["get_payment_status", "get_invoice", "get_order"]
selected_tool = agent.pick_tool(tools)
result = run_tool(selected_tool, order_id)

# l'agent peut choisir get_invoice d'abord,
# ne pas trouver la cause de l'échec,
# puis seulement passer à get_payment_status

Pour ce cas, une route courte avec quelques outils suffit :

payment_data = get_payment_status(order_id)
return format_payment_answer(payment_data)

Ici, l'excès d'outils ajoute :

• du bruit dans le choix des actions
• des appels d'outil inutiles
• un risque plus élevé de mauvais routage

Pourquoi cela arrive et ce qui se passe mal

Cet anti-pattern apparaît souvent quand une équipe essaie de construire immédiatement un agent "universel" pour toutes les demandes.

Causes typiques :

• ajout de nouveaux outils sans retirer les anciens
• absence d'allowlist d'outils par type de tâche
• peur que "un seul outil ne suffise pas"
• copie de gros toolsets de démos sans valider les cas production

Cela crée des problèmes :

• sélection instable - l'agent choisit un outil qui correspond formellement, mais n'est pas le meilleur
• latency plus élevée - boucle de sélection et appels répétés prennent plus de temps
• cost plus élevé - étapes tool ou LLM inutiles pour une demande typique
• contexte gonflé - le prompt contient trop de descriptions d'outils et de résultats intermédiaires
• debug difficile - difficile d'expliquer pourquoi l'agent a choisi ce chemin

Signaux production typiques montrant qu'il y a déjà trop d'outils :

• une demande utilisateur typique lance 3-5 appels d'outil alors que 1-2 suffiraient
• une même tâche passe par des chemins différents selon les runs
• l'équipe ne peut pas expliquer clairement pourquoi l'outil A est choisi au lieu de l'outil B
• l'ajout d'un nouvel outil dégrade la quality des scénarios existants

Au final, l'agent passe plus d'étapes à choisir l'action qu'à résoudre la tâche elle-même. Point important : le choix d'outil fait partie de l'inference LLM. Le modèle choisit une action parmi les options visibles dans le prompt. Quand le nombre d'outils augmente, le nombre de chemins possibles augmente aussi, et le choix devient moins stable : le modèle choisit plus souvent un outil qui semble convenir, mais n'est pas le meilleur.

Quand ce schéma grossit, sans trace ni visualisation d'exécution, il devient difficile de comprendre pourquoi l'agent a choisi ce chemin d'outils. C'est pourquoi les systèmes de production ont généralement une couche d'observabilité dédiée aux runs d'agents.

Bonne approche

Commencez par la route la plus simple qui couvre de façon stable la majorité des demandes actuelles. Ajoutez des outils uniquement lorsqu'il existe un échec mesurable, un risque ou une limite du design actuel.

Cadre pratique :

• définissez une tool allowlist claire pour chaque type de tâche
• gardez un petit ensemble d'outils sur chaque route
• ajoutez un nouvel outil seulement avec une raison mesurable (par exemple amélioration de success rate ou réduction d'erreurs sans forte hausse de latency et de cost per request)

def answer_payment_question(order_id: str, user_message: str) -> str:
    route = classify_intent(user_message)  # classifieur simple ou règles

    if route == "payment_status":
        allowed_tools = ["get_payment_status"]
        data = run_tool("get_payment_status", order_id)
        return format_payment_answer(data)

    allowed_tools = ["get_payment_status", "get_invoice"]
    return agent.run(
        user_message=user_message,
        allowed_tools=allowed_tools,
    )

Dans ce schéma, l'agent travaille avec un ensemble d'outils réduit et pertinent, donc le choix d'action devient plus stable.

Test rapide

Si vous répondez "oui" à ces questions, vous avez un risque too-many-tools :

• Une demande typique nécessite-t-elle régulièrement 3+ appels d'outil alors que 1-2 devraient suffire ?
• La même demande suit-elle des chemins d'outils différents selon les runs ?
• Les nouveaux outils sont-ils ajoutés plus vite que l'équipe ne peut les limiter, retirer ou revoir ?

Différence avec les autres anti-patterns

Tool Calling Everywhere vs Too Many Tools

Multi-Agent Overkill vs Too Many Tools

Giant System Prompt vs Too Many Tools

Auto-vérification : avez-vous cet anti-pattern ?

Vérification rapide de l'anti-pattern Too Many Tools.
Cochez les points pour votre système et regardez le statut ci-dessous.

Vérifiez votre système :

FAQ

Q : Est-ce que cela veut dire que beaucoup d'outils est toujours mauvais ?
R : Non. Le problème n'est pas le nombre en soi. Le problème est que l'agent voit trop d'options non pertinentes dans un scénario donné.

Q : Quand ajouter un nouvel outil ?
R : Quand il existe un signal concret : lacunes de couverture, échecs de quality ou limites de route que l'ensemble actuel ne peut pas couvrir sans croissance disproportionnée de latency, de cost ou de complexité de debugging.

Q : Comment réduire le chaos de sélection d'outils sans gros refactor ?
R : Commencez simplement : mettez une allowlist par type de tâche, fixez une limite de steps, et retirez les tools rarement utilisés ou redondants.

Et ensuite

Anti-patterns proches :

• Agent Everywhere Problem - quand un agent est ajouté même pour des tâches déterministes.
• Overengineering Agents - quand le système ajoute des couches sans bénéfice mesurable.
• Multi-Agent Overkill - quand il y a trop d'agents avec des rôles flous.

Ce qu'il faut construire à la place :

• Allowed Actions - comment définir des limites claires de ce que l'agent peut faire.
• Routing Agent - comment router les tâches et n'exposer à l'agent que les outils pertinents.
• Tool Execution Layer - où contrôler les appels d'outils et les politiques d'accès dans l'architecture.