Anti-Pattern Tool Calling for Everything : appel d’outils pour tout

Idée en 30 secondes

Tool Calling for Everything est un anti-pattern où l'agent convertit presque chaque demande en tool-call par défaut.

Résultat : même les scénarios simples passent par des étapes inutiles, latency et cost augmentent, et le système devient plus fragile à cause des dépendances aux appels externes.

Règle simple : appelez un tool seulement si la tâche ne peut pas être couverte de façon fiable sans données externes ou action externe.

Exemple de l'anti-pattern

L'équipe construit un agent support pour des questions de commande, remboursement et policy de service.

Même pour une question policy simple, l'agent appelle d'abord des tools.

response = agent.run(
    "User: Quel est le délai de retour d'un produit ?"
)

Dans ce schéma, une réponse typique passe par une chaîne d'outils inutile :

tool_result = run_tool("get_return_policy")
answer = agent.summarize(tool_result)
return answer

Pour ce cas, un workflow court sans tool-call suffit :

policy = RETURN_POLICY_BY_REGION[region]
return format_return_policy(policy)

Ici, le tool-calling excessif ajoute :

• des appels externes inutiles
• un coût plus élevé par requête
• des points de défaillance supplémentaires

Pourquoi cela arrive et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe construit une architecture "tool-first" et ne garde pas de route simple sans outils.

Causes typiques :

• pas de chemin no_tool explicite pour les cas déterministes
• un même modèle d'exécution est appliqué à tous les types de demandes
• peur de répondre sans vérification externe même quand les données sont déjà déterministes
• absence de métriques qui montrent la valeur de chaque tool-call

Cela crée des problèmes :

• latency plus élevée - chaque tool-call ajoute une étape réseau et calcul
• cost plus élevé - le nombre d'appels LLM/tool augmente sur une demande typique
• fragilité des scénarios - même un cas simple dépend d'un service externe
• risque d'effets secondaires (changements d'état) - un appel inutile peut remettre à jour un statut ou dupliquer une action externe
• debug difficile - plus dur d'expliquer pourquoi une requête simple est partie dans un tool-path

Contrairement à Too Many Tools, le problème principal ici n'est pas le choix entre de nombreux outils, mais la décision même de faire un tool-call quand il n'est pas nécessaire.

Signaux production typiques montrant que le tool-calling est déjà excessif :

• la majorité des demandes FAQ ou policy passent par tool-call alors que la réponse est déterministe
• tool_call_rate des routes FAQ ou policy reste élevé (par exemple 80%+)
• cost per request augmente alors que success rate change peu
• la panne d'un outil casse un scénario qui pourrait fonctionner localement
• l'équipe ne peut pas expliquer clairement quand le tool-call est obligatoire et quand il ne l'est pas

Point important : chaque tool-call signifie généralement un nouveau prompt et une nouvelle LLM inference. Quand les appels inutiles sont nombreux, le nombre d'étapes augmente sans gain de valeur utile.

Sans trace et visualisation d'exécution, il est difficile de voir quelle part des requêtes simples passe réellement par la route no_tool et quelle part continue à passer par des tool-calls inutiles.

Bonne approche

Commencez avec une route sans outils comme chemin par défaut. Ajoutez un tool-call uniquement quand des données externes, une vérification d'état actuel, ou une action externe sont réellement nécessaires.

Cadre pratique :

• pour chaque type de demande, définissez : no_tool ou tool_required
• essayez d'abord de couvrir la demande sans tool-call
• gardez les réponses déterministes dans workflow ou dans le code
• pour le chemin tool, définissez une allowlist étroite et un trigger clair
• ajoutez un nouveau tool-call seulement avec raison mesurable (par exemple amélioration de success rate sans hausse forte de latency et de cost per request)

def answer_support_question(user_message: str, order_id: str, region: str) -> str:
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "return_policy":
        return format_return_policy(local_return_policy(region))  # static config or local rules

    if route == "order_status":
        data = run_tool("get_order_status", order_id)
        return format_order_status(data)

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

Dans ce schéma, le tool-call devient ciblé : les outils sont appelés là où ils sont réellement nécessaires, pas par défaut.

Test rapide

Si vous répondez "oui" à ces questions, vous avez un risque tool-calling-for-everything :

• Une demande FAQ ou policy simple déclenche-t-elle régulièrement au moins un tool-call ?
• Une panne d'outil casse-t-elle parfois un scénario qui pourrait fonctionner sans appel externe ?
• Pour un cas typique, le nombre d'étapes tool/LLM est-il plus élevé que nécessaire (là où 0-1 appel suffirait) ?

Différence avec les autres anti-patterns

Too Many Tools vs Tool Calling for Everything

En bref : Too Many Tools concerne le choix instable entre de nombreux tools, tandis que Tool Calling for Everything concerne le fait même d'appeler un tool de façon inutile.

Agent Everywhere Problem vs Tool Calling for Everything

En bref : Agent Everywhere Problem concerne le reasoning agent inutile, Tool Calling for Everything concerne l'appel externe inutile même dans un chemin agent.

Giant System Prompt vs Tool Calling for Everything

En bref : ces anti-patterns se croisent quand always call tool est caché dans un grand prompt au lieu d'une logique de routage explicite.

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

Vérification rapide de l'anti-pattern Tool Calling for Everything.
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 qu'il faut très peu utiliser les tools ?
R : Non. Les tools sont nécessaires quand il faut des données externes, vérifier l'état actuel, ou exécuter une action externe. Le problème est seulement quand tool-call devient la valeur par défaut pour tous les cas.

Q : Quand un tool-call est-il vraiment justifié ?
R : Quand, sans lui, il est impossible de donner un résultat correct de façon fiable dans ce scénario sans croissance disproportionnée de latency, de cost ou de complexité de debug.

Q : Comment réduire les tool-calls inutiles sans gros refactor ?
R : Commencez par une étape : ajoutez une route no_tool pour le cas déterministe le plus fréquent et fixez une règle pour savoir quand le tool-call est obligatoire.

Et ensuite

Anti-patterns proches :

• Too Many Tools - quand trop de tools dans une route rendent le choix d'action instable.
• Agent Everywhere Problem - quand des agents sont utilisés même pour des tâches mieux couvertes par workflow.
• Giant System Prompt - quand des règles dans un seul prompt compliquent un comportement stable.

Ce qu'il faut construire à la place :

• Allowed Actions - comment fixer les actions autorisées par scénario dans le code.
• Routing Agent - comment séparer routes déterministes et cas complexes.
• Tool Execution Layer - où contrôler centralement tool-calls, policies et limites.