outil

En profondeur

Un outil se déclare avant de servir : le harnais décrit au modèle, dans le contexte, ce que l’outil fait et ce qu’il attend comme paramètres. Quand le modèle juge un appel pertinent, il produit une demande formatée, que le harnais intercepte, valide, puis exécute. Le résultat revient dans le contexte, sous forme de texte, et le modèle en tient compte pour la suite. Tout le circuit passe donc par du texte : c’est un échange entre le modèle et son harnais, jamais un accès direct au système d’information.

La qualité d’un outil tient moins à son code qu’à sa description. Le modèle choisit sur la foi d’un nom et de quelques lignes d’explication : deux outils aux périmètres qui se chevauchent produisent des appels erratiques, et un paramètre mal nommé produit des valeurs inventées. Un outil n’est pas non plus l’équivalent d’une interface de programmation : une même interface donne souvent lieu à plusieurs outils, taillés pour des intentions et non pour des ressources techniques. La règle empirique est de concevoir pour un lecteur pressé qui ne verra jamais la documentation complète.

Le risque principal n’est pas que le modèle se trompe d’outil, c’est qu’il en dispose sans garde-fou. Un outil qui écrit, envoie ou paie est une action sur le monde, et le texte qui la déclenche peut provenir d’un document lu au passage plutôt que de votre demande. La règle est donc de séparer ce qui lit de ce qui agit, de faire confirmer les actions irréversibles, et de traiter tout résultat d’outil comme une entrée non fiable. S’ajoute un piège plus discret : chaque outil déclaré occupe du contexte et sollicite l’attention du modèle, si bien qu’un catalogue trop fourni dégrade les choix au lieu de les élargir.