Comment un agent appelle-t-il un outil ?

Le modèle ne peut rien exécuter. C’est le point de départ, et il est constamment mal compris.

Le mécanisme réel

Vous fournissez au modèle une liste de fonctions disponibles, chacune décrite par un nom, une description en langage naturel et un schéma de ses arguments. Le modèle, plutôt que de répondre en texte, produit une sortie structurée du type « appeler chercher_client avec le paramètre nom égal à Dupont ».

Votre code reçoit cette structure, décide de l’exécuter ou non, appelle la vraie fonction, et renvoie le résultat au modèle sous forme de message. Le modèle poursuit avec cette information.

Ce que cette séparation permet

Elle est la raison pour laquelle un agent peut être sécurisé du tout. Entre l’intention du modèle et l’effet réel, votre code peut :

• valider les arguments contre un schéma et contre les règles métier ;
• vérifier les autorisations de l’utilisateur final, et non celles d’un compte de service ;
• refuser l’appel, et renvoyer le refus au modèle comme une observation ;
• demander une confirmation humaine avant d’agir ;
• journaliser l’appel.

Un intervieweur qui pose cette question vérifie souvent que vous ne croyez pas que le modèle « a accès » à votre base de données. Il n’y a jamais accès : il demande, vous exécutez.

Comment la fiabilité est obtenue

Les fournisseurs contraignent le décodage sur le schéma déclaré, ce qui garantit que les arguments produits sont syntaxiquement conformes. Ce qui n’est pas garanti, en revanche : que ce soit le bon outil, que les valeurs soient justes, ou qu’un identifiant fourni existe réellement. La validation métier reste à votre charge.

Les erreurs fréquentes en pratique

• Un argument inventé. Le modèle a besoin d’un identifiant client qu’il ne connaît pas et le fabrique. Le correctif est de rendre l’identifiant obtenable — un outil de recherche préalable — et de valider en base avant d’agir.
• Le mauvais outil, quand deux outils ont des descriptions voisines.
• Un appel omis : le modèle répond de mémoire alors qu’un outil aurait donné la vraie valeur. Cela se corrige dans l’invite, en exigeant l’usage de l’outil pour ce type d’information.

Ce qu’il faut renvoyer au modèle

Le résultat, mais aussi les erreurs, en clair. « Client introuvable » ou « paramètre date attendu au format ISO » sont des observations exploitables : le modèle corrige généralement son appel au tour suivant. Faire échouer la boucle sur une erreur d’outil gaspille cette capacité d’autocorrection, qui est l’un des vrais avantages de l’approche.