La mémoire de l’agent d’IA n’est pas une base de données : ce qu’il faut conserver, récupérer et oublier.
Pourquoi la mémoire de l’agent constitue un problème de pertinence : en quoi le contexte, la mémoire, l’état et RAG diffèrent, ce qu’il faut stocker, comment définir son champ d’application, gérer son âge et l’auditer, et pourquoi oublier est un avantage.
Sources: AI Agent Memory Is Not a Database
La mémoire des agents d’IA est généralement présentée comme une fonctionnalité qui les rend plus intelligents : se souvenir des conversations passées, des préférences de l’utilisateur, des étapes précédentes du flux de travail, de ce qui a fonctionné la dernière fois, des faits tirés de documents. Le rêve est d’avoir un agent qui connaît tout ce qu’il a jamais vu. C’est là que commence la confusion, car un agent n’a pas besoin de se souvenir de tout, et la mémoire n’est pas identique au stockage des données.
Une base de données peut contenir des millions d’enregistrements sans que aucun d’eux ne fasse partie de la mémoire d’un agent. Les questions techniques sont différentes : qu’est-ce qui doit être mémorisé, et pour combien de temps ? Où cela est-il stocké, quand est-il récupéré, quand est-il supprimé ? Et s’agit-il vraiment de mémoire ? Vu sous cet angle, la mémoire relève moins d’un problème de stockage que d’un problème de pertinence.
Pourquoi l’idée de « conserver tout » échoue
Pensez à un agent chargé d’une tâche de longue durée. Dans la première étape, il apprend l’objectif de l’utilisateur, le document choisi, quelques valeurs extraites, le résultat d’une outil, une décision provisoire et l’issue de la validation. Ensuite vient une autre étape, puis une autre encore, et la pile d’informations s’accroît.
L’implémentation la plus simple consiste à conserver tout cela : ajouter chaque message, stocker chaque résultat d’outil et renvoyer tout le contenu lors de la prochaine requête. Cela fonctionne un certain temps. Puis le contexte s’emballe, les réponses ralentissent, les coûts augmentent, des informations obsolètes commencent à influencer de nouvelles décisions, et des éléments qui n’ont plus d’importance restent encore dans la requête. En pratique, on demande au modèle de déterminer quelles des cinquante informations sont pertinentes en ce moment. À ce stade, la mémoire se transforme en bruit.
Quatre termes souvent confondus
Ces concepts résolvent des problèmes différents, et les conceptions d’agents s’améliorent lorsqu’on les sépare.
Contexte désigne ce que le modèle doit connaître à un moment donné : la demande actuelle, les preuves sélectionnées, quelques décisions antérieures, ainsi que les résultats des outils pertinents. Il est temporaire et sert à l’étape de raisonnement en cours.
Mémoire correspond aux informations que le système pourrait vouloir reprendre plus tard, comme une préférence de l’utilisateur, une décision confirmée par quelqu’un, un résumé utile ou le résultat d’une tâche précédente. Elle peut survivre à une seule invocation du modèle.
État indique où en est le flux de travail. Il peut s’agir d’un statut tel que QUEUED, RUNNING, WAITING_FOR_TOOL, RETRYING ou COMPLETED, ou de flags plus détaillés comme document_extracted = true, analysis_completed = true et report_generated = false. L’état permet au système de continuer ; ce n’est pas une connaissance.
RAG signifie récupérer des connaissances provenant d’une source externe lorsque c’est nécessaire : documents, bases de données, politiques, rapports, wikis internes, entrepôts vectoriels. Ces informations existent déjà ailleurs. L’agent n’a pas besoin de les mémoriser définitivement, seulement de les trouver lorsque c’est requis, ce qui constitue un problème distinct.
Mémoire à court terme
La mémoire à court terme correspond au ensemble de travail. Les personnes qui résolvent un problème gardent certaines informations en tête et les éliminent pour la plupart une fois le travail terminé ; les agents ont le même besoin. Au cours d’un flux de travail, un agent peut utiliser la demande actuelle, le document sélectionné, les résultats récents des outils, les calculs intermédiaires, les décisions antérieures ainsi que l’avancement de la tâche. Tout cela est pertinent maintenant mais peut devenir presque inutile demain. Une bonne définition est l’ensemble minimal d’informations nécessaires pour poursuivre la tâche en cours, et non tout ce qui s’est produit depuis son début.
La mémoire à long terme doit se mériter sa place
La mémoire à long terme correspond à ce que l’on conserve délibérément car cela pourrait être utile à nouveau. On trouve par exemple une préférence exprimée telle que « privilégier des rapports concis », un choix professionnel confirmé comme « utiliser ce format de rapport pour les analyses futures », ou un fait établi tel que « ce projet considère le Système A comme source de vérité ».
Les exigences devraient être plus élevées ici. Avant de stocker quoi que ce soit, demandez-vous s’il est probable qu’il améliore une décision future. Sinon, omettez-le, car la mémoire à long terme comporte un coût en dehors du stockage : chaque élément est quelque chose que le système pourrait par la suite récupérer, considérer comme fiable, maintenir ou interpréter incorrectement.
RAG n’est pas une mémoire à long terme
Disons qu’il y a 20 000 documents internes dans un index vectoriel et que l’agent peut les rechercher. Ce n’est pas de la mémoire de l’agent. Ces documents constituent des connaissances, et RAG est le moyen de les récupérer. L’agent ne devrait pas conserver tous les documents en mémoire, mais seulement savoir comment trouver le bon. Le flux sain consiste à ce que l’agent ait besoin d’informations, recherche la source de connaissances, récupère les éléments pertinents et les utilise. Le flux malsain consiste à copier toutes les connaissances en mémoire. Les connaissances peuvent être énormes, tandis que la mémoire de travail doit rester limitée.
L’état importe souvent plus que la mémoire
Beaucoup de ce que l’on appelle la mémoire de l’agent n’est en réalité que l’état du flux de travail. Supposons qu’un agent ait terminé l’extraction d’un document, la récupération des preuves et leur analyse, sans avoir encore généré le rapport. Si l’agent plante avant que le rapport ne soit prêt, le système doit savoir où reprendre. C’est cela, l’état. Le modèle n’a pas besoin de se rappeler que l’étape d’analyse est terminée, puisque l’application le sait déjà.
Le statut des tâches, le nombre de tentatives, les points de contrôle, les identifiants des jobs, les étapes achevées et les actions en attente appartiennent généralement à l’état déterministe de l’application, et non au cadre d’une conversation avec un LLM. Une bonne règle : si le logiciel peut connaître quelque chose avec précision, qu’il le stocke également avec précision. Le modèle ne doit pas être chargé de se souvenir des faits liés au flux de travail.
Tout ce qui s’est produit ne mérite pas nécessairement d’être enregistré
Imaginez qu’un outil renvoie un en-tête JSON de 500 lignes. Le pas suivant a-t-il besoin de toutes ces 500 lignes ? Probablement seulement d’un ou deux champs, tels que account_status = ACTIVE, total_balance = 120000 ou document_found = true. La sortie brute peut rester dans les journaux ou le stockage, tandis que la mémoire ne doit conserver que les éléments essentiels.
Les conversations fonctionnent de la même manière. Si un utilisateur et un agent ont échangé dix messages pour préciser une exigence, une note concise comme « l’utilisateur souhaite que le rapport soit regroupé par catégorie et trié par gravité » est bien plus utile que de rejouer toute l’échange à chaque fois.
Ce qui mérite d’être mémorisé
Aucune réponse unique ne convient à tous les systèmes, mais quelques catégories constituent généralement de bons candidats :
- Préférences stables : format de sortie, langue, style de rapportage.
À éviter de stocker
- Chaque réponse du modèle. La plupart des raisonnements intermédiaires ne sont pas utiles par la suite.
- Chaque sortie d’outil, qui peut être volumineuse, obsolète ou spécifique à un instant donné.
- Erreurs temporaires. Un temps d’exécution insuffisant d’hier ne doit pas devenir le contexte de demain.
- Des hypothèses de modèle non vérifiées, ce qui représente le risque le plus élevé. Si un modèle indique qu’un document « semble faire référence à l’Entreprise A » et que personne ne le valide, en le stockant on peut transformer une simple supposition fragile en un fait permanent sur lequel on continuera à s’appuyer par la suite.
- Des données sensibles pour lesquelles il n’y a aucune raison claire de les conserver. La mémoire doit avoir un but.
La mémoire peut se tromper
C’est l’un des plus gros problèmes liés à la mémoire à long terme. Un agent enregistre que la monnaie de rapport d’un client est le USD, et six mois plus tard cette préférence change tandis que l’ancienne entrée reste en place. Laquelle l’emporte ? La mémoire a besoin d’une notion de fraîcheur. Certains faits restent valables pendant des années, d’autres seulement quelques minutes, et un bon système sait les distinguer.
Un cycle de vie, pas un stockage oublié
La mémoire ne devrait pas suivre un parcours de stockage et de conservation permanente. Un cycle plus réaliste comprend l’acquisition, la validation, le stockage, la récupération, l’utilisation, puis la mise à jour, l’expiration ou la suppression. Pour cela, chaque entrée peut nécessiter une date de création, une origine, un indicateur confirmé ou non confirmé, une dernière heure d’utilisation, une règle d’expiration et un lien vers toute valeur plus récente qui l’a remplacée. Écrire n’est que la moitié du travail ; la maintenance en constitue l’autre moitié.
L’origine importe
Supposons qu’il existe deux mémoires. L’une indique que le format préféré est PDF, et l’utilisateur l’a confirmé explicitement hier. L’autre indique que le format préféré pourrait être Excel, ce que un LLM a déduit il y a six mois. Elles ne devraient pas avoir le même poids, c’est pourquoi il est idéal que la mémoire enregistre l’origine : a-t-elle été fournie par l’utilisateur, générée par le système, déduite par un modèle, récupérée à partir d’un document, renvoyée par un outil ou copiée ailleurs ? Ce contexte indique au système jusqu’à quel point il peut lui faire confiance.
La confiance est également importante
« Le contrat semble expirer en juin » est un type de déclaration différent de « Date d’expiration du contrat : 30 juin 2027 », tirée d’un champ structuré. L’une peut être considérée comme ayant un degré élevé de fiabilité, tandis que l’autre nécessite une vérification ; ainsi, les conclusions approximatives ne se transforment pas silencieusement en faits. Un enregistrement utile à long terme contient souvent plus qu’une simple valeur : il peut également inclure source, confidence, timestamp, scope et status, ce qui rend les recherches ultérieures beaucoup plus sûres.
Les résumés sont des interprétations
Les résumés font partie des meilleures façons de limiter la mémoire de travail. Conservez plutôt « l’utilisateur souhaite une explication technique concise avec des exemples » au lieu d’une conversation complète, ou « trois résultats confirmés, un non résolu » au lieu de chaque étape d’analyse. Le problème, c’est qu’un résumé est une interprétation et peut omettre un détail important. Pour les workflows importants, associez le résumé à un lien vers les preuves originales. Le résumé permet à l’agent de rester efficace, tandis que les sources originales restent accessibles en cas de besoin de vérification.
Ne créez pas une deuxième source de vérité
Si les détails du client se trouvent déjà dans la base de données principale des clients, les copier dans la mémoire à long terme de l’agent est généralement une erreur. Bientôt, les deux versions diffèrent, et personne ne sait laquelle est correcte. Il vaut mieux considérer le système officiel comme la source à consulter en cas de besoin et intégrer le résultat dans le contexte de l’agent. Ne dupliquez pas un système de registre sans une raison très claire. Le critère est de savoir si l’information peut être récupérée de manière fiable depuis sa source plutôt que d’être mémorisée. Dans ce cas, la récupération peut être préférable à la mémoire.
Portée
Lorsque plusieurs utilisateurs, organisations ou flux de travail partagent une même infrastructure d’agents, des limites sont nécessaires en matière de mémoire. La mémoire d’un utilisateur ne doit pas apparaître dans le contexte d’un autre, une organisation ne devrait pas accéder aux données d’une autre, et un flux de travail n’a pas besoin des résultats intermédiaires d’un autre. En général, la mémoire requiert un champ d’application explicite, tel que global, organisationnel, utilisateur, conversationnel, de flux de travail ou de tâche. Plus le champ d’application est restreint, plus il est peu probable que des informations irrelevantes s’infiltrent dans une décision qui n’en a pas besoin.
Récupérer la mémoire est un problème de recherche
Avec 500 mémoires stockées, personne ne devrait les inclure toutes dans chaque demande. Nous retombons sur le problème du contexte : la récupération des mémoires nécessite donc son propre processus — examiner la tâche en cours, déterminer quel type de mémoire est pertinent, filtrer selon l’utilisateur, le flux de travail et l’organisation, rechercher, classer, sélectionner puis ajouter les éléments pertinents au contexte de travail. C’est pourquoi l’ingénierie des mémoires et celle du contexte sont étroitement liées. Les mémoires déterminent ce qui pourra être utilisé plus tard, tandis que l’ingénierie du contexte définit ce qui est utilisé immédiatement.
Écrire moins, récupérer mieux
Au lieu de se demander ce qui d’autre peut être stocké, il faut se demander quelle information a une valeur suffisante à long terme pour justifier son stockage. Au lieu de se demander combien de mémoires peuvent tenir dans une demande, il faut se demander quelle mémoire est pertinente pour cette décision. Une bonne architecture de mémoires devrait généralement faire en sorte que l’agent voie moins d’informations, car les mémoires irrelevantes ne sont rien d’autre que du contexte inutile.
Observabilité
Supposons qu’un agent donne une réponse étrange. Le document récupéré semble correct et l’appel à l’outil a réussi, pourtant la réponse est erronée, et finalement quelqu’un découvre qu’un souvenir ancien a influencé la décision. Sans visibilité sur le processus de récupération des souvenirs, il est très difficile de déboguer. Pour chaque exécution, il est utile de consigner quels souvenirs ont été consultés et pourquoi, leur origine et leur âge, leur statut confirmé, le fait qu’ils aient fait partie du contexte final, ainsi que le fait qu’ils aient modifié la sortie. Cela transforme les souvenirs, qui étaient auparavant un comportement caché, en éléments pouvant être examinés.
Une architecture plus réaliste
Plutôt que que tout afflue vers la mémoire puis vers l’agent, imaginez ceci : un utilisateur ou une tâche arrive, l’état du flux de travail est consulté, et le système décide quelles informations sont nécessaires. Ensuite, il puisera dans des sources distinctes :
- Contexte de travail pour ce qui est nécessaire en ce moment, comme la demande actuelle, le résultat le plus récent de l’outil et la décision en cours.
- Mémoire à court terme pour ce qui est nécessaire au sein de ce flux de travail, comme un résumé de tâche, des résultats intermédiaires et des décisions récentes.
- Mémoire à long terme pour ce qui pourrait être utile pour des flux de travail futurs, comme une préférence stable, un fait confirmé ou un résultat historique.
- Connaissances et RAG pour les informations existant ailleurs, telles que des documents, des politiques, des rapports et des bases de données.
- État de l’application pour une vérité déterministe, comme le statut, les points de contrôle, le nombre de tentatives et les étapes terminées.
Ensuite, filtrer, classer, assembler le contexte actuel et permettre à l’agent de raisonner. Appeler tout cela simplement « mémoire » cache sa structure.
Questions à se poser avant d’ajouter une fonction de mémoire
- Cela aidera-t-il une tâche future ? Si non, ne le stockez pas.
Les réponses à ces questions sont généralement plus importantes que le choix de la base de données mémoire.
Oublier est une fonctionnalité
Une bonne mémoire ne signifie pas se souvenir de tout. Un agent utile doit oublier beaucoup de choses : des détails temporaires, les résultats d’outils anciens, des hypothèses non vérifiées, des faits obsolètes ainsi que des raisonnements qui n’ont plus d’importance. Plus de mémoire ne rend pas automatiquement un système plus intelligent ; parfois, cela ne fait qu’offrir au modèle davantage d’occasions de relier des éléments incorrects. En pratique, cela signifie : ne conserver que ce qui sera utile plus tard, gérer l’état du flux de travail avec du code déterministe simple, récupérer les connaissances là où elles se trouvent, ne laisser entrer dans le prompt que les souvenirs pertinents, noter l’origine de chacun d’eux, et mettre à jour ou supprimer les entrées au fur et à mesure que les faits évoluent.
Les bases de données existent pour stocker des données. La mémoire d’un agent a un autre but : présenter aux modèles les faits appropriés au moment où ils sont nécessaires, tout en empêchant que des informations anciennes et désordonnées ne se transforment en certitudes irréfutables.