Un modèle qui agit

Un service client reçoit une question : « ma commande 4417 est-elle partie ? ». Trois implémentations y répondent. La première envoie la question et la fiche de commande dans un seul appel au modèle, puis renvoie sa réponse : 900 jetons, 400 ms, un résultat identique à chaque exécution. La deuxième exécute une séquence écrite d'avance — extraire le numéro, appeler l'API de suivi, rédiger la réponse : trois appels, un chemin unique, un test par étape. La troisième donne au modèle quatre outils et le laisse décider : entre 2 et 30 appels, une trajectoire différente à chaque exécution, et une facture que personne dans l'équipe ne sait prévoir à l'avance.

Les trois répondent correctement au cas simple. L'écart n'apparaît que sur les bords : la commande n'existe pas, l'API de suivi renvoie 503, le client mentionne deux commandes dans la même phrase. Là, l'appel unique invente, la chaîne figée casse à l'étape prévue et s'arrête, l'agent essaie autre chose. Cette capacité à essayer autre chose est la seule chose que vous achetez en passant à un agent, et elle coûte cher : en jetons, en latence, en surface d'attaque et en heures de débogage. Toute cette leçon sert à décider si vous en avez besoin, parce que la réponse honnête est non plus souvent qu'on ne le prétend.