L’essentiel
- Meta AI décrit un défaut propre aux agents lancés sur des tâches longues : l’information reste présente dans le contexte, mais elle ne guide plus les décisions.
- La parade proposée est un second agent, dédié à la mémoire, qui tient un carnet structuré et décide à chaque contrôle s’il glisse un rappel ou s’il se tait.
- Le taux de réussite au premier essai passe de 38 à 46 % sur Terminal-Bench 2.0, et la moyenne pondérée de 55 à 62 % sur tau2-Bench.
L’agent tape une commande, elle échoue. Trente étapes plus tôt, il avait déjà tenté la même, sans plus de succès, et cet échec figure noir sur blanc dans l’historique qu’il a sous les yeux. Une équipe de Meta AI a mis un nom sur ce trou de mémoire qui n’en est pas un, et propose une parade à contre-courant : adjoindre à l’agent un second agent dont le seul métier est de se souvenir.
L’information est encore là, elle ne décide plus rien
Les auteurs appellent le phénomène la « dégradation de l’état comportemental » (behavioral state decay). Au fil d’une tâche longue, l’état qui oriente les décisions de l’agent se disperse dans un historique qui gonfle. Il s’enfouit au fond de la fenêtre de contexte, quand il n’en sort pas purement et simplement.
Meta AI insiste sur un point précis : même quand l’information reste présente dans la transcription, elle ne pèse plus de façon fiable sur le comportement. Allonger l’historique ne règle donc rien, car une fenêtre de contexte est un espace de stockage, pas un organe d’attention.
Les systèmes de mémoire existants savent stocker, mettre à jour et retrouver, ce qui fonctionne bien pour la personnalisation ou le rappel d’une session à l’autre. Anthropic propose par exemple un outil de mémoire couplé à une édition automatique du contexte : l’agent écrit ce qu’il apprend dans des fichiers et les relit quand il en a besoin. Le geste reste à sa charge. Un agent en cours d’exécution, lui, doit trancher autre chose : ce souvenir mérite-t-il d’être ramené maintenant ?
Un carnet de bord en trois cases
Le dispositif associe un « agent d’action » laissé tel quel et un « agent de mémoire » séparé. À intervalles fixes, ce dernier relit une fenêtre glissante des dernières étapes et met à jour une banque de mémoire structurée. Puis il décide s’il ajoute un rappel court au prochain appel de l’agent d’action.
Cette banque compte trois sections. Un champ de statut privé suit l’avancement et les risques en suspens, sans jamais être montré à l’agent d’action. La Knowledge Memory conserve les faits stables : exigences, chemins de fichiers, configurations. La Procedural Memory garde la trace de ce qui a été tenté et de ce qui en est sorti, des commandes en échec aux correctifs qui ont fonctionné, en passant par les hypothèses écartées.
Un détail compte plus qu’il n’y paraît : l’agent de mémoire ne réécrit pas librement son carnet. Il ne peut le modifier qu’à travers des appels d’outils prédéfinis. La première phase met à jour la banque, la seconde décide si un état stocké doit peser sur le prochain coup de l’agent d’action.
Le souffleur qui sait se taire
L’image la plus juste est celle du souffleur de théâtre. Il suit la pièce, connaît le texte, et sa compétence principale consiste à ne rien dire tant que le comédien n’en a pas besoin. Trop peu de rappels, l’agent refait les mêmes erreurs. Trop de rappels, on ajoute de la latence, on consomme des tokens et on détourne l’agent de ce qu’il est en train de faire.
C’est ce qui sépare ce module d’un simple résumeur. Un résumeur choisit ce qu’il conserve ; ce système choisit si un état d’exécution doit influencer la décision suivante. Comme les modes de défaillance varient énormément d’une tâche à l’autre, une règle de résumé figée ne peut pas trancher à coup sûr. S’abstenir fait partie de la politique, au même titre qu’intervenir.
Les auteurs le présentent comme un module qui se greffe sur des agents existants et sur les environnements qui les exécutent, sans rien y modifier. Il reste volontairement borné : il fournit des rappels tirés de la mémoire, jamais des conseils stratégiques plus larges.
Huit points gagnés sur Terminal-Bench, trois seulement sur les télécoms
Les tests portent sur deux terrains. Terminal-Bench 2.0 évalue des agents autonomes dans des environnements en ligne de commande réalistes. tau2-Bench mesure l’usage conversationnel d’outils dans l’aérien, le commerce de détail et les télécoms. Claude Opus 4.6 tenait le rôle de l’agent de mémoire, Claude Sonnet 4.5, plus ancien, celui de l’agent d’action.
Sur Terminal-Bench, 46 % des tâches sont résolues au premier essai, contre 38 % pour la version de référence. Sur tau2-Bench, la moyenne pondérée par tâche monte de 55 à 62 %. Les gains ne se répartissent pas uniformément : environ dix points sur l’aérien et sur le commerce de détail, trois points seulement sur les télécoms.
Cette dispersion est peut-être la donnée la plus instructive du lot. Elle suggère que le procédé paie là où l’état s’accumule sur de longues chaînes d’actions, et beaucoup moins là où la tâche se règle en quelques tours. Une réserve s’impose : l’agent de mémoire tournait sur un modèle plus capable que l’agent d’action, et la publication ne permet pas de faire la part entre l’architecture elle-même et cette intelligence ajoutée par-dessus.
Une couche de supervision à la portée de n’importe quelle équipe
Ces huit points ne viennent d’aucun réentraînement ni d’aucun changement de modèle : ils viennent d’une couche de supervision posée à côté. Le levier se déplace vers ce qui entoure le modèle, c’est-à-dire vers la seule partie du système sur laquelle un praticien garde la main.
Deux paramètres méritent votre attention si vous tentez l’expérience : la fréquence des contrôles et la taille de la fenêtre glissante. Ils arbitrent directement entre fiabilité et coût, puisque chaque contrôle est un appel de modèle supplémentaire. Un agent qui se relit toutes les trois étapes coûte cher ; un agent qui se relit trop rarement a déjà oublié ce qu’il devait retenir.
Le travail ouvre d’ailleurs une piste plus large. Si la mémoire mérite son propre agent, la planification, la vérification du travail rendu ou la tenue du budget, aujourd’hui empilées dans un même prompt, méritent probablement le leur.
Mon avis
On a passé deux ans à espérer que des fenêtres de contexte toujours plus larges règlent la mémoire des agents, et ce papier acte poliment que non. La fiabilité redevient un problème d’ingénierie, donc un problème attaquable avec un budget normal et sans laboratoire de recherche : c’est la meilleure nouvelle de l’été pour les équipes qui bricolent leurs propres agents. Je m’attends à voir ce type de module de mémoire devenir une case à cocher dans les frameworks d’agents avant la fin de l’année. Le test qui m’intéresse n’a pas encore été mené : la même architecture pilotée par un petit modèle bon marché, pour savoir si le gain vient du mécanisme ou de la puissance qu’on a posée au-dessus.
