Des chercheurs le prouvent : gonfler AGENTS.md est nuisible, le fichier a une limite

Dans le preprint arXiv 2610.11007, le fichier de contexte d'un agent, qu'il s'agisse d'AGENTS.md ou d'un équivalent, est décrit comme un problème d'optimisation. Au début de chaque session, l'agent LLM charge ce fichier en entier, et chacun de ses tokens est payé à nouveau à chaque tour suivant. Les auteurs prouvent une borne supérieure de la taille optimale du fichier, et cette borne ne dépend pas du nombre d'instructions candidates disponibles. Quel que soit le nombre de règles accumulées par une équipe, elles aident jusqu'à une certaine taille, au-delà de laquelle le fichier ne fait que nuire.

En pratique, ces fichiers grossissent généralement par ajouts successifs. L'agent se trompe, quelqu'un ajoute une ligne. Six mois plus tard, le fichier compte des centaines de lignes et personne ne sait lesquelles fonctionnent.

Le modèle : le fichier comme une étagère à attention limitée

Les auteurs formulent la curation comme un capacitated assortment problem, c'est-à-dire un problème de choix d'assortiment à capacité limitée. Les instructions occupent des tokens, et l'attention du modèle est finie. Ajouter une instruction n'augmente jamais la probabilité d'exécution des autres : elle ne peut que la réduire. Chaque instruction conservée dans le fichier a en outre un coût de maintenance par session.

Ces hypothèses débouchent sur deux résultats :

• Le fichier optimal a un plafond de taille, indépendant du nombre de candidats.
• La stratégie « ajouter tout ce qui est utile pris isolément » peut, en gain net, être arbitrairement moins bonne que le sous-ensemble optimal.
• Un budget de tokens plafonne les pertes, même si le coût du token a été sous-estimé.

Le dernier point est d'ordre pratique. Il est difficile de calculer le prix exact d'un token dans une boucle d'agent, mais une limite stricte sur la taille du fichier protège contre une erreur grossière.

Un retour d'information censuré

La seconde partie du travail porte sur l'apprentissage à partir des sessions passées, et c'est là qu'apparaît un biais dans les données. On peut observer l'utilité et la nocivité des instructions chargées. Une instruction absente ne laisse de trace que si son absence a provoqué une erreur. Si la règle n'existe pas et que tout s'est bien passé, on ne peut rien apprendre sur cette règle. C'est ce qu'on appelle la censure.

Il en découle une conclusion gênante. Si l'on supprime les instructions que l'agent ignore, on supprimera inévitablement aussi des instructions utiles. L'absence d'effet visible dans les logs ne prouve pas qu'une règle est inutile.

Les auteurs déterminent aussi combien de preuves il faut collecter avant d'ajouter une nouvelle instruction. Ils évaluent par ailleurs le regret dans le cas où les relecteurs humains ne parviennent à vérifier qu'un nombre limité de modifications par période. Cela reflète un processus réel : un curateur automatique propose des changements, et l'humain est physiquement incapable de tous les examiner.

Ce que montrent les expériences

La partie empirique est décrite brièvement dans le résumé. Des règles non pertinentes, tirées de vrais fichiers de contexte, dégradent l'exécution des instructions par le modèle de langage. Cela concorde avec la théorie, mais le résumé ne donne aucun chiffre précis. Les modèles testés et l'ampleur de la baisse de précision ne ressortiront que du texte intégral. Les résultats restent préliminaires : il s'agit de la première version du preprint, sans relecture par les pairs.

Comment l'appliquer dès maintenant

Pour les équipes qui maintiennent AGENTS.md, CLAUDE.md ou des fichiers similaires, ce travail suggère plusieurs règles :

• Fixez une limite stricte de taille du fichier et discutez explicitement tout dépassement.
• N'ajoutez une nouvelle règle qu'après plusieurs échecs répétés, pas dès le premier.
• Ne supprimez pas une règle simplement parce que l'agent « n'y réagit pas » : vérifiez d'abord si elle n'empêche pas des erreurs silencieuses.
• Reconstruisez périodiquement le fichier à partir d'un sous-ensemble des meilleures règles et comparez-le à la version actuelle sur des tâches réelles.
• Faites passer les modifications automatiques en relecture par petits lots, en tenant compte de l'attention limitée des relecteurs.

Il s'agit d'un travail théorique, et ses conclusions reposent sur les hypothèses du modèle, par exemple sur le fait qu'une nouvelle instruction n'augmente pas l'exécution des autres. Mais face à l'habitude d'ajouter indéfiniment des lignes au fichier de l'agent, il fournit un argument formel contraire.