Un agent, c’est un système qui choisit son étape suivante
La définition tient en une phrase et elle est plus utile que toutes les listes de caractéristiques : un agent est un système qui décide lui-même de son étape suivante, au lieu de suivre une séquence que quelqu’un a écrite à l’avance. Les outils, la mémoire, la boucle de raisonnement, tout ce que le vocabulaire courant énumère, ne sont que des moyens au service de cette propriété. Un système qui appelle un modèle à un endroit précis d’une séquence fixe n’est pas un agent, même si son fournisseur l’appelle ainsi. Cette distinction n’est pas une question de terminologie : elle décide de ce qui est facile et de ce qui est difficile. Un agent traite des situations que personne n’avait prévues, ce qu’aucun workflow ne sait faire. En échange, il est plus lent, plus cher par unité, impossible à tester exhaustivement puisque l’espace de ses comportements ne s’énumère pas, et capable de faire une chose à laquelle vous n’aviez pas pensé. L’échange est favorable dans un cas précis, et défavorable partout ailleurs.
Ce que la propriété entraîne
L’espace des comportements n’est pas énumérable. Vous pouvez tester un workflow en parcourant ses branches, parce qu’elles sont en nombre fini et écrites. Vous ne pouvez pas faire cela avec un agent : le nombre de chemins possibles dépend du nombre d’outils et de la longueur de la boucle, et il devient très grand très vite.
La même entrée peut produire des chemins différents. Un système qui a passé les tests peut échouer d’une manière que les tests ne pouvaient pas trouver. Ce n’est pas un défaut à corriger, c’est la propriété qu’on a choisie, et la réponse consiste à borner les conséquences plutôt qu’à courir après le déterminisme.
Le coût suit le nombre d’étapes. Douze étapes coûtent environ douze fois un appel unique. Invisible à cent requêtes par jour, décisif à cent mille.
Le diagnostic demande une trace. Quand un workflow échoue, on lit le code. Quand un agent échoue, on a besoin de savoir ce qu’il a décidé à chaque étape et pourquoi, ce qui suppose une journalisation conçue à l’avance et non ajoutée après le premier incident.
Le test de la feuille de papier
Il existe une manière simple et honnête de décider, et elle ne demande aucune expertise technique. Asseyez-vous et écrivez les étapes du processus sur une feuille, sous forme de séquence, avec les branchements nommés.
La plupart des équipes y arrivent, et s’en étonnent. Le sentiment qu’un processus est trop compliqué pour être ordonné vient presque toujours de ce que personne n’a essayé, et une heure de travail suffit à le dissiper.
Si vous y arrivez et que les branchements se comptent, construisez cela. Vous obtiendrez le même résultat pour une fraction du coût, en une fraction du temps, avec un système qu’une personne arrivée l’an prochain pourra reprendre. Choisir un agent dans ce cas revient à acheter de l’imprévisibilité et à la payer sur toutes les dimensions.
Les trois raisons de ne pas y arriver
Quand l’exercice échoue réellement, la raison compte, parce que deux des trois raisons possibles ne plaident pas pour un agent.
Les entrées varient plus qu’on ne peut les énumérer. C’est le meilleur argument en faveur d’un agent, et le seul qui tienne seul. Une boîte de réception qui reçoit des demandes formulées de mille façons différentes en est l’exemple type.
L’étape suivante dépend de ce que la précédente a trouvé, sur un espace large. Deuxième meilleur argument. Une recherche documentaire où ce qu’on trouve détermine où chercher ensuite relève de ce cas.
Personne n’a encore compris le processus. La plus fréquente des trois, et celle qui ne plaide pas du tout pour un agent. C’est un argument pour passer une semaine sur le processus. Construire un agent ici revient à demander à une machine de découvrir un fonctionnement que l’organisation n’a jamais formulé, et le résultat est un système dont personne ne peut dire s’il fait ce qu’il faut.
Le nombre d’outils, décision sous-estimée
Chaque outil ajouté à un agent agrandit l’espace de ses comportements possibles, donc la surface à tester et la surface d’erreur. Trois outils bien choisis produisent un système dont on peut raisonner ; quinze produisent un système dont plus personne ne sait dire ce qu’il peut faire.
La règle utile porte moins sur le nombre que sur les droits. Chaque outil reçoit l’habilitation la plus étroite qui permette la tâche, et un outil qui écrit quelque part est traité différemment d’un outil qui lit. Cette distinction est structurelle, donc fiable, contrairement à une consigne qui demanderait au système de se retenir.
C’est aussi la meilleure protection contre la dérive la plus courante : un assistant conversationnel auquel on ajoute un outil, puis un autre, jusqu’à ce que l’un d’eux écrive quelque part. Personne n’a pris la décision de construire un agent, et pourtant il y en a un en production, avec une journalisation conçue pour un système dont le pire résultat était une phrase malheureuse.
