Un nom d’agent stable n’est pas l’élément que vous avez examiné : fixez l’identité de candidat.
Le nom d’un agent peut rester le même tandis que ses compétences, outils et permissions changent. Séparez le nom, le candidat de comportement et l’identité d’exécution pour une revue et un retrait.
Deux agents peuvent partager un nom tout en différant sur tous les aspects importants pour une évaluation. Supposons qu’un « Agent de recherche » réussisse l’évaluation un lundi. Mardi, l’étiquette reste inchangée, mais une compétence a été remplacée, un outil a obtenu des droits d’écriture et une règle de routage envoie certaines requêtes par un autre chemin. Sur un organigramme, il s’agit toujours du même agent. En tant que preuve de ce qui a été testé, cette réponse n’est pas suffisamment précise.
L’étiquette indique un rôle. Ce qu’elle ne peut pas indiquer, c’est la combinaison spécifique des éléments influençant le comportement qui a permis de réussir l’évaluation. Ce fossé s’agrandit à mesure que le comportement de l’agent dépasse le simple appel à un modèle pour devenir une composition : modèle, instructions, compétences, outils, permissions, politique de mémoire, routage, hooks, harness et tout ce que l’application hôte ajoute.
Les noms coordonnent, les candidats fournissent des preuves
Personne ne souhaite que chaque révision interne devienne une nouvelle identité publique accompagnée d’un numéro de série. Les gens ont besoin d’un nom qui dure. Une équipe composée d’un agent de recherche, d’un agent de dépendances et d’un agent de support bénéficie de labels indiquant la fonction de chacun et sa place au sein de l’équipe.
Une évaluation, quant à elle, pose une autre question : à quel candidat comportemental spécifique ce verdict s’applique-t-il ? Imaginez une évaluation menée sur un seul modèle, un ensemble de prompts, un ensemble de compétences, des limites d’outil, une politique de permissions et une configuration de routage. Tous les éléments qui ont une importance pour la mesure font partie de ce que le résultat décrit. En changeant l’un d’eux, le résultat précédent peut encore faire allusion au nouveau candidat, mais il ne le valide plus.
Un nom amical peut justement cacher cela. L’identité du produit reste stable tandis que la composition exécutable qui le sous-tend évolue. L’identité pour les personnes assure la continuité, tandis que l’identité pour les candidats assure la précision.
La configuration devient un matériel inspectable
Les produits d’agents actuels révèlent déjà des éléments de ce modèle, bien qu’aucune architecture unique ne soit partagée entre eux. Certains outils permettent de définir des agents dans des fichiers regroupant des instructions ciblées, des outils, des contraintes, des compétences sélectionnées ainsi que des serveurs MCP, accompagnés de paramètres de modèle et de permissions ; les définitions spécifiques au projet peuvent être stockées dans le répertoire de version. Il s’agit d’une approche de conception et non d’une norme, mais elle montre que la configuration n’a plus besoin d’être une configuration invisible autour d’une appel de modèle. Elle peut être un artefact que l’on lit et que l’on examine.
Un autre modèle conserve les prompts, les listes d’outils, les plannings, les identifiants et les paramètres de mémoire dans Git, de sorte que chaque modification passe par une demande de fusion et laisse une trace d’examen, la possibilité de revenir en arrière ainsi qu’un historique d’audit. Le fait qu’une organisation adopte cette méthode ne prouve rien quant à ce que chaque équipe devrait faire, mais il montre que le comportement des agents peut être géré comme une configuration modifiable avec un historique de type logiciel.
D’autres signaux indiquent la même tendance. Certaines plateformes de fournisseurs offrent déjà des configurations d’agents réutilisables et versionnées, bien que ces interfaces soient encore en version bêta et en évolution constante. Les feuilles de route protocolaires mentionnent l’identité des agents comme un sujet de travail futur, ce qui n’est qu’un plan et non un comportement déjà mis en œuvre. Rien de tout cela ne signifie que le problème est résolu. Néanmoins, ces exemples justifient une affirmation modeste : lorsque le comportement provient de parties indépendamment modifiables, l’ensemble assemblé a besoin de son propre identifiant.
Les parties versionnées peuvent encore former un tout ambigu
C’est là que la difficulté devient déceptivement ennuyeuse. Un modèle a une version. Une compétence a une révision. Un répertoire a un commit. Un serveur MCP a un déploiement, une politique de mémoire peut avoir sa propre version, et l’agent peut également en avoir une visible par le fournisseur. Chaque élément peut être nommé, tandis que le résultat global reste incertain.
Examinons les cas où le verrouillage ne fonctionne pas pleinement :
- Le prompt est verrouillé, mais l’alias du modèle change.
- Le modèle est verrouillé, mais une compétence utilise la version la plus récente.
- La compétence est fixée, mais l’application hôte modifie les outils qu’elle expose.
- Une politique de permissions change, tandis que le nom public reste identique.
Le système est versionné par fragments, et il n’est pas clair quel est exactement l’exécutable utilisé. La pratique de publication de logiciels offre une analogie utile, avec une limite : une configuration d’agent n’est pas nécessairement un seul fichier binaire ou un manifeste géant. L’analogie concerne l’objet auquel s’applique une décision. Une équipe de développement ne se contente pas de dire « nous avons testé le Produit X » lorsqu’il existe plusieurs versions. Le nom du produit facilite la coordination, tandis que la version ou le commit précis indique quel candidat est concerné par cette affirmation. L’examen des agents nécessite cette même séparation chaque fois que la configuration peut modifier significativement le comportement.
Trois identités valent mieux qu’une
Forcer un seul identifiant à porter tous les sens crée rapidement de la confusion. Il vaut la peine de séparer au moins trois niveaux.
Identité destinée aux utilisateurs
Le rôle durable : son nom, sa finalité, son propriétaire, ses responsabilités et sa position au sein du système. Il doit rester suffisamment stable pour permettre aux personnes et aux autres agents de coordonner leurs actions autour de lui.
Identité du candidat au comportement
Il s’agit de l’ensemble exact des dépendances influençant le comportement que l’équipe évalue, approuve, compare ou met en production. Selon l’architecture, il peut faire référence à :
- le modèle qui s’exécute, avec toutes les paramétrisations modifiant son comportement,
- le texte des instructions ou le paquet de prompts,
- les compétences liées à des versions précises,
- les outils et les serveurs MCP auxquels il peut accéder,
- ce qu’il peut faire et ce qui nécessite une validation,
- la manière dont la mémoire est conservée et utilisée,
- les règles de routage et de transfert de tâches,
- les points d’interception du cycle de vie,
- la version du framework ou du runtime, si celle-ci modifie le comportement,
- Paramètres de la surface hôte, si celui-ci contrôle le contexte, les outils, les validations ou l’exécution.
Le mot clé est « matériel ». L’objectif n’est pas de serialiser chaque paramètre simplement parce qu’il existe. Il s’agit plutôt de capturer les dépendances dont le changement pourrait rendre fausse une affirmation concernant la revue, la reproduction ou le retrait.
Identité d’exécution
Même un candidat parfaitement fixé ne prend pas en compte tout ce qui affecte une exécution. Une exécution dépend également des entrées de l’utilisateur, du contenu de la mémoire modifiable, du contexte récupéré, de l’état du système externe, des données en temps réel, des identifiants, des décisions humaines ainsi que du nondéterminisme propre au modèle. Là où cela a de l’importance, ces éléments font partie de la filiation de l’exécution.
En gardant les différentes couches séparées, on évite deux erreurs opposées : considérer un nom convivial comme une identité technique exacte, et traiter un instantané de configuration comme s’il enregistrait tous les faits relatifs à une exécution en temps réel.
Quoi fixer en priorité
Le degré de fixation dépend de ce qui est en jeu. Un assistant personnel à faible risque peut se contenter d’un commit de répertoire ou d’une version du fournisseur. Un flux de travail en production offrant des droits d’écriture exige davantage. Pour une évaluation, notez tout ce qui concerne la mesure : modèle, prompt, compétences, outils, permissions, routage et état du système.
Omettez le schéma au début et utilisez la liste ci-dessus comme liste de contrôle. Pour chaque élément, demandez-vous s’il resterait qualifié de candidat évalué après modification. Si la réponse honnête est non, cet élément doit faire partie de l’identité du candidat ou de son arbre généalogique.
Les valeurs sensibles n’ont pas besoin d’être copiées dans le registre. Une configuration peut faire référence à une identité secrète, à une classe de identifiants ou à une limite de permissions sans transformer le manifeste en un lieu propice aux fuites de secrets. Une identité précise devrait améliorer la traçabilité et ne pas créer de problèmes de sécurité supplémentaires.
L’évaluation, le débogage et le rollback partagent un même besoin
Ces activités semblent être trois préoccupations opérationnelles distinctes, mais chacune nécessite un objet réparable.
Évaluation. Tout score constitue une affirmation concernant un objet donné. Lorsque cet objet ne peut pas être reconstitué avec suffisamment de précision, le score peut survivre à l’objet qu’il décrivait. Toute modification n’annule pas nécessairement toute évaluation : corriger une faute d’orthographe dans une compétence sans rapport a à peine d’impact sur un critère de raisonnement, tandis qu’un changement de permissions peut ne pas affecter la qualité du texte écrit mais décider d’un examen de sécurité. Ce qui compte, c’est ce qui était mesuré, et cette décision doit être prise ouvertement afin qu’un nom constant ne puisse pas masquer un écart substantiel.
Débogage. En l’absence d’identité de configuration, l’enquête sur un incident se transforme en une recherche à travers de multiples niveaux. Un fichier de prompts, l’historique de la console, le registre des outils, le journal de déploiement, une capture de mémoire, ainsi que les branches et les transcriptions peuvent chacun être exacts pour leur propre niveau, tandis que l’ensemble reste flou. Une référence précise du candidat simplifie la question de base : cette exécution défaillante utilisait-elle réellement le candidat que tout le monde supposait ? Si c’est le cas, il convient ensuite d’examiner l’état et le comportement de l’exécution. S’il ne s’agit pas de ce candidat, cette incohérence constitue déjà la découverte. Une défaillance provenant du candidat retenu et une exécution qui ne l’a jamais utilisé relèvent de catégories distinctes d’échecs.
Réversion. Supposons que le candidat approuvé ait combiné une instruction, un ensemble de compétences, une politique de permissions, une règle de routage et un environnement de exécution. Le simple remplacement de l’instruction ne signifie pas pour autant que l’ancien candidat est rétabli. Les équipes doivent se demander s’elles peuvent reconstruire l’intégralité du dernier candidat approuvé ou seulement annuler la composante qui a attiré leur attention. La première option constitue une véritable réversion, tandis que la seconde relève d’une modification espérant corriger le problème.
Un dernier élément est facile à négliger. Trouver « le dernier candidat accepté » nécessite une recherche, et cela ne fonctionne que si les candidats disposent d’un historique de succession. L’identité exacte indique ce que représentait chaque candidat, mais pas lequel a remplacé lequel ou ce qui a changé entre-temps. Si la réversion est importante, chaque candidat devrait indiquer son prédécesseur et énumérer les différences substantielles, afin que la restauration ne soit jamais une quête hasardeuse.
Ne laissez pas la configuration éclipser l’exécution
La réaction excessive et tentante consiste à conserver une image globale de tout. Cela engendre de nouveaux problèmes. La mémoire mutable, les documents récupérés, les entrées utilisateur, l’état de l’API externe, l’horloge et les identifiants contribuent tous à définir une exécution. Certains éléments sont sensibles, d’autres doivent rester dynamiques, et d’autres encore ne peuvent pas être reproduits exactement, ce qui explique pourquoi ils ne sont pas tous inclus dans le candidat retenu.
Une frontière plus claire se présente comme suit :
- La couche de configuration enregistre quelles dépendances influençant le comportement ont été choisies.
- La couche d’exécution enregistre quelle exécution a utilisé ce candidat, ainsi que toutes les entrées mutables importantes.
- La couche d’approbation enregistre le candidat exact auquel l’approbation a été appliquée.
Les couches peuvent faire référence les unes aux autres sans se fusionner en un seul artefact. Cette frontière empêche également une « identité exacte » de devenir une prétention que les preuves ne peuvent pas étayer. Identifier un candidat ne rend pas un modèle déterministe, ne fige pas les systèmes extérieurs ni ne garantit un résultat identique par la suite. Cela permet simplement de rendre le sujet de la prétention récupérable, ce qui est déjà d’une grande aide.
Un test à cinq questions
Lorsqu’un agent nommé est suffisamment important pour être examiné ou mis en circulation, posez les questions suivantes :
- Qu’est-ce qui peut changer sans changer le nom ? Dans la plupart des systèmes, bien plus que ce à quoi on s’attend.
- Quels de ces changements pourraient invalider cette prétention d’examen en particulier ? Cela dépend du fait que la décision concerne la qualité, la sécurité, les permissions, la fiabilité, le coût ou la disponibilité.
Rien de tout cela ne nécessite une cérémonie pour chaque modification. La précision est essentielle lorsque des affirmations commencent à avoir des conséquences. Comme le comportement des agents est assemblé au-dessus et autour du modèle, et que cet assemblage devient modulaire, portable, versionné ou interchangeable, la configuration n’est plus une simple mise en place accessoire. Elle fait partie du candidat exécutable. Le nom peut rester inchangé, mais les preuves doivent indiquer ce qui a changé.
Lectures complémentaires
- Pourquoi les scores de précision des agents sont trompeurs : pass^k, perturbations et injection de défauts — Pourquoi pass@1 cache des agents IA peu fiables, et comment pass^k, les ensembles de perturbations des entrées et l’injection de défauts révèlent les lacunes en termes de cohérence, de stabilité et de tolérance aux pannes.
- Pourquoi les agents qui impressionnent lors des démos échouent en production, et ce qu’il convient de construire à la place — Points de défaillance, le compromis entre agent unique et plusieurs agents, des pratiques de conception telles que les tentatives répétées et les solutions de secours, ainsi que le coût total lié au fonctionnement d’un agent IA au-delà des frais de token.