Une mémoire oubliée au fond d'une base coûte peu. Dès qu'elle revient dans un prompt, elle rejoint la conversation précédente, les sorties d'outils, les instructions et le message courant dans la même addition en tokens d'entrée. Un agent qui rejoue tout son historique ne paie donc jamais une seule fois pour se souvenir : les mêmes morceaux reviennent sur la facture à chaque tour.

C'est le déplacement le plus utile du papier Agentic Context Management de Gaurav Dadhich.1 L'article propose cinq primitives — architecturer, ingérer, scoper, anticiper, compacter et consolider — mais sa meilleure idée tient dans une distinction plus simple : la mémoire est ce qu'on peut conserver ; le contexte est ce qu'on choisit de faire payer au prochain appel.

IRZ a déjà regardé un autre côté du problème : une mémoire persistante doit pouvoir dire d'où vient une affirmation, si elle est devenue obsolète et ce qui l'a remplacée. Ici, la question arrive juste après. Même un souvenir parfaitement vrai n'a pas forcément besoin d'occuper les prochains milliers de tokens.

Le coût revient

Prenons un agent dont chaque tour ajoute environ t tokens à l'historique. Au premier tour il renvoie t, au deuxième environ 2t, puis 3t, et ainsi de suite. Après N tours, la quantité cumulée d'entrée ressemble donc à :

t × (1 + 2 + ... + N)

La somme croît comme O(N²).1 Rien de spécifique à un framework là-dedans : on obtient cette courbe dès qu'un historique plus long est renvoyé à chaque appel.

Le papier donne un exemple avec 500 tokens nouveaux par tour et une fenêtre bornée à 4 000 tokens. Dans ce modèle comptable, l'historique complet représente environ six fois plus de tokens cumulés à 100 tours et treize fois plus à 200 tours que le contexte borné.1 Ce ne sont pas des factures cloud mesurées : l'exemple ignore notamment les différences de prix par modèle, la génération, les appels d'outils et le coût du système de mémoire lui-même.

Il montre néanmoins pourquoi augmenter la taille maximale d'une fenêtre ne règle pas l'économie du problème. Une fenêtre de deux millions de tokens peut techniquement accepter davantage d'histoire. Elle ne rend pas gratuit le fait de renvoyer cette histoire deux cents fois.

Schéma IRZ montrant un historique persistant, un filtre de contexte puis un appel modèle, avec trois questions coût, utilité et scope.Une donnée peut rester durable sans être réinjectée à chaque tour. Le coût apparaît au passage entre stockage et contexte actif. Analyse IRZ d'après Dadhich, 2026

Trois budgets

Plutôt que d'ajouter une nouvelle expression au dictionnaire déjà bien rempli de l'IA, on peut ramener la « gestion du contexte » à trois budgets très ordinaires.

Le premier est le budget de tokens : combien d'historique, de documentation, de sorties d'outils et de mémoire récupérée peut-on raisonnablement envoyer maintenant ? Le papier de Dadhich s'attarde surtout sur ce coût cumulatif et propose un contexte borné, alimenté par récupération et compaction.1

Le deuxième est un budget d'information. Compacter permet de payer moins parce qu'on élimine des détails. Mais le résumé ne sait pas toujours quel détail deviendra important quinze tours plus tard. Le papier insiste donc sur une compaction validée plutôt que sur un raccourcissement aveugle.1 Son implémentation de référence, Synap, émet selon l'auteur un score de validation, mesure un ratio de compression et peut réessayer lorsqu'un résultat est jugé insuffisant. Le mécanisme interne n'est toutefois pas publié : c'est une description de produit, pas une méthode reproductible ligne par ligne.

Le troisième est un budget d'isolation. Dans une organisation, une information peut être pertinente pour un utilisateur, une équipe ou un client sans devoir devenir une vérité globale. Le papier décrit une hiérarchie de scopes et une couche de connaissances globales.1 Cette architecture réduit le risque de récupérer un souvenir au mauvais niveau, mais elle n'est pas à elle seule une preuve de sécurité ou de contrôle d'accès. Le stockage, les permissions et l'implémentation doivent encore faire leur travail.

Compacter, donc perdre

Avec la compaction, le problème quitte en partie le stockage pour devenir une décision de jugement : que peut-on supprimer maintenant sans regretter ce choix plus tard ?

Si 20 000 tokens doivent rentrer dans 4 000, il faut choisir. On peut supprimer des traces de raisonnement, garder les décisions finales, transformer plusieurs tours en faits structurés ou produire un résumé narratif. Chaque méthode encode une théorie de ce qui sera utile plus tard.

Dadhich modélise une compaction périodique dans une fenêtre bornée : si la fenêtre coûte W, qu'une compaction arrive tous les p tours et qu'elle coûte c × W, le coût cumulé reste linéaire en nombre de tours, N × W × (1 + c/p).1 Avec les paramètres illustratifs du papier, l'économie théorique devient très importante sur les longues conversations.1

La difficulté se déplace alors vers la fidélité. Un résumé peut être excellent pour les cinq questions que vous imaginez aujourd'hui et désastreux pour la sixième que personne n'avait prévue.

Une autre étude publiée en janvier 2026, Active Context Compression, donne à l'agent lui-même un outil pour décider quand consolider puis supprimer son historique brut.4 Sur seulement cinq tâches SWE-bench Lite, cette approche réduit les tokens de 22,7 % au total sans changer le score, trois tâches réussies sur cinq dans les deux configurations.4 Le résultat est intéressant comme prototype de mesure, mais cinq tâches sont évidemment trop peu pour décréter que l'auto-compaction est résolue.

La bonne mesure

MemoryCPT, publié début août, pousse la même question dans une autre direction : son pipeline apprend à construire puis récupérer une mémoire en intégrant explicitement le coût dans son objectif.5 Les auteurs introduisent une métrique de Quality per Cost, plutôt que de comparer uniquement la qualité des réponses.5

Deux systèmes peuvent répondre aussi bien tout en envoyant des quantités de contexte très différentes, alors qu'une mémoire extraordinairement bon marché peut réduire sa facture en oubliant précisément ce qui rendait la réponse correcte. Le compromis se lit donc mieux comme une courbe qui rassemble qualité, quantité de contexte fournie au modèle, coût du travail de mémoire et latence que comme un classement à une seule colonne.

LongMemEval avait déjà montré pourquoi la qualité de mémoire mérite un benchmark spécifique. Ses 500 questions couvrent extraction, raisonnement multi-session, temporalité, mise à jour des connaissances et capacité à s'abstenir.3 Le benchmark a aussi poussé ses auteurs à distinguer les choix d'indexation, de récupération et de lecture plutôt que de traiter la mémoire comme un bloc unique.3

92 %, avec astérisque

Le papier Agentic Context Management rapporte 92,0 % sur LongMemEval et 93,2 % sur LoCoMo pour Synap.12 Le dépôt public de résultats donne 460 bonnes réponses sur 500 pour LongMemEval. La catégorie multi-session est nettement la plus faible, à 75,2 %, tandis que plusieurs catégories atteignent 100 % dans cette configuration.2

Ces chiffres sont utiles sans constituer un classement universel. Le dépôt lui-même prévient que les comparaisons changent avec le modèle qui répond, le juge, les prompts et la granularité d'ingestion.2 Ici, gpt-5-mini sert à la fois de modèle de réponse et de juge, tandis que la catégorie adversariale 5 de LoCoMo est exclue.2

Autre limite : les artefacts détaillés par run — réponses, contexte récupéré, verdicts du juge — sont indiqués comme disponibles sur demande plutôt que tous publiés dans le dépôt.2 La méthodologie et les résultats par catégorie sont donc inspectables, mais on n'est pas face à une reproduction indépendante complète.

Le papier reconnaît également trois dimensions que ces benchmarks ne capturent pas encore correctement : latence de production, efficacité en tokens par tâche et résistance au context rot.1 Ce sont précisément les métriques nécessaires pour valider l'argument économique au-delà de l'algèbre.

Anticiper sans voir

La primitive la plus séduisante du papier est aussi la moins ouverte : l'anticipation. L'idée consiste à récupérer du contexte avant que l'agent ne formule explicitement son besoin, pour qu'une préférence ou une information pertinente soit déjà disponible au bon moment.1

Dadhich rapporte un taux de réussite supérieur à 60 % sur plusieurs clients pour cette anticipation.1 Le mécanisme reste propriétaire et l'article le présente comme un chantier en cours. Ce chiffre doit donc rester au même niveau de preuve que ce qu'il est : une observation rapportée par l'auteur de l'implémentation, pas un benchmark public indépendant.

C'est un bon rappel pour tout le domaine. Les architectures de mémoire ont au moins trois types de phrases à ne pas mélanger :

  • « cette somme croît quadratiquement » peut être vérifié sur une feuille de papier ;
  • « le système obtient 460/500 sur ce benchmark » peut être évalué avec une méthodologie et des artefacts ;
  • « notre anticipation fonctionne dans plus de 60 % des cas en production » dépend d'un système et de données que le lecteur ne voit pas complètement.

Les trois affirmations peuvent être vraies tout en demandant des niveaux de confiance différents, ce qui est précisément la nuance à conserver lorsqu'un papier de recherche décrit aussi le produit de son auteur.

Garder dehors

La conséquence pratique tient presque dans un vide : une mémoire d'agent n'a pas besoin de tout remettre devant le modèle. Avant d'injecter une donnée, le système devrait pouvoir expliquer pourquoi elle entre maintenant, à quel scope elle appartient, combien elle coûte, sous quelle forme elle doit arriver et ce qui se passe quand la fenêtre est pleine. Une information parfaitement sourcée peut rester durablement disponible tout en passant cent tours hors du contexte courant.

C'est la différence avec l'article IRZ précédent sur les preuves de mémoire. Une entrée peut être vraie mais inutile maintenant. Elle peut être pertinente mais trop détaillée. Elle peut être utile à une équipe et dangereusement générale à l'échelle d'un autre client.

Une bonne architecture de contexte ne cherche donc pas le plus gros prompt possible ; elle organise un droit d'entrée temporaire. Le système de mémoire devient intéressant précisément lorsqu'il sait qu'un souvenir existe, qu'il sait où le retrouver, et qu'il choisit malgré tout de le laisser tranquille.