Mémoire des agents IA : comment créer des agents IA dotés d’un contexte persistant

Si vous deviez accompagner un nouveau collègue jusqu’à l’imprimante tous les matins pendant six mois, vous commenceriez à vous inquiéter. S’il pouvait réciter chacun de ces trajets dans les moindres détails mais avait toujours besoin d’être escorté, sa mémoire serait excellente… mais vous devriez quand même vous lever de votre bureau.

La mémoire des agents IA vit aujourd’hui une version sans fin de ce trajet jusqu’à l’imprimante. Charles Packer, PDG de Letta, affirme dans The New Stack que les benchmarks de mémoire sont saturés parce qu’ils mesurent le rappel, un problème qu’il considère comme résolu. Le véritable défi, c’est qu’un agent progresse dans son travail grâce au contexte qu’il conserve, sans aucun réentraînement.

Sa cofondatrice Sarah Wooders compare cela à un premier jour de travail — les benchmarks fournissent à l’agent tout le contexte dont il a besoin — répété tâche après tâche, sans lien entre elles, ce qui ne ressemble en rien à la façon dont les gens travaillent. Une nouvelle recrue a peut-être besoin qu’on l’accompagne jusqu’à l’imprimante. Mais au bout de trois ans, on espère pouvoir lui confier une consigne d’une ligne sans se lever de son bureau.

C’est l’objectif vers lequel tendre, et l’ambition de Brain, notre système de mémoire auto-améliorant pour Perplexity Computer, qui organise les travaux passés et les corrections en un wiki de connaissances évolutif.

Nous verrons ce dont un agent doit se souvenir et comment vérifier si cela l’aide à mieux travailler.

Qu’est-ce que la mémoire des agents IA ?

La mémoire d’un agent IA désigne les informations qu’il conserve de ses interactions et de ses travaux précédents, ainsi que les mécanismes qui permettent de les mettre à jour et de les utiliser. Le contexte de mémoire persistante transporte ces informations d’une session à l’autre : fermer une conversation ne signifie donc pas repartir de zéro pour la tâche suivante.

La plupart des solutions proposées sous ce nom se souviennent de l’utilisateur. Vos préférences, vos contacts, votre rôle, le fait que vous voulez des PDF plutôt que des PNG. C’est la moitié facile du travail.

Lorsque nous avons créé Brain, le système de mémoire de Perplexity Computer, nous nous sommes concentrés sur le travail lui-même. Quelle approche a fonctionné ? Quelle source a fait perdre vingt minutes ? Qu’avez-vous dû corriger après que l’agent a annoncé avoir terminé ? Cet historique offre un meilleur point de départ à la tâche suivante.

Brain stocke ces informations sous forme de fichiers dans le bac à sable de l’agent, organisés en trois couches :

• sessions/ contient les transcriptions brutes et leurs résumés.
• notes/ contient des informations synthétisées, organisées par thème.
• knowledge/ contient le wiki lui-même : des pages Markdown liées entre elles sur des personnes, des projets et des concepts.

Rien de tout cela ne s’améliore tout seul. Pendant la nuit, des agents en arrière-plan que nous appelons « Dream » lisent les sessions de la journée, les résument et révisent le wiki partout où la situation a changé. Nous préparons et vérifions ces modifications avant de les valider via Git, de sorte qu’il existe un diff à examiner lorsque quelque chose semble anormal.

Cela rend-il l’agent meilleur dans son travail ? Lors de notre évaluation appariée sur 30 jours, les sessions avec Brain ont amélioré l’exactitude de 9,3 points de pourcentage et le rappel de 8,9 points, tout en consommant environ 15 % de tokens en moins.

Agrandir

Source : X

Quels sont les types de mémoire agentique ?

Il en existe deux grandes catégories, et la distinction ressemble beaucoup à celle que l’on ferait pour une personne : ce que vous avez en tête en ce moment, et ce que vous saurez encore le mois prochain.

Mémoire à court terme

La mémoire à court terme contient le contexte de la conversation ou de la tâche en cours. Votre demande, les messages récents, le résultat d’un appel d’outil, le document que l’agent vient d’ouvrir. Juste assez d’informations pour déterminer quoi faire ensuite.

On parle aussi de mémoire de travail. Pour un LLM, la fenêtre de contexte contient les informations disponibles lors d’un appel donné au modèle. L’application peut gérer un état de tâche supplémentaire et décider quelles parties fournir à chaque étape.

Et « court terme » ne signifie pas forcément jetable. Un framework peut enregistrer l’état de la conversation et le restaurer le lendemain : cet état reste rattaché à ce fil. Mais la possibilité pour une autre tâche d’utiliser ces informations relève d’une décision de conception distincte.

Mémoire à long terme

La mémoire à long terme rend les informations disponibles d’une session à l’autre. L’article CoALA a emprunté trois catégories aux sciences cognitives, offrant aux concepteurs d’agents un vocabulaire pour décrire les expériences et le savoir-faire :

• La mémoire épisodique, c’est ce qui s’est passé : elle comprend les sessions passées, les étapes suivies par un agent, le résultat obtenu. Dans Brain, sessions/ fournit cet historique sous forme de transcriptions brutes et de leurs résumés.
• La mémoire sémantique, c’est ce que l’agent tient pour vrai : il peut s’agir de faits concernant l’utilisateur, ses projets et son univers, extraits des conversations. Le wiki knowledge/ de Brain contient ce type d’informations, avec des liens vers les éléments de preuve.
• La mémoire procédurale, c’est la façon de faire les choses : il s’agit des prompts, des flux de travail réutilisables, des Skills que Perplexity développe pour fournir aux agents les instructions et les outils nécessaires à une tâche. Vous en disposez peut-être déjà en partie sans l’appeler mémoire.

Le travail intéressant se passe entre les couches. Une session enregistre que vous avez refusé un PNG. Votre consigne d’utiliser des PDF devient une préférence que l’agent peut conserver pour la suite. Une correction du processus d’exportation devient une règle qu’il pourra suivre la prochaine fois.

Cette conversion, de « ceci s’est produit » à « ceci est vrai » puis à « voici comment nous procédons », fait partie du problème d’apprentissage évoqué en introduction, et c’est là que les exécutions nocturnes de l’agent Dream de Brain concentrent leurs efforts.

Imaginons que quelqu’un réchauffe du poisson au micro-ondes dans une cuisine commune. Des plaintes fusent, on ouvre une fenêtre. Finalement, un panneau apparaît : PAS DE POISSON.

Six mois plus tard, le coupable a déménagé, mais le panneau est toujours là. C’est cela, la persistance. On peut expliquer les types de mémoire par ce qui subsiste :

• La mémoire de travail, c’est ce que vous gardez à l’esprit en préparant le déjeuner, comme le fait qu’il faut remuer la soupe.
• La mémoire épisodique, c’est l’incident du poisson : l’odeur qui a suivi tout le monde jusque dans le couloir.
• La mémoire sémantique, c’est la leçon que vous en avez tirée : réchauffer du poisson peut laisser une odeur tenace dans une cuisine commune.
• La mémoire procédurale, c’est la consigne qui régit la suite. Ne pas réchauffer de poisson au micro-ondes ici. Le panneau permet à quelqu’un qui n’a rien vu de l’incident de respecter la règle.

Il existe aussi une autre distinction, car elle change ce que nous construisons. Une étude publiée pour la première fois en décembre 2025, Memory in the Age of AI Agents, affirme que l’opposition court terme/long terme ne suffit pas, et classe également la mémoire selon sa forme :

• Au niveau des tokens : il s’agit du contenu explicite que l’agent lit. Des fichiers, des enregistrements stockés, des fragments récupérés.
• Paramétrique : il s’agit d’informations encodées dans les poids appris. Leur mise à jour nécessite un entraînement ou des méthodes d’édition de modèle.
• Latente : il s’agit d’informations conservées dans des représentations internes, sans être écrites sous forme de texte lisible.

Nous nous concentrons ici sur la mémoire au niveau des tokens, c’est-à-dire les informations stockées en dehors du modèle et chargées dans son contexte en cas de besoin. Le wiki Markdown de Brain en est un exemple.

Agrandir

Lorsque nous mettons à jour une page, nous modifions ce que l’agent peut lire lors de sa tâche suivante, mais ses poids sous-jacents restent les mêmes. C’est l’idée de Packer évoquée en introduction : s’améliorer grâce au contexte que l’agent conserve, sans réentraînement.

Comment les différents types de mémoire d’un agent fonctionnent-ils ensemble ?

Un agent peut revenir sur une tentative précédente, voir où elle a échoué et charger les instructions que vous lui avez données par la suite. Plusieurs types de mémoire interviennent dans une même tâche, sans qu’il faille les solliciter à tour de rôle ni leur attribuer chacun une base de données distincte.

Ici, la persistance détermine ce qui reste disponible une fois la conversation terminée, tandis que la récupération détermine si l’agent y aura de nouveau accès.

Dans Brain, nous préservons ce chemin qui mène de la leçon aux éléments de preuve. Imaginons que vous demandiez à Computer de poursuivre un projet de la semaine dernière :

• L’index de Brain lui indique quelles pages de mémoire existent et où les trouver.
• Brain ouvre la page du projet pour lire les décisions et les instructions enregistrées.
• Si une note indique que vous avez rejeté une approche, l’agent peut suivre sa citation jusqu’à la conversation d’origine et vérifier pourquoi.

Les liens vers les pages associées lui permettent de rechercher les personnes ou les autres projets concernés. Pour cela, l’agent lit des fichiers et y effectue des recherches. grep, par exemple, lui permet de trouver les mentions d’un projet par son nom.

Nous avons également testé ce que les agents gagnent à pouvoir explorer des fichiers. Dans un benchmark interne portant sur 150 questions relatives à des documents financiers, un agent d’exploration utilisant des outils de fichiers standard a atteint un score de réponse de 0,627, contre environ 0,37 pour la recherche sémantique sur le même corpus.

Agrandir

Source : X

Comment améliorer la mémoire des agents IA ?

Un article de mai 2026 signé Orogat et Mansour identifie quatre défaillances récurrentes de la mémoire des agents : le stockage ne cesse de croître, les croyances obsolètes ne sont pas révisées, des informations sont oubliées quand l’espace vient à manquer, et la récupération lit sans rien apprendre de la consultation.

La solution qu’ils proposent consiste à ne plus considérer la mémoire agentique comme un simple stockage, mais comme un « état » qui évolue au moyen de quatre opérations : ingérer, réviser, oublier, récupérer. C’est notre liste de contrôle pour cette section.

Choisir avec soin ce qui est mémorisé

Dès qu’un « mauvais » souvenir est enregistré, chaque étape en hérite.

Workday AI Research a testé une approche sélective sur environ 1 500 souvenirs candidats issus du benchmark LoCoMo, en posant cinq questions avant de conserver chacun d’eux :

• Est-ce utile ? Est-ce susceptible de resservir ?
• Est-ce fiable ? La conversation l’a-t-elle réellement dit, ou le modèle a-t-il comblé les blancs ?
• Est-ce nouveau, ou déjà stocké ?
• Est-ce récent ?
• S’agit-il d’un fait durable ou d’un état passager ?

Seule la première question nécessitait un appel au modèle. Les quatre autres s’exécutaient sous forme de règles, en moins de 65 millisecondes au total. La méthode a atteint une précision supérieure de 12 % sur les décisions de conservation ou de suppression, tout en conservant 97 % des souvenirs pertinents.

C’est la dernière question qui a le plus contribué : sans la distinction entre informations durables et temporaires, la qualité des décisions chutait d’environ 18 %.

Réviser la réponse sans perdre l’historique

Enregistrez quand un fait est devenu valide, quelle source l’étaye et ce qu’il a remplacé. Si les sources divergent, laissez ce désaccord visible jusqu’à disposer de suffisamment d’éléments pour le trancher. Le document le plus récent peut lui aussi se tromper.

Brain met à jour le wiki à partir de documents sources, de résultats de connecteurs et de corrections des utilisateurs. Chaque entrée de mémoire renvoie à sa source. Nous avons besoin que l’agent trouve la réponse actuelle et sache où chercher si cette réponse lui semble suspecte.

Oublier délibérément

L’article qualifie l’un de ces modes de défaillance d’« oubli lié à la capacité » : des informations sont supprimées pour respecter une limite de stockage, et non parce qu’elles ont cessé d’être utiles.

Revenons à la cuisine commune. Au bout de six mois, personne ne se soucie de savoir qui a réchauffé le poisson au micro-ondes ni combien de temps la fenêtre est restée ouverte. Mais le panneau a toujours son utilité.

Quand la personne suivante préparera son déjeuner, la règle sera là. Il suffit d’archiver les plaintes.

Les vérifications de fraîcheur et de type d’information de Workday interviennent avant le stockage, pour filtrer ce qui mérite de devenir un souvenir. Dans Brain, nous réexaminons aussi les connaissances existantes à mesure que les documents sources évoluent et que les utilisateurs apportent des corrections. Dans les deux cas, c’est le contenu qui rend l’intervention nécessaire.

Faire en sorte que la récupération alimente la prochaine mise à jour

L’agent récupère un fait, l’utilise et laisse le stockage exactement dans l’état où il l’a trouvé. Dès lors, à moins que le système ne capture ce qui s’est passé ensuite, rien n’indique si ce fait a été utile ou s’il a mené l’agent vers une nouvelle impasse.

Enregistrez le résultat, la source et toute correction. Lorsque nous avons créé Brain, nous avons intégré cet historique de travail à ce qu’il mémorise : quelle approche a fonctionné, quelle source n’a mené nulle part et ce que l’utilisateur a corrigé après que l’agent a annoncé avoir terminé. Brain intègre cette expérience à ses mises à jour périodiques du wiki, afin que les tâches ultérieures puissent en tirer parti.

Rien de tout cela n’apparaît pourtant dans un benchmark de rappel. Pour savoir si la boucle fonctionne, il faut confier à l’agent une tâche qu’il ne peut accomplir qu’avec la mémoire et compter combien de fois il y parvient, en tenant compte du coût et de la latence. C’est ce que fait DolphinBench, et c’est pourquoi les meilleurs scores se situent encore entre 70 et 80.

Comment créer un agent doté d’une mémoire persistante avec Perplexity

L’Agent API de Perplexity n’intègre pas de système de mémoire autogéré comme Brain. Nous préférons le dire d’emblée. En revanche, elle vous fournit les éléments de mémoire dont vous avez besoin : un emplacement pour conserver les procédures, un moyen de transmettre le contexte d’un échange à l’autre, et des outils pour lire et écrire dans un stockage que vous contrôlez.

Commencer par la mémoire procédurale

Une Skill personnalisée regroupe des instructions, des procédures et des fichiers complémentaires sous un numéro de version. Une équipe plateforme peut rédiger une seule fois ses vérifications de déploiement, ses critères de rollback et son format de rapport, puis faire en sorte que les applications fassent référence à la même Skill. Lorsque la procédure change, l’équipe met en ligne une nouvelle version.

Agrandir

Source : X

Un Profil va un cran plus loin. Les Profils enregistrent le modèle, les instructions, les outils, les Skills, les connecteurs et les paramètres d’exécution de l’agent sous un identifiant versionné unique.

Nous avons ajouté les deux en septembre, ainsi que des connecteurs gérés, afin qu’un administrateur de projet puisse configurer une seule fois une connexion GitHub ou Slack approuvée et permettre aux applications d’y faire référence au lieu de stocker des identifiants distincts. Lorsque les accès changent, l’administrateur met à jour la connexion à un seul endroit.

Pourquoi cela relève-t-il de la mémoire ? Revenons une fois de plus à la cuisine du poisson réchauffé au micro-ondes. La personne suivante peut respecter la consigne « PAS DE POISSON » sans avoir assisté aux plaintes.

Une Skill joue le même rôle pour un agent, avec de la place pour les étapes, les exceptions et les vérifications qui ne tiendraient pas sur une porte de micro-ondes. Les Skills sont consignées par écrit, versionnées et disponibles la prochaine fois que la tâche se présente.

Nous utilisons aussi des Skills pour guider les mises à jour de la mémoire de Dream. Mais ce qu’une Skill ne fait pas, c’est apprendre par elle-même. Les instructions changent lorsqu’une nouvelle version est mise en ligne, que ce soit par une personne ou par un processus automatisé.

Si vous voulez que l’agent remarque que la vérification de rollback échoue sans cesse sur un service et qu’il s’adapte, c’est la boucle des sessions vers le wiki décrite plus haut.

Vous devez conserver ce qui s’est passé, déterminer ce qui doit changer et rendre la correction disponible la prochaine fois. Pour cela, il faut les deux éléments suivants.

Conserver la mémoire de travail d’un tour à l’autre

L’agent exécute une vérification de déploiement. Vous demandez : « Pourquoi cela a-t-il échoué ? » Une question de suivi raisonnable, à condition que l’agent puisse encore voir à quoi « cela » fait référence.

Notre Agent API prend en charge deux façons de transmettre le contexte de la conversation d’un tour à l’autre :

• Rejouer vous-même la conversation : incluez les messages précédents dans le tableau input de la requête suivante. Vous décidez de ce que vous conservez, résumez, masquez ou supprimez avant l’envoi.
• Poursuivre à partir d’une réponse terminée : enregistrez son ID et transmettez-le en tant que previous_response_id avec le message suivant. Nous conservons l’état de la conversation côté serveur, votre application n’a donc pas à renvoyer les tours précédents. Vous pouvez poursuivre à partir de la dernière réponse de la chaîne.

Le rejeu vous permet de contrôler ce que l’agent voit, tandis que la poursuite par ID vous évite de reconstituer la conversation. Dans les deux cas, fournissez les nouvelles instructions, les nouveaux outils ou les nouveaux paramètres de modèle nécessaires à la réponse suivante.

Utiliser votre propre stockage épisodique et sémantique

C’est la partie que l’Agent API vous laisse gérer.

Une première option est l’appel de fonctions. Vous définissez les outils, l’agent demande un appel, et votre application l’exécute et renvoie le résultat. Pour la mémoire, un point de départ simple consiste à effectuer une opération de lecture avant que l’agent agisse et une opération d’écriture ensuite.

Si vous ne consignez que le fait récupéré par l’agent, vous ne savez toujours pas s’il a été utile. Consignez le résultat, la source et tout ce que l’utilisateur a corrigé, et vous tenez le début d’une couche épisodique.

Notre prise en charge de MCP vous offre une autre option. Si un serveur MCP distant compatible expose les opérations dont vous avez besoin, l’agent peut les appeler sans que vous ayez à encapsuler chacune d’elles dans une fonction personnalisée.

Nos connecteurs donnent à l’agent accès aux éléments sur lesquels reposent les souvenirs. GitHub, Slack, Google Drive, Datadog, Linear et Notion figurent dans notre catalogue géré, et vous pouvez ajouter des connecteurs personnalisés pour vos systèmes internes.

Enfin, décidez quand l’historique est examiné et quand la version actuelle est révisée.

Tester ce qui subsiste dans une nouvelle session

Fermez maintenant la conversation. Lancez une nouvelle requête sans rejouer les anciens messages ni transmettre previous_response_id, mais donnez à l’agent accès au même stockage de mémoire. Demandez-lui d’effectuer une tâche connexe sans répéter la correction.

S’il a besoin qu’on le lui rappelle, vous n’avez pas encore terminé.

Pour l’agent de déploiement, créez quelques tests autour de ce qui doit être conservé :

• La correction persiste : il récupère et utilise la commande de rollback vérifiée pour le service concerné.
• La correction reste dans son périmètre : il ne touche pas aux procédures des autres services.
• Les nouvelles informations remplacent les anciennes consignes : lorsque la commande change à nouveau, il utilise la version actuelle et peut remonter jusqu’à la source du changement.

Notre guide pratique sur les tests de régression montre comment enregistrer les sorties de l’agent et les éléments récupérés, les confronter au comportement attendu et comparer les exécutions après avoir modifié des instructions ou des modèles.

Gardez les versions du modèle, du Profil et de la Skill fixes lorsque vous comparez des exécutions avec et sans mémoire. Démarrez chaque comparaison à partir d’un instantané connu du stockage ; sinon, un test risque d’apprendre à l’agent la réponse au suivant.

En cas d’échec, enregistrez le cas. La prochaine modification devra le réussir.

Ou passez-vous du développement : Brain dans Computer

Si ce que vous voulez, c’est la boucle complète plutôt que ses composants, c’est Computer. Brain fonctionne en coulisses, en apprenant à partir de quatre sources : vos sessions, les outils connectés, les fichiers et artifacts que vous créez, et vos corrections. Les mises à jour en arrière-plan de Brain renforcent ce qui reste valable, révisent ce qui a changé et signalent les informations obsolètes.

Vous n’avez pas à construire cette boucle vous-même. Il vous suffit de faire votre travail.

La Mémoire conserve les préférences et les informations que vous avez partagées. Brain relie les projets, les personnes, les décisions et le travail en cours aux éléments qui les étayent.

Vous pouvez consulter ce qu’il a appris dans la vue Mémoire, retracer l’origine des entrées, puis les modifier ou les supprimer. Brain s’appuie sur votre propre activité, exclut les sessions en navigation privée et dispose de son propre bouton d’activation.

Agrandir

Chez Rho, par exemple, les décisions d’un projet de facturation étaient éparpillées entre Slack, Notion, Jira, Figma et Google Docs. L’équipe a configuré Computer pour qu’il examine les modifications pendant la nuit, signale les incohérences et publie un briefing matinal dans Slack.

Leur ingénieur logiciel, Oktawian Jurkiewicz, a remarqué que Computer construisait aussi une mémoire pour le projet. « Nous ne l’avons pas définie », explique-t-il. « Computer a compris tout seul quelles données il devait conserver à partir de chaque source. »

L’équipe indique avoir réduit le temps de réunion hebdomadaire de 2,5 heures à 15 minutes et estime avoir économisé 120 heures de travail sur les 12 semaines du projet.

Ces 120 heures sont attribuées à l’ensemble du flux de travail : connecteurs, exécutions nocturnes et briefing Slack. Quelle part du temps gagné revient à la seule mémoire ? Nous ne pouvons pas encore la quantifier.

Mais ce que nous pouvons vous conseiller pour votre propre développement, c’est de revenir au test évoqué plus haut : exécutez des tâches équivalentes avec et sans la couche de mémoire, puis comparez les taux d’achèvement, le coût et le temps, y compris le temps passé par quelqu’un à corriger le résultat.

FAQ sur la mémoire des agents IA

Les agents IA peuvent-ils avoir une mémoire ?

Oui. Les agents IA peuvent conserver des informations d’une session à l’autre grâce à des conversations, des faits, des préférences et des procédures réutilisables stockés. Le système doit récupérer ces informations lorsqu’elles sont pertinentes et les mettre à jour lorsque la situation évolue.

Brain dans Perplexity Computer, par exemple, construit un contexte de travail à partir des sessions, des outils connectés, des fichiers et des corrections de l’utilisateur.

Combien de RAM un agent IA utilise-t-il ?

Il n’existe pas d’exigence unique. Si votre agent appelle un modèle hébergé via la Perplexity Agent API, vous n’avez pas besoin de charger ce modèle dans votre propre RAM. Votre application et vos outils locaux ont tout de même besoin de mémoire.

L’exécution d’un modèle en local est différente. À quatre bits par paramètre, huit milliards de paramètres représentent environ 4 Go de données de poids brutes. La mémoire réellement nécessaire est plus élevée si l’on tient compte de la surcharge liée à la quantification, du traitement du contexte et du logiciel qui exécute le modèle.

Quelle est la meilleure mémoire pour un agent IA ?

La meilleure configuration dépend de ce que l’agent doit conserver. Un état de conversation permet les questions de suivi ; les enregistrements épisodiques préservent ce qui s’est passé ; la mémoire sémantique contient les connaissances actuelles ; la mémoire procédurale fournit des instructions réutilisables.

La plupart des travaux au long cours bénéficient d’une combinaison. Pour Brain, nous utilisons un wiki interconnecté et appuyé sur des sources. Pour votre propre développement, vérifiez si la configuration aide l’agent à accomplir ses tâches, à appliquer les corrections et à retirer les consignes obsolètes.