Explication de la mémoire des agents : mémoire de travail, épisodique, sémantique et procédurale

Un agent de codage a un jour corrigé le même bug lors de deux sessions consécutives. Personne ne le lui avait demandé, et il n’y avait aucun problème avec le modèle.

Lors de la première session, l’agent a pris en charge le ticket BUG-142, a identifié la cause du dysfonctionnement dans l’ordre d’exécution des migrations, a modifié le code, a exécuté les tests d’intégration et a vu ceux-ci réussir. Puis la session s’est terminée.

Avant la session suivante, le système a effacé l’historique de la conversation afin de réduire les coûts liés aux tokens. C’était un choix judicieux, car rejouer un transcript de plus en plus long coûte de l’argent, augmente la latence et encombre le message d’instruction. Mais ce n’était pas le seul élément qui a disparu. Les résultats des tests réussis n’existaient que dans l’ancienne fenêtre de contexte. Aucun enregistrement n’indiquait que le bug avait été résolu, et le suivi des tâches continuait de lister BUG-142 comme en cours.

Ainsi, la deuxième session a commencé : j’ai vu un ticket ouvert et j’ai fait ce que demandait ce dernier. J’ai mené une enquête, abouti à la même conclusion et appliqué la même correction.

Le modèle n’avait pas oublié comment résoudre le problème. Le système n’avait pas réussi à conserver le fait que le problème avait été résolu.

Ce défaut remet en question la question habituelle. Au lieu de se demander comment donner une mémoire à un agent, il faut se demander quel type d’informations devrait survivre au-delà de la session. Y répondre conduit à quatre tâches distinctes :

• Mémoire de travail : la tâche en cours.
• Mémoire épisodique : ce qui s’est passé et quand.
• Mémoire sémantique : ce qui est reconnu comme vrai.
• Mémoire procédurale : la manière dont les choses doivent être faites.

La mémoire n’est pas une entité unique. Elle remplit au moins quatre fonctions, et la plupart des bugs de mémoire proviennent de leur confusion. Cette division s’inspire de la science cognitive et se retrouve dans des recherches comme CoALA (Cognitive Architectures for Language Agents), qui décrit les agents linguistiques en termes de mémoire modulaire, d’actions structurées et d’un processus de décision.

Au lieu d’examiner ces quatre fonctions une par une, deux autres concepts doivent être distingués de la mémoire elle-même : la fenêtre de contexte et l’état officiel de l’application.

La fenêtre de contexte est un espace de travail

Le contexte correspond à tout ce que le modèle peut voir lors d’une seule requête d’inférence. Il inclut généralement des instructions système, des définitions d’outils, des messages récents, des documents récupérés, les fichiers en cours d’édition, les résultats des outils et le plan actuel. C’est l’espace de travail actif de l’agent.

Ce stockage est également temporaire. Lorsqu’une session se termine, une conversation est compressée ou les messages anciens sont supprimés pour respecter un budget de tokens ; le contenu disparaît à moins que l’application ne le sauvegarde délibérément ailleurs. Un modèle n’a aucun souvenir privé des appels précédents. Soit l’application reprend ces informations, soit elle relie le modèle à un stockage externe.

C’est pourquoi une fenêtre de contexte plus large ne constitue pas une mémoire à long terme. Une plus grande fenêtre de contexte représente un espace de travail plus vaste, et non un classeur. Plus de matériel reste visible pendant que l’agent travaille, mais une fois cet espace vidé, tout y disparaît, à moins que quelque chose ne classe d’abord les éléments importants.

Dans cet incident, la solution efficace se trouvait sur l’espace de travail sans que rien ne la mette en avant. Néanmoins, conserver l’intégralité de la transcription n’aurait pas résolu le problème, car une deuxième distinction avait été négligée.

La mémoire n’est pas la vérité actuelle du système

Comparez deux affirmations. L’une est une mémoire : « BUG-142 a été corrigé lors de la session d’hier. » L’autre correspond à l’état de l’application : le champ d’état du ticket indique COMPLETED.

Ils sont liés, mais ce sont des choses de types différents. Le premier est un enregistrement historique indiquant qu’un événement s’est produit. Le second constitue la source de vérité actuelle du suivi. La mémoire enregistre ce qui s’est passé, tandis que l’état enregistre ce qui existe à cet instant.

Cette lacune est importante car les souvenirs deviennent obsolètes, restent incomplets ou s’avèrent erronés. Imaginez que l’agent récupère une note indiquant que BUG-142 est en cours de traitement. Cette note pouvait être exacte au moment où elle a été écrite, mais elle ne prouve rien concernant la situation actuelle. Avant d’agir en fonction d’elle, l’agent devrait consulter le suivi des tâches, examiner le dépôt de code, exécuter les tests pertinents ou essayer de reproduire le problème. Un souvenir récupéré n’est qu’une affirmation sur le passé, pas une preuve du présent.

L’incident initial a échoué à deux reprises. Aucun enregistrement utile concernant la correction apportée n’a été conservé, et l’état officiel de la tâche n’a jamais été mis à jour. Une fois cela clarifié, nous pouvons déterminer ce que l’agent devait réellement conserver.

Mémoire de travail : la tâche en cours

La mémoire de travail contient ce dont l’agent a besoin pour poursuivre la tâche en cours, et peu d’autre chose. Pour BUG-142, elle peut inclure la tâche elle-même, l’hypothèse actuelle (le tableau de dépendances est initialisé trop tard), l’étape en cours (exécuter le jeu d’outils d’intégration), la dernière observation (trois tests de migration échoués) ainsi que les fichiers qui sont en cours d’édition.

Elle répond à des questions pratiques : quel est l’objectif ? Quelle étape est en cours ? Qu’a renvoyé la dernière appelée d’outil ? Quels fichiers ont été modifiés ? Qu’est-ce qui n’est pas encore terminé ?

En pratique, elle se trouve dans la requête, dans un objet d’état de l’agent, dans un point de contrôle du flux de travail ou dans un stockage de session à durée de vie courte. Elle est temporaire et liée à une seule tâche ; elle n’est pas conçue pour constituer un registre durable de tout ce que le système a appris. La description donnée par IBM de la mémoire à court terme est similaire : des informations récentes utilisées pour prendre des décisions immédiates et assurer la continuité de la conversation.

La mémoire de travail diffère également des trois autres types. Les mémoires épisodique, sémantique et procédurale peuvent persister entre les sessions, tandis que la mémoire de travail décrit ce qui est actif en ce moment même, qu’il soit conservé dans la mémoire ou stocké temporairement à proximité.

Sa durée de vie courte n’est pas un défaut. Une fois la tâche terminée, il y a rarement de raison de conserver chaque hypothèse intermédiaire, chaque fragment à moitié écrit, chaque commande échouée ou chaque idée abandonnée. Les problèmes commencent lorsque un résultat important n’existe que dans cette mémoire temporaire. Dans cet incident, deux éléments ont disparu : le résultat du test et le fait que BUG-142 avait été corrigé. Le système a traité un résultat important comme de l’espace temporaire jetable.

La mémoire de travail soutient l’exécution. Elle ne doit jamais être le seul enregistrement du travail achevé.

Mémoire épisodique : le registre des événements

La mémoire épisodique stocke des expériences spécifiques. Un épisode est plus qu’un simple fait : il s’est produit dans une situation particulière, généralement avec un moment précis, une action et un résultat.

Pour BUG-142, un épisode utile pourrait être décrit sous forme d’un bref enregistrement structuré :

• Événement : BUG-142 reproduit lors de l’initialisation de la migration.
• Contexte : le tableau des dépendances n’était pas disponible au démarrage du service.
• Action : modification de l’ordre d’exécution des migrations.
• Résultat : les tests d’intégration ont réussi.
• Preuve : commit a7f43d2.
• Heure : 8 septembre 2026, 14:20.

Un tel enregistrement indique à un futur agent que cette situation s’est déjà produite. Il permet d’éviter le travail répétitif, fournit des exemples et montre quels essais antérieurs ont fonctionné ou non. CoALA distingue la mémoire épisodique de la mémoire sémantique, car un enregistrement d’une expérience a une fonction différente de celle des connaissances généralisées.

Un épisode n’est pas non plus identique à l’historique de chat. Une transcription peut contenir des centaines de messages, des résultats d’outils, des spéculations, des corrections et des répétitions. Il suffit de tracer une ligne séparative depuis le journal brut, par exemple « nous devrions probablement vérifier l’ordre d’initialisation », à côté d’un épisode résumé : le réordonnancement de l’initialisation des dépendances a résolu le BUG-142, et les tests ont donné un résultat positif lors du commit a7f43d2. Ce dernier est bien plus facile à retrouver et beaucoup plus utile pour une tâche ultérieure.

La mémoire épisodique peut encore fonctionner de manière erronée de deux manières. Le système peut conserver l’action mais oublier le résultat. Une simple indication du type « tentative effectuée : ordre de migration modifié » laisse l’agent futur incertain quant à la nécessité de réessayer. Ou bien l’agent peut retrouver une information sur une action réussie il y a six mois, après que l’architecture ait changé. La mémoire épisodique conserve le passé sans décrire le présent, c’est pourquoi chaque épisode doit inclure son moment, son contexte, ses preuves et son résultat.

Mémoire sémantique : ce que l’agent sait

Un épisode enregistre ce qui s’est passé. La mémoire sémantique enregistre ce qui a été appris à partir de cela.

L’épisode lié au BUG-142 peut fournir un fait réutilisable : le service de migration a besoin que le tableau de dépendances existe avant le démarrage de l’initialisation. Il ne s’agit plus d’une seule session de débogage, mais d’une affirmation générale concernant le système.

Les éléments typiques incluent la base de données utilisée par le service, une limite de vitesse pour les API, une règle stipulant que les identifiants des clients ne doivent pas figurer dans les journaux, le schéma architectural du répertoire, la préférence d’un utilisateur pour des réponses techniques concises, ainsi qu’une exigence selon laquelle les scripts de migration doivent rester compatibles avec les versions antérieures. La mémoire sémantique couvre les faits, les concepts, les contraintes, les relations et les préférences. Elle a tendance à durer longtemps, mais doit rester révisable, car les faits et les préférences changent.

La différence avec la mémoire épisodique est subtile mais importante à retenir. La version épisodique indique que le BUG-142 est survenu hier parce que la table des dépendances manquait au démarrage. La version sémantique précise que l’initialisation exige d’abord l’existence de cette table. L’une se souvient de l’expérience, l’autre se souvient de la leçon à en tirer.

Sa défaillance caractéristique est le désuétude. Supposons que l’équipe adopte par la suite un nouveau mécanisme d’initialisation qui ne dépend plus de la table. Si le système de mémoire se contente d’ajouter le nouveau fait, l’agent peut récupérer les deux informations : l’une indiquant que la table doit exister en premier, et l’autre affirmant que cela n’a plus d’importance. Il y a alors de la mémoire sans clarté. Un fait obsolète peut être pire qu’aucun fait, car l’agent agira en se fiant à lui avec confiance.

Ainsi, la mémoire sémantique a besoin d’un mécanisme de correction, avec des réponses à quelques questions. Quelqu’un doit être responsable des mises à jour d’un fait. Elle nécessite une source identifiée ainsi qu’une date de dernière vérification. Lorsqu’une version plus récente apparaît, l’ancienne doit être marquée comme remplacée, puis soit supprimée, soit conservée en tant qu’historique. Ce sont là des aspects propres à l’ingénierie de la mémoire. Pour l’instant, l’essentiel est que la mémoire sémantique conserve des connaissances réutilisables, et non simplement un enregistrement d’un événement.

Mémoire procédurale : comment les tâches sont accomplies

La mémoire procédurale indique à l’agent comment exécuter une tâche. Elle contient des compétences, des flux de travail, des règles opérationnelles et des méthodes reproductibles.

A partir d’un bug, une équipe peut dégager une procédure : avant de lancer l’initialisation de la migration, vérifier que le tableau des dépendances est disponible ; exécuter les tests d’intégration de la migration ; enregistrer le résultat ; mettre à jour le suivi des tâches ; joindre la référence du commit ; confirmer que le problème ne se reproduit plus.

Ce n’est pas un fait en soi, bien qu’il en découle. Le fait sémantique est que la table doit exister avant l’initialisation. La règle procédurale consiste à vérifier son disponibilité avant d’initialiser. La mémoire sémantique indique ce qui est vrai, tandis que la mémoire procédurale précise ce qu’il faut faire. Autres exemples : annuler une déploiement raté, enquêter sur un échec de paiement, quels tests doivent être réussis avant de clôturer une erreur, comment examiner une demande de fusion de code, quand demander l’approbation humaine et quel outil doit être utilisé avant d’accéder aux données de production.

Les implementations vont des instructions claires et des manuels mis à jour en version jusqu’aux compétences emballées, aux définitions de flux de travail, au code brut ou aux modèles appris par la pratique. CoALA accorde aux procédures une place propre dans la mémoire de l’agent, liée à la fois aux capacités du modèle et au code explicite de l’agent.

Pour cette raison, les procédures doivent être versionnées comme du logiciel et non accumulées comme un historique de conversations. Lorsqu’une organisation modifie son processus de déploiement, l’agent ne devrait pas récupérer cinq anciennes procédures pour essayer de déterminer laquelle est en vigueur. Tout ce qui fonctionne en production doit indiquer à qui il appartient, quelle est sa version, depuis quand il s’applique, ce qu’il couvre, ce qui le remplace et comment on sait qu’il fonctionne encore.

Dans cet incident, l’absence d’une procédure a eu un impact direct. L’agent a corrigé le code, mais aucune règle ne prévoyait de transformer ce succès en un état mis à jour de l’application. Ce qui manquait, ce n’était pas une retranscription de toute la conversation, mais plutôt une instruction claire du type : une fois les tests réussis, noter le résultat et fermer le ticket. C’est là une lacune procédurale.

Un bug, cinq représentations

La taxinomie est la plus facile à comprendre en notant le même bug de cinq manières différentes.

• Mémoire de travail : « Nous corrigeons actuellement BUG-142 ; l’étape suivante consiste en des tests d’intégration. » Elle permet de poursuivre l’exécution en cours.
• Mémoire épisodique : « Lors de la première session, BUG-142 a été corrigé en modifiant l’ordre des dépendances, et les tests ont réussi. » Elle conserve une expérience vécue.
• Mémoire sémantique : « Le service de migration a besoin de sa table des dépendances avant d’être initialisé. » Elle conserve des connaissances réutilisables.
• Mémoire procédurale : « Avant d’initialiser les migrations, vérifiez la table et exécutez les tests d’intégration. » Elle conserve une méthode reproductible.
• État autoritaire : statut COMPLETED, commit a7f43d2, tests PASSED. Il enregistre ce que l’application considère comme vrai.

Ils sont liés mais ne sont pas interchangeables. L’épisode ne remplace pas le dossier de tâche, et le dossier de tâche ne contient pas tout ce qui a été appris au cours de l’incident. Ce fait ne définit pas toute la procédure de débogage, et cette procédure ne prouve pas qu’un bug donné a été corrigé. On ne peut pas s’attendre à ce que la mémoire de travail survive à la session.

Le système n’a pas seulement échoué à se souvenir d’une chose : il a également échoué à transformer le travail terminé en formes durables appropriées.

Chaque type se dégrade à sa manière

Si tout est stocké dans un seul espace non différencié, le diagnostic devient difficile. Il vaut mieux se demander quelle tâche d’information a échoué.

• La mémoire de travail échoue lorsque l’agent perd son plan actuel après un réinitialisation, généralement parce que l’avancement de la tâche n’était stocké que dans la fenêtre ou dans un processus local.

La mémoire épisodique échoue lorsque l’agent répète une expérience ou refait un travail déjà terminé, car l’événement, l’action ou le résultat antérieur n’a pas été enregistré ni récupéré.

La mémoire sémantique échoue lorsque l’agent applique avec assurance un fait obsolète, car ce fait a changé et la version ancienne n’a jamais été remplacée.

La mémoire procédurale échoue lorsque l’agent termine le travail technique mais omet une étape opérationnelle, car le flux de travail était manquant, obsolète, ambigu ou indisponible.

L’état autoritaire échoue lorsque l’agent agit en fonction d’un statut de tâche incorrect, car le registre source de vérité n’a pas été mis à jour ni vérifié.

Chaque tâche mérite ses propres règles concernant les personnes autorisées à écrire, la manière dont les éléments sont récupérés, la durée pendant laquelle ils sont conservés, la façon de corriger les erreurs et l’évaluation de la qualité. Un index vectoriel peut aider à récupérer plusieurs types de mémoire, mais l’index ne décide pas du type de contenu. Une règle pratique : classer les informations avant de choisir la technologie de stockage.

Une courte liste de contrôle pour la classification

Lorsqu’un agent rencontre une information, posez ces questions dans cet ordre.

1. Est-elle nécessaire uniquement pour l’exécution en cours ? Mémoire de travail. Pensez au plan actuel, au résultat le plus récent d’un outil ou à une hypothèse temporaire.
2. S’agit-il d’un événement spécifique qui s’est produit ? Mémoire épisodique. Une déploiement qui a échoué hier, une tentative de réparation qui n’a pas fonctionné, un design rejeté par l’utilisateur.
3. S’agit-il de connaissances réutilisables ? Mémoire sémantique. Architecture, préférences, contraintes de domaine, définitions métier.

S’agit-il d’un flux de travail, d’une règle ou d’une compétence ? Une mémoire procédurale : une procédure de déploiement, une liste de contrôle pour les tests, une politique d’utilisation des outils ou un parcours d’escalade.

S’agit-il de la source de vérité actuelle ? L’état autoritaire de l’application : le statut d’une demande, le solde du compte, l’état du déploiement, l’inventaire, le statut d’approbation.

Une même expérience mérite souvent plusieurs représentations. Un déploiement échoué peut donner naissance à un épisode (il a échoué à 14:20), à un fait (le service X nécessite la version 17 du schéma), à une procédure (vérifier la compatibilité des schémas avant de déployer) et à un changement d’état (le déploiement a été annulé). Ce n’est pas une duplication inutile, car chaque forme répond à une question différente.

Ce que le système aurait dû faire

Le contexte n’avait jamais besoin de durer éternellement. Ce que le système devait faire, c’était favoriser des résultats importants avant de terminer la session : écrire l’épisode, extraire les faits le cas échéant, ajouter ou mettre à jour la procédure, et définir l’état du ticket avec les preuves de validation correspondantes.

Avec cela en place, il est possible d’éliminer l’ancienne conversation en toute sécurité. La transcription brute peut être supprimée, car tout ce qui mérite d’être conservé a déjà été transformé sous des formes destinées à survivre. Le contexte peut disparaître, mais les résultats importants ne devraient pas disparaître avec lui.

Où cela mène

La classification est le point de départ, et ce sont les problèmes d’ingénierie plus complexes qui suivent. Quelles informations méritent d’être stockées ? Où chaque type doit-il être conservé, et qui a le droit de le modifier ? Quand sont-elles récupérées, et comment entrent-elles dans le système ? Quand sont-elles mises à jour, et à quel moment deviennent-elles obsolètes ? Que se passe-t-il lorsque deux sources de mémoire sont en désaccord, et comment évaluer si la mémoire a réellement amélioré l’agent ?

Ces questions constituent l’ingénierie de la mémoire, et aucune d’entre elles ne peut être correctement répondue avant que les informations n’aient été classées. Ainsi, avant de choisir une base de données vectorielle, un cadre de mémoire ou une stratégie de récupération, demandez-vous quel type d’informations l’agent tente de préserver.

L’objectif n’est pas de faire en sorte qu’un agent se souvienne de tout. Il s’agit plutôt de garantir que les informations utiles survivent, stockées sous une forme adaptée à leur utilisation future. Viennent ensuite les étapes du cycle de vie que suit la mémoire : l’expérience, l’extraction, une décision quant à ce qui doit être conservé, le stockage, la récupération, l’insertion dans le contexte, la vérification, l’action, et enfin la mise à jour ou l’oubli.