Un paper sur arXiv nomme un problème que les utilisateurs d’agents en production rencontrent chaque jour : la gestion du contexte. Le contexte d’un agent, composé de l’historique de la conversation, des définitions des outils et des outputs des tools, s’accumule tour après tour. Le coût en tokens croît de manière quadratique par rapport à la longueur de la session, et l’agent perd des informations juste quand elles seraient nécessaires.

Gaurav Dadhich définit cette discipline Agentic Context Management (ACM) et la décompose en cinq primitives : architecture, ingestion, scoping, anticipation et compaction. La thèse centrale est que le contexte doit être traité comme un cycle de vie. On décide quoi se souvenir, on le structure, on choisit le bon stockage pour chaque type de donnée, on consolide et on oublie en préservant la traçabilité, on anticipe ce qui servira au tour suivant et on compacte dans un budget sans perdre ce qui compte.

Pourquoi ça vous concerne. Si vous avez vu un agent se dégrader après vingt tours ou payé une facture API disproportionnée pour une session qui aurait pu se terminer en cinq étapes, le paper offre un cadre pour comprendre où ça casse. C’est le même pattern qu’Anthropic publie parmi ses recettes internes pour les agents et que le playbook De chat interminable à nouvelle session vous fait appliquer aujourd’hui, même sans infrastructure.

En détail

Ce qu’il y avait avant.

L’approche dominante de la mémoire des agents est la RAG : vous sauvegardez les données dans une base de données vectorielle et les récupérez avec une recherche par similarité quand vous en avez besoin. Ça marche pour les documents statiques, mais ça s’effondre quand le « document » est la conversation elle-même, qui croît et change à chaque tour. Le paper part de là : traiter la mémoire comme du stockage et de la récupération est trop limité.

Le cadre proposé.

ACM traite le contexte comme un cycle de vie avec cinq phases :

1. Architecture : décider de la structure de la mémoire avant de commencer. Quels types de données vont où (historique court en contexte, faits consolidés dans un store structuré, outputs bruts dans une archive séparée).
2. Ingestion : extraire et structurer ce qui vaut la peine d’être mémorisé, au lieu de tout sauvegarder.
3. Scoping : filtrer par pertinence et par domaine organisationnel. Un agent en production sert une hiérarchie de domaines (personnel, équipe, organisation), car le contexte pertinent pour un utilisateur peut être inutile ou nuisible pour un autre.
4. Anticipation : prévoir ce qui servira au tour suivant et en préparer la récupération, plutôt que d’attendre la demande explicite.
5. Compaction : réduire le contexte à un budget prédéfini sans perdre ce qui compte. C’est la phase la plus délicate, car c’est là que se joue le compromis entre coût et exactitude.

L’argument économique.

L’argument le plus utile du paper est la mathématique du coût. Si vous accumulez du contexte sans le gérer, le coût en tokens croît quadratiquement : chaque tour relit toute l’historique. Si vous résumez brutalement à la fin du tour, le coût devient linéaire mais l’exactitude s’effondre au-delà d’un certain point, ce que le paper appelle la accuracy cliff. La compaction validée, en revanche, maintient le coût linéaire et préserve la fidélité, car elle choisit quoi compresser en fonction de ce qui sert vraiment.

Pour ceux qui ne construisent pas d’infrastructure, la leçon pratique est simple : de temps en temps, vous devez compacter le contexte d’un agent, mais avec discernement. Un résumé aveugle coupe tout de la même manière et perd les détails qui importent.

Les chiffres.

L’implémentation de référence, Maximem Synap, affiche 92% sur LongMemEval et 93,2% sur LoCoMo (données déclarées dans le paper, section 6, juillet 2026). Ce sont des benchmarks de mémoire longue qui évaluent si un agent se souvient d’informations à travers des conversations étendues. Les chiffres sont de l’auteur, sur des configurations spécifiques. Le code et les données d’évaluation sont liés dans le paper, mais une réplication indépendante n’est pas encore disponible.

Limites.

Le paper est une proposition de cadre, avec une implémentation de référence à l’appui. Les benchmarks mesurent l’exactitude du rappel, mais le paper lui-même signale ce que les benchmarks actuels ne capturent pas : latence, efficacité des tokens et résistance à la dégradation du contexte dans le temps. Le saut entre une implémentation de référence et un système multi-tenant en production est important, et le paper le reconnaît. Pour le lecteur, la valeur principale réside dans le vocabulaire et le cadre : avoir un nom pour les cinq phases aide à raisonner sur l’endroit où votre agent casse, même sans implémenter Maximem Synap.