Un tool, ça marche. Dix tools dans un agent, c'est là que ça devient intéressant — et fragile. Voici les patterns que j'applique sur mes déploiements en production.
Le piège du catalogue plat
L'approche naïve : balancer 20 tools au modèle et espérer qu'il choisisse bien. Résultats : dérive, mauvais choix, latence (le modèle relit 20 descriptions à chaque tour).
Pattern 1 : hiérarchie de tools
Au lieu de tools granulaires, exposez des tools composites qui encapsulent plusieurs appels :
- ❌
list_users,get_user,get_orders,get_order_items - ✅
get_customer_full_context(customer_id)qui fait les 4 en interne.
Moins de décisions pour le modèle, résultats plus cohérents, latence réduite.
Pattern 2 : routing par domaine
Pour les gros catalogues, un premier appel classifier route vers le bon sous-agent qui n'a accès qu'à ses propres tools. Finie la tentation de mélanger.
Pattern 3 : parallélisation
Claude et GPT-5 supportent l'appel de plusieurs tools en parallèle. Exploitez-le : si l'agent a besoin de 3 infos indépendantes, il les récupère en 1 tour au lieu de 3.
// Dans le system prompt
Si plusieurs informations indépendantes sont nécessaires,
appelle les tools en parallèle dans un même tour.
Exemples d'indépendance : lister les users + charger la config
système. Exemple de dépendance : charger un user puis ses orders.Pattern 4 : verification après action
Pour les actions irréversibles, un tool dédié verify_and_confirm oblige le modèle à résumer l'action et demander confirmation. Pattern simple, il évite 95 % des boulettes.
Pattern 5 : observabilité
Loguer chaque appel de tool avec : input, output, durée, trace d'agent. Sans ça, debugger une dérive prend des jours. Datadog, LangSmith, ou logs maison structurés — peu importe, mais c'est non-négociable.
Pattern 6 : tools 'retour en arrière'
Quand l'agent fait une erreur, il a besoin d'un tool pour annuler. Exemple : undo_last_action(reason). Ça force aussi l'agent à réfléchir avant d'agir, parce qu'il sait qu'il devra justifier un éventuel undo.
Combien de tours maximum ?
Empiriquement : 50 tours pour du dev, 20 pour la plupart des use cases business, 10 pour le support client. Au-delà, ROI décroissant et risque de dérive élevé.
Ressources
Besoin d'architecter un système multi-tools ? J'en ai déployé plusieurs.
