Le problème qu’on voit après le dixième appel

T’as déjà vu un agent qui fait ce qu’il faut les trois premières actions, puis à la sixième oublie une contrainte que tu lui avais donnée au début et se trompe ? Ça arrive quand la tâche s’étire : les exigences initiales, les tentatives échouées, les sous-objectifs ouverts finissent enfouis dans l’historique ou au-delà de la limite de la fenêtre de contexte. L’agent agit seulement sur ce qu’il voit dans les dernières lignes, et perd l’état décisionnel qui compte.

Le paper appelle ce problème behavioral state decay, la dégradation de l’état comportemental : les informations pertinentes existent quelque part dans la trajectoire, mais l’agent ne les remonte pas à la surface quand il doit décider.

Pourquoi ça te touche

Si tu construis un agent pour des tâches qui durent plus que quelques appels, tu rencontres le problème immédiatement. Un débogage système qui demande dix commandes, une analyse qui passe par plusieurs fichiers, une configuration avec des dépendances à respecter : chaque fois que la trajectoire s’allonge, l’état pertinent se disperse. Aujourd’hui, la solution la plus courante est de tout pousser dans le prompt système ou de résumer périodiquement à la main, mais aucune des deux ne scale bien.

Le paper propose une mémoire active qui n’attend pas d’être interrogée : un agent séparé qui observe la trajectoire récente, met à jour une mémoire structurée et décide autonomiquement s’il faut injecter un rappel à l’agent d’action ou rester silencieux. Le module se connecte à un agent existant sans le modifier, et fonctionne avec les frameworks déjà en place.

Si tu as un agent qui perd des pièces sur des tâches longues, cette architecture te donne un point de départ concret.

Ce que dit le paper

Les auteurs ont construit un memory agent qui tourne en parallèle de l’action agent (l’agent qui décide les actions). À chaque étape :

1. Il reçoit la trajectoire récente (dernières actions, observations, outputs)
2. Il décide s’il faut mettre à jour la mémoire structurée (un dictionnaire avec des clés comme task_requirements, environment_facts, failed_attempts, diagnoses, open_subgoals)
3. Il décide s’il faut injecter un rappel textuel à l’action agent ou le laisser travailler sans intervention

La mémoire n’est pas une base de données passive à interroger : l’agent de mémoire choisit quand intervenir, et le fait seulement s’il estime que l’état pertinent n’est pas déjà visible à l’action agent.

Ils l’ont testé sur deux benchmarks :

• Terminal-Bench 2.0 : tâches de terminal Linux qui demandent des séquences longues (configurations système, débogage multi-étapes)
• τ²-Bench : tâches sur des interfaces web et applications de bureau, où l’agent doit mémoriser les objectifs à travers plusieurs pages

Résultats sur pass@1 (pourcentage de tâches complétées au premier essai) :

• Terminal-Bench : +8,3 points de pourcentage avec l’agent de mémoire par rapport à l’action agent seul (pour les agents plus faibles comme plus forts)
• τ²-Bench : +6,8 points de pourcentage

Les auteurs ont comparé cinq variantes :

1. Memory agent proactif (celui proposé) : injecte des rappels seulement quand il décide que c’est utile
2. Bank exposé passivement : l’action agent voit toujours l’état complet de la mémoire
3. Injection continue : chaque mise à jour est injectée, toujours
4. Advisor-only : l’agent de mémoire propose des actions, ne gère pas l’état
5. Retrieval générique : récupère les informations sur demande, comme un RAG

L’intervention sélective bât toutes les alternatives. Injecter en continu crée du bruit, exposer tout passivement ne garantit pas que l’action agent l’utilise au bon moment, et le retrieval sur demande demande que l’agent sache quoi chercher.

Comme preuve de concept pour une politique de mémoire open-weight, ils ont entraîné Qwen3.5-27B sur un dataset appelé SETA avec du fine-tuning supervisé et GRPO (un algorithme de reinforcement learning). Le modèle s’améliore sur la validation et montre un transfert partiel sur Terminal-Bench, mais reste une expérience préliminaire.

À quel point en être sûr

Ce paper s’appuie sur des abstraits et des informations de la page arXiv : le PDF complet n’était pas accessible. Ce qu’on sait :

• Les améliorations sont mesurées sur deux benchmarks spécifiques (Terminal-Bench 2.0 et τ²-Bench), qui couvrent des tâches de terminal et des interfaces graphiques, mais ne représentent pas tous les compits longs possibles. Les gains sur d’autres domaines restent à vérifier.
• L’architecture est plug-and-play avec des agents existants, mais demande un second agent LLM qui tourne en parallèle : il y a un coût computationnel et de latence. Le paper ne rapporte pas combien d’appels supplémentaires sont nécessaires par tâche, ni le temps total d’exécution.
• L’entraînement d’une politique de mémoire open-weight (Qwen3.5-27B) est décrit comme une étape préliminaire avec transfert partiel, pas comme une solution prête à l’emploi.
• Les ablations montrent que l’intervention sélective bât les alternatives testées, mais on ignore combien dépend de la qualité du prompting de l’agent de mémoire : une politique plus simple pourrait marcher aussi bien.
• Il n’est pas clair comment scale la bank de mémoire quand les tâches durent des dizaines ou centaines d’étapes : à un moment donné, même la mémoire structurée se remplit.

En résumé : les résultats sur les benchmarks sont solides, l’idée est claire et testable, mais les détails d’implémentation et les limites pratiques demandent le paper complet pour être évalués complètement.

Qu’en faire

Si tu construis un agent sur des tâches qui durent plus de cinq ou dix étapes et que tu vois qu’il perd les informations pertinentes, essaie cette architecture :

1. Ajoute un second agent qui observe la trajectoire récente et maintient un dictionnaire d’état (exigences de la tâche, faits sur l’environnement, tentatives échouées, sous-objectifs ouverts).
2. Donne-lui une politique d’intervention simple : injecte un rappel seulement si tu vois que l’action agent va violer une contrainte ou répéter une erreur, sinon reste silencieux.
3. Teste avec et sans : mesure le pass@1 sur tes tâches. Si ça ne s’améliore pas, le problème n’est pas la mémoire distribuée, c’est autre chose (prompt initial peu clair, observations ambigües, environment trop instable).

L’erreur à éviter : croire qu’il suffit d’exposer un log complet à l’action agent. Le paper montre que l’intervention active sélective bât l’exposition passive de la mémoire, parce qu’elle réduit la charge cognitive et injecte les informations seulement quand elles comptent.

Une autre implication : si ton agent utilise du retrieval (genre RAG sur de la documentation), la mémoire proactive est complémentaire, pas alternative : le retrieval récupère la connaissance statique sur demande, la mémoire garde l’état décisionnel de la tâche en cours et l’injecte sans attendre d’être cherchée.

Où approfondir

Sur le site :

• Leçon “État et mémoire dans les agents” (pas encore publiée, en roadmap builder) : comment les agents gardent trace du contexte dans les tâches multi-étapes
• Scaffolding “Architecture à deux agents” (à créer) : schéma de base pour séparer l’agent d’action de l’agent de supervision

En dehors du site :

• Paper sur arXiv
• Terminal-Bench et τ²-Bench (cherche les repos officiels pour les tâches de référence)