Il y a trois ans, la « mémoire des agents » se résumait à empiler l'historique de conversation dans une fenêtre de contexte en espérant que ça tienne. En 2026, le sujet a sa propre suite de bancs d'essai, sa propre littérature de recherche et un écart mesurable entre les approches. Voici une note de terrain sur ce à quoi la mémoire des agents ressemble réellement aujourd'hui, et pourquoi c'est le problème de retrieval que vous avez oublié d'instrumenter.
Une fenêtre de contexte plus grande n'est pas une mémoire.
La réponse réflexe à « mon agent oublie des choses » a été « utilise un modèle avec une fenêtre de contexte plus longue ». C'est la mauvaise réponse, et la raison est maintenant bien mesurée. Entasser tout l'historique d'une interaction dans le contexte produit un phénomène que la littérature a nommé : la dégradation du contexte. À mesure que le contexte grossit, la capacité du modèle à utiliser un élément précis se détériore, non pas parce que l'information est absente, mais parce qu'elle est enfouie dans du bruit que le mécanisme d'attention doit traverser.
Les deux courbes résument tout l'argument. Vider tout l'historique dans le contexte (rose) commence fort puis se détériore à mesure que la fenêtre se remplit, parce que le modèle est forcé de tout regarder en même temps. Une couche de mémoire structurée qui ne récupère que les faits pertinents (lime) reste à peu près stable de 8K à plus de 1M de tokens. L'information n'a jamais manqué ; elle était enfouie.
Ça devrait vous sembler familier si vous avez lu nos notes sur le chunking et le retrieval hybride. La mémoire est un problème de retrieval, avec deux différences qui le rendent plus difficile. Premièrement, le corpus est écrit par l'agent lui-même, en temps réel, à mesure que l'interaction se déroule. Deuxièmement, le corpus change : des faits sont remplacés, des préférences se mettent à jour, des conclusions antérieures sont invalidées. Vous récupérez dans un magasin qui se réécrit activement. C'est pour ça qu'elle mérite sa propre discipline.
La mémoire est une boucle écrire, gérer, lire.
La littérature de synthèse de 2026 converge vers une formalisation propre : la mémoire des agents est une boucle étroitement couplée à la perception et à l'action. L'agent écrit des mémoires à mesure qu'il agit, les gère dans le temps (compression, mise à jour, suppression), et les relit quand c'est pertinent. Chaque étape est un problème d'ingénierie distinct avec des modes d'échec distincts.
Les cadres les plus pertinents pour la production exposent maintenant cette boucle comme un ensemble d'opérations explicites. Une approche représentative traite cinq opérations de mémoire, stocker, récupérer, mettre à jour, résumer et supprimer, comme des outils appelables dans la politique de l'agent, puis optimise tout le pipeline par apprentissage par renforcement. C'est un changement de fond : la gestion de la mémoire cesse d'être un pipeline fixe et devient un comportement appris que l'agent améliore.
- stocker
Écrire un nouveau fait. La subtilité sous-estimée : les faits générés par l'agent (ses propres confirmations, recommandations, conclusions) doivent être stockés avec le même poids que les faits énoncés par l'utilisateur. Les systèmes qui ne stockaient que l'entrée utilisateur avaient un large angle mort.
l'angle mort - récupérer
Lire les mémoires pertinentes au moment de décider. Les meilleurs systèmes actuels fusionnent trois signaux en parallèle, similarité sémantique, correspondance de mots-clés et correspondance d'entités, plutôt que de se fier à la seule similarité vectorielle. La même leçon que notre note sur le retrieval hybride, appliquée au magasin de mémoire.
multi-signal, pas que vectoriel - mettre à jour
Remplacer un fait périmé. « L'utilisateur habite à Berlin » devient « l'utilisateur a déménagé à Lisbonne ». Se tromper ici produit le pire échec de mémoire : rappeler avec assurance quelque chose qui n'est plus vrai.
le pire mode d'échec - résumer
Compresser une trajectoire en forme durable. L'agent relit ses propres notes après une réinitialisation du contexte et continue. C'est ce qui permet des flux de plusieurs heures et de milliers d'étapes qu'aucune fenêtre de contexte ne pourrait contenir.
survit à une réinitialisation - supprimer
Oublier ce qui ne compte plus. L'opération la moins construite, et sans doute la plus importante pour les agents à long horizon : un magasin de mémoire non borné finit par avoir le même problème de rappel qu'une fenêtre de contexte non bornée.
celle qu'on ne construit pas
Trois types de mémoire. La plupart des agents n'en ont que deux.
En empruntant aux sciences cognitives, la mémoire des agents se divise en trois types. La plupart des systèmes de production implémentent les deux premiers et sautent discrètement le troisième, ce qui est une erreur, parce que c'est là que vit la compétence durable de l'agent.
| type | question | ce qu'elle contient | exemple |
|---|---|---|---|
| Épisodique | ce qui s'est passé | Des traces d'événements et d'interactions précis : la conversation de mardi dernier, le bogue corrigé hier. | « L'utilisateur a signalé que l'export échouait vendredi. » |
| Sémantique | ce qui est su | Des faits durables abstraits des événements : préférences, configuration, vérités stables qui persistent entre les sessions. | « L'utilisateur préfère Python. L'équipe déploie le vendredi. » |
| Procédurale | comment on fait les choses | Des workflows et conventions appris : comment cette équipe structure ses PR, quels tests roulent avant le merge. Appliqués de façon constante. | « Rouler le lint et les tests d'intégration avant d'ouvrir une PR ici. » |
La mémoire épisodique et sémantique est bien servie par les approches vectorielles et de liaison d'entités actuelles. La mémoire procédurale est la frontière. Un agent de codage qui a appris comment votre équipe travaille, ses conventions, ses habitudes d'outillage, ses normes de revue, est nettement plus utile qu'un agent qui les redérive à chaque session. L'outillage pour gérer spécifiquement la mémoire procédurale est encore jeune, et c'est le domaine le plus susceptible de différencier les produits d'agents au cours de la prochaine année. C'est aussi le type le plus directement lié au harnais d'évaluation de notre note sur la suite d'éval en 6 lignes : la mémoire procédurale est, en effet, l'agent qui apprend les conventions que vos tests encodent.
On peut enfin mesurer ça.
Le plus grand développement, c'est que la qualité de la mémoire a cessé d'être autodéclarée. Trois bancs d'essai définissent maintenant le paysage, et ils mesurent des choses progressivement plus difficiles. C'est le même arc de maturation que le retrieval a connu : l'évaluation ad hoc a cédé la place à des bancs d'essai reproductibles et inter-laboratoires, et le domaine est devenu sérieux du jour au lendemain.
| banc d'essai | échelle | tests | pourquoi ça compte |
|---|---|---|---|
| LoCoMo | 1 540 Q | Rappel à un saut, à plusieurs sauts, en domaine ouvert et temporel à travers des conversations multi-sessions. | Le premier standard reproductible inter-laboratoires. Avant lui, la qualité de la mémoire relevait de l'anecdote. |
| LongMemEval | 500 Q | Mise à jour des connaissances, raisonnement temporel, rappel multi-sessions et rappel de préférences. | Exigeant sur les cas difficiles : mettre à jour des connaissances périmées et raisonner dans le temps. |
| BEAM | 1 M–10 M tokens | Dix catégories dont la résolution de contradictions, l'ordonnancement d'événements et l'abstention. | Insoluble en agrandissant la fenêtre de contexte. Le banc d'essai à l'échelle de la production. |
Surtout, l'évaluation est multidimensionnelle. Bien marquer en précision ne suffit pas : les bancs d'essai suivent aussi la consommation de tokens par requête et la latence. C'est la partie qui compte pour la production. Un système qui obtient 95 % de rappel mais brûle 26 000 tokens par requête n'est pas viable. Les meilleurs résultats actuels atteignent environ 92–94 % de précision sur les bancs d'essai conversationnels à environ 6 900 tokens par requête, un gain d'efficacité de 4× sur les approches naïves à contexte complet, à précision comparable ou meilleure. Les deux vont ensemble, et c'est tout l'enjeu.
Ce cadrage de l'efficacité en tokens se rattache directement à notre note sur faire du coût une métrique prioritaire. Chaque récupération de mémoire, ce sont des tokens injectés dans un appel de modèle, et ces tokens coûtent de l'argent à chaque invocation. Une couche de mémoire qui récupère 26 000 tokens quand 6 900 suffiraient n'est pas seulement plus lente, c'est une ligne sur la trace de coûts. Quand vous évaluez une approche de mémoire, le nombre de tokens par requête appartient au même tableau de bord que votre coût par étape.
Le design d'API qui s'est imposé.
Un patron de conception s'est imposé comme le standard de facto pour la mémoire en production : la mémoire multi-portée. Chaque écriture de mémoire est associée à une ou plusieurs portées, et ces portées se composent au moment de la récupération. C'est une petite idée qui règle un nombre surprenant de vrais problèmes.
# Quatre portées qui se composent : le patron devenu standard memory.add( "User prefers dark mode and terse responses", user_id="u_8821", # persiste sur TOUTES les sessions ) memory.add( "This run is debugging the payment webhook", user_id="u_8821", run_id="r_4f2a", # limité à CETTE exécution seulement ) memory.add( "Org policy: never auto-deploy on Fridays", org_id="acme", # partagé dans toute l'organisation ) # Les portées se composent à la lecture : on fusionne et on classe results = memory.search( "how should I handle this deploy?", user_id="u_8821", run_id="r_4f2a", org_id="acme", ) # renvoie la politique org + la préférence utilisateur + le contexte, # classés : mémoires utilisateur > contexte de session > historique brut
Les quatre portées, user_id, agent_id, run_id et org_id, répondent à deux questions sur chaque fait : à qui appartient cette mémoire, et combien de temps vit-elle. Un fait sur l'utilisateur persiste pour toujours ; un fait sur cette exécution meurt avec l'exécution ; une politique d'organisation s'applique à tous. Le pipeline de récupération les fusionne automatiquement et classe les mémoires utilisateur au-dessus du contexte de session au-dessus de l'historique brut.
Deux leçons de production sont sorties du travail sur les portées. D'abord, écritures asynchrones par défaut : les écritures de mémoire qui bloquent le pipeline de réponse ajoutent une latence que l'utilisateur ressent directement, et c'était le piège de production le plus fréquent. Ensuite, pour les systèmes multi-agents, mémoire consciente de l'acteur : dans une conversation partagée, « l'utilisateur a besoin d'aide pour le déploiement » est ambigu, parce que l'utilisateur l'a peut-être dit ou un agent de surveillance l'a peut-être inféré. La provenance dans la couche de mémoire (stocker qui a généré chaque mémoire) devient une question de fiabilité, pas seulement de débogage. C'est le même souci de provenance que le travail d'ancrage de notre note sur la qualité des agents service client : une mémoire que vous ne pouvez pas attribuer est une mémoire à laquelle vous ne pouvez pas vous fier.
Ce qui reste vraiment non résolu.
Le domaine a mûri vite, mais les problèmes qui restent sont réels. Ils sont précis et bornés plutôt que fondamentaux, ce qui est bon signe, mais aucun n'a encore de réponse propre.
- Identité inter-sessions
Savoir de façon fiable que l'utilisateur de cette session est la même personne qu'un utilisateur d'il y a trois semaines, à travers les appareils et les contextes, sans jointure d'identité externe fragile. L'isolation de la mémoire en dépend, et c'est plus difficile qu'il n'y paraît.
toujours ouvert - Abstraction temporelle à l'échelle
Raisonner correctement sur quand des faits étaient vrais et dans quel ordre, à travers des millions de mémoires. « L'utilisateur préférait X, puis est passé à Y » exige que le système modélise le temps, pas seulement qu'il stocke des horodatages.
toujours ouvert - Péremption de la mémoire
Savoir quand un fait stocké a péri en silence. Une préférence d'il y a un an peut tenir ou non. Sans modèle de péremption, le système rappelle avec assurance des choses qui ne sont plus vraies.
toujours ouvert
Cette dernière devrait faire tilt. La fenêtre de retour hallucinée dans notre note sur la qualité des agents service client était un échec de péremption : l'agent a récupéré un vrai fait qui avait été remplacé. La péremption de la mémoire est ce même problème, généralisé. Tout magasin de mémoire à longue durée de vie accumule des faits qui cessent discrètement d'être vrais, et détecter ça automatiquement reste non résolu.
Traitez la mémoire comme vous traitez le retrieval.
Le constat pratique, c'est que la mémoire a franchi le seuil entre « curiosité de recherche » et « décision d'ingénierie de production que vous devez prendre délibérément ». Vous pouvez câbler une mémoire persistante dans un agent en un après-midi : l'écosystème couvre maintenant 21 cadres et 20 bases vectorielles, et la surface d'intégration est la partie du domaine qui croît le plus vite. Le difficile n'est pas la plomberie. C'est de faire les bons choix d'architecture.
Le point de fond : cette série a consacré beaucoup de mots au retrieval, stratégies de chunking, recherche hybride, choix de base vectorielle. La mémoire est le même problème sous un autre chapeau. Le corpus est simplement un corpus que l'agent s'écrit à lui-même, en temps réel, et qu'il réécrit sans cesse. Tout ce que vous avez appris sur la récupération dans des documents s'applique, plus les problèmes véritablement nouveaux d'écrire, de mettre à jour et d'oublier. Ces nouveaux problèmes sont exactement pourquoi la mémoire a gagné sa propre discipline en 2026.
Si vous voulez un deuxième regard sur la façon dont une couche de mémoire structurée changerait votre pile d'agents actuelle, le formulaire de contact est la voie la plus rapide. Nous faisons des revues de 30 minutes pour les piles d'agents en production, gratuitement.