Le contexte est la nouvelle contrainte pour les créateurs d'agents

Le signal le plus utile de la recherche sur les agents cette semaine ne concerne ni des modèles plus gros ni des fenêtres de contexte plus longues. Il s'agit du contexte comme contrainte que l'on peut gérer activement. Trois évolutions distinctes pointent dans la même direction : les agents obtiennent de meilleurs résultats quand leur mémoire de travail est délibérément façonnée, et pas seulement étendue.

La présentation d'Anthropic à l'AI Engineer New York a abordé la coordination des agents avec des concepts empruntés à Unix et Linux [1]. La leçon n'est pas que les agents devraient imiter littéralement les systèmes d'exploitation, mais que les développeurs ont besoin de primitives pour contrôler ce qu'un agent voit, quand il le voit et ce qu'il conserve. Un processus ne garde pas tout son historique d'exécution en mémoire. Il lit ce dont il a besoin, écrit ce qui compte et laisse tomber le reste. Les créateurs d'agents commencent à appliquer la même discipline.

Des chercheurs de Microsoft ont identifié un mode de défaillance concret que cette discipline permet de traiter. Les agents autonomes se retrouvent piégés dans des « bassins d'idées » — des régions de solutions locales dont ils ne peuvent pas sortir parce que leur historique de conversation qui s'allonge les ancre à des raisonnements antérieurs [2]. La solution qu'ils ont testée, appelée Fork-and-Flush, efface l'historique de conversation tout en préservant l'espace de travail. Résultat : jusqu'à 66 % de meilleurs résultats avec le même budget de calcul. Ce chiffre est important car il isole la gestion du contexte comme variable. Le modèle n'a pas changé. La tâche n'a pas changé. Seule la relation de l'agent à son propre historique a changé.

Le contexte est une surface de conception

Pour les développeurs, cela remet en question une hypothèse courante. Beaucoup d'équipes traitent le contexte comme un problème de stockage : combien peut-on en faire tenir, comment le compresser, comment récupérer le bon fragment. Ce sont de vraies questions, mais elles passent à côté de la plus fondamentale : qu'est-ce que l'agent devrait avoir le droit de mémoriser, tout simplement ?

Fork-and-Flush fonctionne parce qu'il traite l'oubli comme une fonctionnalité. L'agent conserve ses artefacts — l'espace de travail, le code, la solution partielle — mais abandonne la trace de raisonnement qui y a mené. Cette trace de raisonnement n'est pas neutre. Elle transporte des hypothèses, des impasses et des cadrages précoces qui contraignent l'exploration ultérieure. L'effacer n'est pas de l'amnésie ; c'est un redémarrage contrôlé depuis un état connu.

Les workflows inspirés d'Unix proposés par Anthropic suggèrent le même principe à un niveau supérieur. Sous Unix, de petits programmes communiquent via des interfaces explicites. Ils ne partagent pas de mémoire. Chacun démarre à neuf avec ses entrées et produit des sorties. Quand Anthropic applique cela à la coordination d'agents, l'implication est que les tâches d'agents de longue durée devraient être décomposées en unités plus petites avec des frontières nettes, plutôt qu'exécutées comme une conversation continue [1].

L'isolation change l'évaluation

Le troisième développement concerne la frontière entre un agent et le monde. Anthropic garde ses évaluations internes hors ligne tant qu'elle ne peut pas empêcher les « actions non intentionnelles du modèle » [3]. Ce n'est pas une annonce de sécurité abstraite. C'est un aveu qu'un agent connecté à Internet pendant les tests peut agir de manière difficile à prédire, à tracer ou à annuler.

Pour les développeurs, cela a une conséquence pratique directe. Si vous évaluez des agents dans un environnement où ils peuvent atteindre des systèmes externes, vous ne mesurez pas l'agent. Vous mesurez l'agent plus tout ce qu'il a trouvé, déclenché ou modifié par hasard. L'évaluation hors ligne est une forme de contrôle du contexte : elle supprime une variable que vous ne pouvez pas observer entièrement. La même logique s'applique en production. Un agent qui peut agir sur le monde a besoin d'une frontière que vous contrôlez, pas seulement d'un prompt qui lui demande de bien se comporter.

Ce qui relie ces trois histoires, c'est un déplacement de l'origine de la qualité d'un agent. Elle vient moins de la capacité brute du modèle que de la structure qui l'entoure : ce que l'agent mémorise, ce qu'il oublie, ce qu'il peut toucher et ce qu'il ne peut pas. Les développeurs qui traitent le contexte comme une surface de conception — quelque chose à façonner, réinitialiser et isoler — obtiendront des résultats plus fiables avec les mêmes modèles. Ceux qui le traitent comme un journal passif continueront à se battre contre les mêmes échecs.