Créer une mémoire d’agent capable de survivre à la conversation sans accumuler inutilement des données.

Une scène qui se reproduit avec presque tous les agents mis en production se déroule comme suit.

Le lundi, un utilisateur indique qu’il gère la région du Nord-Ouest, ne s’intéresse qu’aux projets en cours et ne supporte pas les réponses longues. L’agent répond « Compris », et pour le reste de la session, cela signifie que les réponses seront courtes, se limiteront au Nord-Ouest et ne comporteront pas de brouillons. L’utilisateur est satisfait.

Mardi, la même personne ouvre une nouvelle conversation et demande comment se passent ses projets. L’agent demande gentiment de quelle région il souhaite avoir des nouvelles.

L’expression sur le visage de cet utilisateur est la raison de devoir réfléchir sérieusement à la mémoire.

Pourquoi enregistrer tout est une mauvaise idée

Presque tous les développeurs recourent à la même solution : enregistrer toute la conversation pour la recharger le lendemain. Cela semble évident, mais c’est un piège. La manière dont cela échoue nous apprend plus sur la conception des agents que la plupart des tutoriels.

Supposons que l’historique complet soit conservé et reproduit chaque fois que l’utilisateur revient. Les événements se produisent dans un ordre prévisible.

La première semaine, ça marche. L’agent se souvient vraiment de tout, et vous avez l’impression d’être malin. C’est la phase dangereuse, car cela semble confirmer le bon fonctionnement du système.

La troisième semaine, cela devient lent et coûteux. Chaque interaction implique désormais des milliers de tokens de conversations antérieures. Vous payez pour des bavardages du lundi en répondant à une question du vendredi. La fenêtre de contexte est comme le bureau de l’agent, et vous l’avez déjà encombrée des documents de la semaine précédente avant même de commencer le travail du jour.

À la sixième semaine, les choses tournent mal. Personne ne vous avertit de cette étape. Les anciennes conversations contiennent des affirmations qui ont cessé d’être vraies. L’utilisateur se concentrait sur le Nord-Ouest jusqu’à ce qu’une promotion le mette à la tête de tout le pays. Le projet a été en retard jusqu’à sa livraison. Revoir tout cela oblige l’agent à évaluer de manière égale les faits obsolètes et ceux qui sont actuels. Le problème n’est plus qu’il se souvienne trop peu ; il se souvient plutôt trop, sans savoir ce qui est périmé.

Revoir l’ensemble de l’historique revient en fait à créer un mécanisme pour produire du contexte obsolète. Ainsi, la question « Comment puis-je conserver tout ? » n’a jamais été la bonne. Les vraies questions sont les suivantes :

Quelles informations méritent d’être conservées, lesquelles doivent être récupérées en cas de besoin, et lesquelles doivent être éliminées pour être recréées à partir de zéro ?

En y répondant, l’architecture de la mémoire s’établit automatiquement.

Une conception en trois niveaux

Comparez cela à la manière dont vous gérez les informations au travail. Certaines choses, vous les gardez en tête pendant une réunion avant de les oublier volontiers par la suite. D’autres, vous les notez dans un carnet parce que vous en aurez besoin le mois suivant. D’autres encore, vous ne les mémorisez jamais, car elles changent et vous les vérifiez à chaque fois. Les agents ont besoin des mêmes trois niveaux de stockage.

Niveau 1 : mémoire de session, destinée à disparaître

Ce niveau contient tout ce qui est lié à la conversation en cours : l’historique des messages, les résultats provisoires des outils, une tâche en plusieurs étapes inachevée, ainsi que l’état de LangGraph qui se déplace d’un nœud à l’autre.

Lorsque la session se termine, ce niveau est conçu pour disparaître. Ce n’est pas un enregistrement oublié ; c’est précisément son fonctionnement, et c’est une caractéristique positive.

Les débutants se sentent coupables à ce sujet, mais ce n’est pas nécessaire. Le déroulement d’une conversation ressemble à une réunion : ce n’est pas la transcription qui compte, mais les conclusions. La question intéressante est donc de savoir ce qui est promu au niveau 2 lorsque la session se termine.

Ce n’est pas la transcription. Une étape d’extraction simple et explicite permet d’identifier trois catégories :

1. Faits stables concernant l’utilisateur, tels que « gère la région du Nord-Ouest », valables tant qu’ils ne sont pas annulés.
2. Préférences, comme « souhaite des réponses courtes » et « exclure les projets en version草案 ».
3. Décisions, telles que « accord sur un format de résumé hebdomadaire ».

Cette conversation du lundi pourrait atteindre quatre mille tokens. Ce qui mérite de survivre à celle-ci, ce sont environ quarante tokens de faits structurés, ce qui représente une compression d’environ cent fois. Contrairement à un résumé, rien d’important n’est altéré, car vous avez extrait des catégories nommées plutôt qu’une impression générale. Les résumés suppriment discrètement des contraintes, tandis que l’extraction est la solution : une préférence soit figure dans la liste mot pour mot, soit elle n’y figure pas, et vous pouvez écrire un test pour cela.

Niveau 2 : mémoire à long terme, petite, structurée et modifiable

Il s’agit du stockage compact qui persiste entre les sessions, le carnet de l’utilisateur. Résistez à l’envie d’être malin. Un format ennuyeux est justement la raison pour laquelle il fonctionne :

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Quelques dizaines de lignes de JSON par utilisateur, chargées dans le contexte au début de chaque session. Cela coûte suffisamment peu pour être inclus à tout moment, et reste suffisamment léger pour ne pas alourdir les ressources.

Trois règles permettent de le maintenir en bon état.

La structure l’emporte sur le texte narratif. Un texte vague du type « cette personne gère probablement la région du Nord-Ouest et préfère la concision » est inutile par la suite. En revanche, les faits distincts peuvent être affichés à l’utilisateur, corrigés et supprimés un par un.

Attribuez une date à tout, et remplacez plutôt que d’ajouter. Lorsque l’utilisateur passe de la région du Nord-Ouest à la région nationale, on ne rajoute pas un deuxième fait à côté du premier ; on le remplace. Une fois que la base de données contient à la fois « gère le Nord-Ouest » et « gère la région nationale », on réintroduit le problème de l’état obsolète, ce qui est pire, car cet état restera désormais permanent.

Permettez à l’utilisateur de le voir et de le corriger. Même une commande simple du type « Voici ce dont je me souviens à votre sujet » change la situation. Une mémoire que l’utilisateur ne peut pas examiner devient finalement une mémoire en laquelle il ne a plus confiance, généralement au moment où l’agent affirme avec une certitude absolue quelque chose qui est déjà dépassé depuis des mois.

Tout ce qui peut être consulté reste en dehors du Niveau 2. Cela relève du Niveau 3, et les équipes y consacrent le plus souvent leurs efforts à des choses inappropriées.

Niveau 3 : régénération sur demande, volontairement non mémorisée

Tout ce qui change automatiquement se trouve ici : les états des projets, les chiffres, les dates, les organigrammes, les données en temps réel, le contenu des bases de données et des API.

La règle est que ce niveau d’information ne doit jamais être mémorisé. Ne le résumez pas, ne le stockez pas dans une mémoire interne, et n’essayez pas de l’utiliser à partir d’une conversation antérieure. Au moment où c’est nécessaire, l’agent invoque un outil pour obtenir la valeur actuelle.

Écrit ainsi, cela semble évident. C’est aussi la règle la plus souvent enfreinte dans la mémoire des agents, car stocker des données en temps réel sous forme de mémoire interne peut sembler une optimisation. En réalité, c’est une bombe à retardement à mèche lente :

• Stocker « Le projet Falcon est retardé » puis le projet est livré. Pendant des semaines, l’agent continue de parler d’un projet qui a déjà été livré.
• Stocker « L’équipe compte 8 membres » puis deux personnes rejoignent l’équipe. Toutes les réponses concernant les capacités sont donc fausses.

Le résumé le plus précis de toute cette architecture est probablement celui-ci :

Utilisez la mémoire pour les informations concernant la personne. Utilisez des outils pour toutes les autres informations.

Les préférences des utilisateurs changent rarement, et ils vous en informent lorsqu’il y a changement. Le monde, lui, change constamment sans vous en dire rien. Alors, pensez aux utilisateurs et interrogez le monde.

Un cas d’échec : « partager tout » rencontre les systèmes multi-agents

C’est la version simplifiée. Le chemin menant à cette solution a été emprunté suite à un incident, dans un processus fictif impliquant deux agents au sein d’une entreprise de services réseau.

L’agent A a parlé avec les utilisateurs et recueilli leurs exigences en matière de rapports. L’agent B a ensuite généré ces rapports. Lorsque A a transmis son travail à B, l’équipe a répété la même erreur de débutant à l’échelle architecturale : ils ont transféré tout le contexte d’A, y compris toute la conversation, tous les résultats des outils et tout l’état du système. Le raisonnement semblait solide. Plus de contexte signifiait-il forcément un B mieux informé ?

La manière dont cela s’est produit constitue la partie intéressante. Lors d’une même session, un utilisateur a demandé à haute voix à l’Agent A : et si les projets archivés étaient inclus ? Après réflexion, il a conclu que non, cela fausserait les totaux, il fallait les exclure. C’était une simple réflexion à voix haute, et A l’a gérée correctement.

Puis le transfert a eu lieu et B a reçu l’intégralité de la transcription, y compris les digressions. Mais B ne disposait pas du contexte de conversation d’A pour évaluer cette information. Rien dans le contenu transmis ne précisait que l’idée des projets archivés avait été rejetée, et hors contexte, cela ressemblait à une instruction. B a inclus fidèlement les projets archivés, ce qui a entraîné des erreurs dans les totaux d’un rapport officiel ; personne n’a pu en trouver la raison en examinant son code, alors que celui-ci était parfaitement correct.

C’est la version multi-agents de tout ce qui a été mentionné précédemment : un transfert correspond à une frontière de session. Lorsque l’Agent B commence sa tâche, il s’agit d’une nouvelle conversation du mardi. L’équipe a commis la même erreur de « sauvegarder tout » de manière latérale, entre agents, plutôt que de façon longitudinale au fil des jours.

La solution était la même. Le transfert de transcriptions a été remplacé par un envoi structuré, en fait un élément temporaire de niveau 2 que A crée pour B :

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

Cela correspond à environ cinquante tokens sans ambiguïté. B reçoit les conclusions, et non le chemin sinueux menant à celles-ci. La catégorie « archived-projects » de bogues est devenue impossible à gérer, car des idées abandonnées ne peuvent physiquement survivre une fois extraites dans une liste de exigences.

Prenons une phrase dans tout design multi-agents : les agents devraient s’échanger des conclusions, jamais des transcriptions.

Une liste de contrôle à appliquer cette semaine

Cinq décisions que vous pouvez prendre concernant un agent existant :

1. Laissez la mémoire de session disparaître. Ajoutez une étape d’extraction à la fin de la session, ou après N tours, qui ne conserve que les faits, préférences et décisions, laissant le reste s’évanouir avec la conversation.
2. Gardez le niveau 2 sous forme de JSON simple. Éléments discrets, timestamps, mises à jour qui remplacent le contenu. Jamais de texte en prose en expansion constante, et jamais en mode ajout uniquement.

Fournissez aux utilisateurs un accès à leur mémoire. Une question du type « Que vous souvenez-vous de moi ? », même rudimentaire, crée de la confiance et permet de détecter gratuitement des informations obsolètes.

Mettez en place un audit de niveau 2 pour les informations sur le monde. Tout ce que l’outil peut obtenir de frais, comme des statuts, des comptages, des dates et des chiffres, doit être remplacé. La mémoire sert l’utilisateur, les outils servent le monde.

Transmettez des conclusions claires lors des transferts de tâches. Utilisez un envoi structuré contenant la tâche, les exigences et les contraintes. Si votre transfert inclut un texte brut, vous avez déjà commis l’une des erreurs mentionnées sans même vous en rendre compte.

La leçon à retenir

Penser que la mémoire signifie stocker davantage est complètement à l’opposé de la réalité. Toutes les erreurs mentionnées, que ce soit des solutions tentatives pour l’amnésie du mardi, des informations obsolètes ou les rapports sur les projets archivés, trouvent leur origine dans un entassement excessif et négligent d’informations.

Un bon fonctionnement de la mémoire des agents repose principalement sur l’art d’oublier. L’état de la session peut disparaître, les notes à long terme restent suffisamment courtes pour être lues d’un seul coup d’œil, et rien de ce que le monde peut vous apprendre de nouveau n’est mémorisé. Les agents qui donnent l’impression d’être véritablement personnels ne sont pas ceux qui se souviennent de tout ; ils se souviennent simplement des quarante tokens appropriés.