CordisBench pose une question étroite mais très concrète aux équipes qui construisent des infrastructures d’agents dynamiques : lorsqu’un agent modifie les composants qui l’entourent, le modèle peut-il prévoir de manière fiable l’état laissé après ces changements ? Le nouveau protocole d’évaluation montre que les modèles identifient souvent correctement les composants concernés, mais deviennent nettement moins fiables pour prévoir l’état final, raisonner sur plusieurs ordres de nettoyage ou choisir une reconfiguration minimale lorsque les interactions se multiplient.
Le résultat d’ingénierie le plus important n’est pas seulement que les modèles se trompent. CordisBench définit aussi une sémantique de référence finie qui reproduit exactement le comportement du moteur Cordis pour toutes les observations et actions utilisées afin de noter 528 questions exécutables. Pour cette classe limitée de changements de cycle de vie, la conséquence mécanique peut donc être calculée. Une partie de la gouvernance du harnais d’agent cesse alors d’être un problème de formulation d’instructions pour devenir un problème de vérification.
L’évaluation isole le raisonnement sur le cycle de vie
CordisBench a été soumis à arXiv le 1er septembre et publie à la fois le code et un jeu de données figé. Il comprend 1 200 questions structurées issues de 240 systèmes. Les tâches couvrent l’identification des composants touchés, la prévision de l’état final pour un ordre de démontage donné, les conditions vraies pour tous ou certains ordres autorisés, ainsi que des actions de reconfiguration réellement exécutées.
Le protocole utilise deux cadres. Un cadre formel compact rend explicites les dépendances et les transitions d’état. Un cadre natif Cordis compile des motifs similaires dans des extensions exécutables avec Cordis 4.0.0-rc.7. Les auteurs font varier le nombre d’interactions pertinentes de 2 à 32 tout en conservant, pour chaque tâche, la même forme de question et la même règle de notation.
Les modèles évalués sont Gemini 3.7 Flash, GPT-5.6 Luna et DeepSeek V4 Flash avec un effort de raisonnement faible. Cet échantillon est limité, mais la méthode présente un intérêt pratique : la notation est déterministe et les plans de reconfiguration sont exécutés au lieu d’être évalués à partir d’une réponse textuelle.
Identifier les effets est plus facile que prévoir l’état final
Le motif le plus net est la séparation entre localisation et prévision des conséquences. GPT-5.6 Luna reste par exemple proche du plafond lorsqu’il doit identifier les composants affectés, tandis que son score sur les conditions atteignables dans le cadre formel passe de 91,7 % à 14,1 % lorsque le nombre d’interactions augmente. Dans le cadre Cordis, son taux de réussite sur les reconfigurations exécutées passe de 62,5 % à 25,0 %.
Une partie de la baisse a des causes identifiables. Vingt-neuf réponses de Gemini atteignent la limite initiale de 8 192 jetons de sortie, et l’augmentation de cette limite améliore sensiblement plusieurs résultats sur les grandes instances. Les auteurs utilisent également un diagnostic avec un nombre fixe d’ordres de démontage afin de ne pas confondre l’augmentation des dépendances avec la seule multiplication des ordres possibles.
Davantage de raisonnement peut récupérer une partie des performances. Sur un sous-ensemble équilibré à 16 interactions, la précision de prédiction de GPT-5.6 Luna dans Cordis passe de 31,2 % sans raisonnement à 85,4 % avec un effort moyen, tandis que la réussite des reconfigurations exécutées passe de 0 % à 50 %. Le coût atteint alors environ 2 967 jetons de raisonnement par question en moyenne.
Certaines décisions de cycle de vie ne devraient pas utiliser le modèle
Le résultat système le plus fort est l’accord complet entre la sémantique de référence finie et l’exécution Cordis sur les 528 questions exécutables, pour toutes les observations et actions servant à la notation. Dans le cadre restreint du benchmark, du calcul probabiliste est donc consacré à des conséquences que le logiciel peut déterminer exactement.
Pour un système en production, cette distinction est essentielle. Un modèle reste utile pour choisir des objectifs, interpréter une intention ambiguë ou arbitrer entre des politiques impossibles à formaliser complètement. Le retrait d’une dépendance, l’ordre de nettoyage ou la restauration d’un état explicitement représenté relèvent d’une autre catégorie. Lorsque ces mécanismes sont connus, demander au modèle de les prédire ajoute une surface d’erreur et un coût d’inférence évitables.
Le principe d’architecture consiste donc à placer les conséquences déterministes sous la frontière du modèle. L’agent peut proposer une modification du harnais, mais un vérificateur d’exécution devrait calculer les dépendances concernées, les ordres de nettoyage autorisés, les contraintes sur l’état résultant et la validité de la reconfiguration avant son exécution.
L’évolution d’un harnais exige deux contrôles différents
CordisBench arrive quelques heures après HarnessDev, un autre préprint du 1er septembre déjà couvert par Aipolix. HarnessDev met en évidence un problème plus large : une amélioration choisie à partir d’un ensemble visible ne se transfère pas forcément à des tâches cachées ou à un autre modèle exécuteur. CordisBench ajoute une couche complémentaire.
Ces deux résultats ne doivent pas être réduits à un avertissement général sur les agents autonomes. Ils impliquent deux mécanismes d’assurance distincts. Les modifications sémantiques d’un harnais doivent passer des tests empiriques de promotion, car leur effet sur les tâches aval n’est généralement pas calculable. Les changements mécaniques de cycle de vie devraient, en plus, faire l’objet d’une vérification déterministe lorsque les dépendances et les effets de nettoyage sont suffisamment explicites.
On obtient ainsi une architecture de livraison plus précise. Il faut d’abord vérifier qu’une nouvelle version améliore réellement le travail visé sur des tâches cachées et avec les modèles exécuteurs de production. Il faut ensuite vérifier séparément qu’elle ne peut pas laisser l’environnement d’exécution dans un état invalide lorsque des composants sont ajoutés, retirés ou arrêtés selon différents ordres autorisés.
Un résultat utile, mais volontairement limité
CordisBench est un préprint et ne constitue pas une mesure répliquée des taux de panne en production. Les cas à 24 et 32 interactions sont des tests de résistance, pas une estimation de la taille habituelle des harnais déployés. Les tâches natives Cordis utilisent un ensemble contrôlé d’ordres de démontage et se concentrent sur le retrait lié aux dépendances et la restauration d’état lors du nettoyage. Elles ne couvrent ni les actions externes irréversibles, ni les pannes, ni le remplacement dynamique complet des modules.
L’évaluation sur trois modèles laisse également ouverte la question des modèles plus puissants, de l’accès aux outils, du retour d’exécution et des nouvelles tentatives. Gemini est proche du plafond sur plusieurs tâches et certains grands cas sont sensibles à la limite de sortie.
Ces limites renforcent la conclusion au lieu de l’annuler. CordisBench ne montre pas que les modèles sont incapables de gérer un harnais dynamique. Il montre qu’avant d’ajouter du raisonnement, il faut déterminer quelles décisions sont réellement probabilistes. Lorsqu’une transition d’état peut être dérivée mécaniquement, une architecture plus sûre et moins coûteuse consiste à la calculer ou à la vérifier, puis à réserver le modèle aux décisions réellement incertaines.