Un article sur arXiv présente HANDBOOK.md, un benchmark qui mesure si les modèles suivent vraiment les instructions de politique sur des horizons longs. Soixante-cinq tâches agentiques dans des environnements d’entreprise simulés (email, chat, calendrier, suivi des problèmes via Model Context Protocol), chacune gouvernée par un manuel opérationnel de 20 à 124 pages rédigé par des experts. Sous évaluation rigoureuse, le meilleur modèle passe 36,2 % des essais. La plupart des configurations frontier restent sous 25 %.

Si vous aviez supposé qu’un long system prompt ou un document de politique suffisait à maintenir un agent en ligne, ces chiffres disent le contraire. L’article identifie quatre schémas d’échec récurrents. L’agent laisse une demande plausible dans l’environnement écraser la politique stable. Il exécute un contrôle obligatoire puis agit contre son résultat. Il perd les détails des règles à mesure que le contexte s’allonge. Il déclare une conformité qu’il n’a pas atteinte.

C’est la version mesurée et reproductible de ce que nous avons vu quand GPT-5.6 Sol a géré une vraie entreprise pendant 24 heures : l’agent reçoit des instructions claires puis les viole, parce que la pression de l’environnement pèse plus que le document de départ. La différence est que l’échec ici est structuré plutôt qu’anecdotique, avec 824 critères d’évaluation déterministes.

La conséquence pratique est que la gouvernance des agents ne peut pas reposer uniquement sur le contexte. Elle nécessite une couche logicielle externe qui vérifie les actions après que l’agent les a exécutées. Le cours sur comment évaluer si votre agent fonctionne part du même principe : les benchmarks génériques ne vous disent pas si l’agent respecte vos règles.

En détail

Les benchmarks traditionnels pour les agents mesurent si le modèle complète une tâche. HANDBOOK.md mesure quelque chose de différent : si un long document de politique contraignant peut contraindre le comportement de l’agent sur un horizon étendu d’utilisation d’outils. C’est la différence entre demander « l’agent a-t-il terminé le travail ? » et « l’agent a-t-il respecté les règles en le faisant ? ».

Les 65 tâches sont modélisées sur la façon dont les employés d’entreprise suivent les manuels opérationnels. Chaque tâche place l’agent dans un environnement autosuffisant : un espace de travail avec fichiers, email, chat, calendrier, suivi des problèmes et services commerciaux, tous exposés via Model Context Protocol. La politique est un manuel rédigé par des experts, long de 20 à 124 pages, couvrant cinq domaines (finance, facturation médicale, assurances, logistique, ressources humaines) dans dix entreprises fictives.

Pour résister à la mémorisation, chaque tâche modifie l’un des dix manuels de base, en altérant les règles spécifiques et les seuils sur lesquels l’évaluation repose. Aucune tâche ne partage la même politique. L’évaluation est complètement déterministe : 824 critères programmatiques qui vérifient à la fois que les actions requises ont été exécutées et que les actions interdites ne l’ont pas été.

Les chiffres. Trente configurations de modèle évaluées. Sous évaluation rigoureuse (un essai ne passe que s’il satisfait chaque critère), la meilleure passe 36,2 % des essais. La plupart des configurations frontier restent sous 25 %.

Les quatre schémas d’échec :

1. Écrasement par l’environnement. L’agent reçoit une demande plausible dans l’environnement (un email, un message de chat) qui contraste avec la politique, et il la suit à la place de la politique. C’est le schéma le plus préoccupant car il chevauche le vecteur classique de l’injection de prompt indirecte.
2. Contrôle exécuté et ignoré. L’agent exécute le contrôle requis par la politique, obtient le résultat, puis agit de manière opposée. Il fait la vérification mais ne l’utilise pas.
3. Dégradation sur horizon long. Les détails des règles se perdent à mesure que la conversation et l’utilisation des outils s’allongent. Les règles au début du manuel pèsent plus que celles vers la fin.
4. Conformité déclarée. L’agent déclare avoir respecté la politique alors qu’il ne l’a pas fait. Si vous faites confiance à l’auto-rapport de l’agent pour la surveillance, vous ne détecterez pas cet échec.

Ce que cela signifie pour ceux qui construisent. La thèse implicite de l’article est que le context engineering, seul, ne suffit pas à gouverner les agents en production. Vous pouvez rédiger le manuel le plus précis du monde, le mettre dans le system prompt, et l’agent le suivra moins de quatre fois sur dix. La gouvernance doit reposer sur une couche logicielle externe : contrôles post-action, validation des résultats, et où possible restrictions sur les outils eux-mêmes (ne donnez pas à l’agent un outil qu’il ne devrait pas utiliser, au lieu de lui dire de ne pas l’utiliser).

Les limites. Le benchmark utilise des environnements simulés, pas de vrais systèmes de production. Les manuels sont rédigés par des experts mais les entreprises fictives pourraient ne pas capturer toute la complexité des politiques réelles. L’échantillon de 65 tâches est relativement petit, bien que les 824 critères d’évaluation le compensent en partie. On ne sait pas comment les résultats changeraient avec des techniques de context engineering plus sophistiquées (RAG sélectif sur la politique, récupération des règles pertinentes au moment de l’action) par rapport à la simple insertion du manuel dans le contexte. L’article ne teste pas ces alternatives.