TL;DR : La plupart des agents se réinitialisent et oublient tout. Voici la pile mémoire exacte que j'ai construite pour que mes agents partagent le contexte entre les redémarrages, se coordonnent sans se marcher sur les pieds et conservent les décisions pendant des mois.
Le problème que personne ne résout
Voici la configuration mémoire typique d'un agent IA. Mettre les choses importantes dans le prompt système. Espérer que la fenêtre de contexte ne s'épuise pas. Redémarrer et tout perdre.
J'ai fait fonctionner deux agents coordonnés (Ella sur OpenClaw, Lyra sur Hermes) à travers des centaines de sessions pendant 6 mois. Le plus grand facteur qui les rend utiles, ce ne sont pas les modèles ou les outils. C'est l'architecture mémoire.
Quand Lyra déploie un correctif à 2h du matin, Ella le sait au matin. Quand j'ai décidé en janvier comment les secrets devaient être stockés, les deux agents suivent toujours cette décision en juillet. Quand une session plante en plein milieu d'une tâche, la suivante reprend exactement là où elle s'est arrêtée.
Voici le système exact en 4 couches.
Couche 1 : Contexte intra-session
Chaque session commence par la lecture de deux fichiers. Le fichier d'identité est l'identité permanente de l'agent. Pas un prompt système enfoui dans la configuration. Un vrai fichier Markdown que je peux modifier. Il contient comment l'agent doit se comporter, ce qu'il priorise, ce qu'il ne fait jamais sans demander, et sa relation avec les autres agents.
Le fichier d'index mémoire est l'index de tout ce qui mérite d'être retenu entre les sessions. Pas une base de données vectorielle. Pas d'embeddings. Une simple table des matières pointant vers des fichiers mémoire individuels. Chaque fichier mémoire est une courte note avec un nom, une description, un type et un bref contenu. L'index est toujours chargé. Les fichiers individuels sont lus à la demande lorsqu'ils sont pertinents.
Pourquoi le Markdown ? Parce que je peux le lire, le modifier et le déboguer. Quand un agent commence à mal se comporter, j'ouvre l'index et je trouve la mauvaise instruction. Quand je veux changer un comportement, je modifie le fichier. Pas d'API. Pas de tableau de bord. Pas de réentraînement.
Couche 2 : Rétention post-session (Hindsight)
Le problème de la mémoire uniquement en Markdown : elle ne capture que ce que quelqu'un écrit explicitement. Le contexte le plus précieux est implicite. Les décisions prises lors d'une exécution. Les faits déduits d'une tâche. Les choses qui se sont avérées importantes.
Hindsight est un backend de rétention de faits locaux fonctionnant sur localhost. À la fin de chaque session significative, l'agent pousse automatiquement un ensemble organisé de faits retenus dans une banque nommée. Chaque agent a sa propre banque.
Ce qui est retenu : les décisions prises pendant la session, les faits non évidents concernant l'utilisateur ou le projet, les schémas d'échec et les correctifs que nous avons adoptés, et les préférences que l'utilisateur a confirmées ou corrigées.
Quand une nouvelle session commence, Hindsight est interrogé pour obtenir le contexte pertinent avant que l'agent ne réponde. Ce n'est pas une recherche en texte intégral sur les transcriptions. Ce sont des faits organisés, étiquetés par type, que l'agent a appris à retenir.
Le chemin promu : fait Hindsight, révision humaine, entrée dans l'index mémoire. Rétention automatique avec une porte d'approbation humaine.
Couche 3 : État partagé à long terme (Nexus)
La mémoire d'un seul agent s'effondre quand on ajoute un deuxième agent. Ils dérivent. L'un pense que X est l'état actuel du projet. L'autre pense Y. En une semaine, ils se contredisent.
La solution est un fichier d'état partagé, inspectable, que les deux agents lisent et écrivent. Nous utilisons un coffre Obsidian que j'appelle Nexus. Il contient un journal de contexte en direct auquel les deux agents ajoutent après chaque tour significatif, un fichier d'état du projet, un journal des décisions, et un point de contrôle du contexte de travail par agent mis à jour toutes les quelques appels d'outils lors de longues tâches.
Le fichier de contexte en direct est la poignée de main en temps réel. L'invariant : avant chaque réponse, lisez-le. Après chaque tour significatif, ajoutez-y.
Quand Lyra termine une PR à 2h du matin et qu'Ella répond à ma question du matin, Ella le sait déjà. Elle a lu le journal. Pas de passage de messages. Pas d'API inter-agents. Pas de scrutation. Un fichier partagé, deux agents, journal en ajout seulement.
Couche 4 : Connaissances consultables (gbrain)
Les trois premières couches gèrent la mémoire épisodique. Ce qui s'est passé, ce qui a été décidé, ce qui est important à retenir. gbrain est la couche sémantique. C'est un wiki compilé fonctionnant comme un serveur MCP sur le coffre Nexus. Recherche en texte intégral et sémantique sur tout ce qui a été écrit.
Quand un agent doit répondre à une question de recherche, trouver une synthèse antérieure, ou chercher comment nous avons traité une classe de problème auparavant, il interroge gbrain au lieu de relire chaque fichier. Le résultat est une liste classée de pages pertinentes avec leur provenance. L'agent lit ce qui est pertinent. Il ne déverse pas tout le coffre dans le contexte.
C'est la différence entre la mémoire et le rappel. Les couches 1 à 3 gèrent ce que l'agent transporte. La couche 4 gère ce que l'agent peut consulter.
L'invariant de synchronisation inter-agents
Deux agents, un fichier de contexte en direct. Le risque : ils s'écrasent mutuellement, ou manquent les entrées de l'autre. L'invariant que nous utilisons : chaque entrée est signée avec le nom de l'agent, le canal, le type et un résumé d'une ligne. Ajout seulement. Ne jamais modifier l'entrée de quelqu'un d'autre. Si Lyra a enregistré quelque chose de pertinent, Ella le reconnaît explicitement dans la réponse suivante. Pour les décisions importantes, les deux agents écrivent également dans le journal des décisions avec un horodatage et une justification.
Cela a fonctionné à travers des centaines de sessions. Nous avons eu un conflit : une condition de concurrence où les deux agents ont ajouté dans la même minute lors d'un transfert. Résolution : lire les deux entrées, les concilier au tour suivant. Aucune fusion automatisée nécessaire.
Ce que cela remplace
Avant cette architecture : cinq sessions de chat déconnectées, chacune avec son propre contexte obsolète. Des agents se contredisant parce qu'aucun ne pouvait voir ce que l'autre savait. Des instructions que j'avais données il y a trois semaines, oubliées. Des décisions qui vivaient dans ma tête au lieu d'un fichier.
Après : deux agents qui se briefent avant chaque réponse. Un journal d'état partagé qu'aucun ne peut nier. Des décisions retenues qui survivent à des mois de réinitialisations de contexte. Chaque préférence de comportement dans un fichier que je peux modifier et vérifier.
Le compromis honnête : ce système exige de la discipline. Vous devez écrire les choses. Vous devez maintenir les fichiers. Vous devez examiner ce qui est retenu avant qu'il ne devienne permanent. Ce n'est pas un système magique toujours actif. C'est une discipline manuelle structurée avec de l'automatisation aux jonctions.
Comment commencer
Vous n'avez pas besoin de deux agents ou d'un coffre complet pour exécuter la version un de cela.
Étape 1 : Un fichier d'identité plus un index mémoire. Créez-les. Lisez-les au début de la session. Écrivez chaque préférence de comportement dans l'index la deuxième fois que vous corrigez l'agent pour la même chose.
Étape 2 : Un fichier d'état partagé. Si vous utilisez plus d'un agent, ou si vous utilisez Claude dans plusieurs fenêtres, créez un fichier de contexte en direct. Chaque session y ajoute à la fin et le lit au début.
Étape 3 : Une règle de rétention. Quand une session produit une décision qui doit survivre, écrivez-la manuellement dans l'index. Faites-le à la main jusqu'à ce que vous ayez confiance dans le modèle. Ensuite, automatisez le signalement.
Étape 4 : Un fichier par fait, pas un gros document. L'index pointe vers des fichiers individuels. Cela facilite la suppression d'un souvenir obsolète sans toucher aux autres.
La pile complète en 4 couches a pris environ 6 mois à stabiliser. Les couches 1 et 3 ont pris un week-end. Commencez par là.
À retenir
La plupart des configurations mémoire des agents sont de la gestion de fenêtre de contexte avec des étapes supplémentaires. Elles fonctionnent jusqu'à ce que la fenêtre se réinitialise ou que vous ajoutiez un deuxième agent.
La mémoire durable des agents est un problème d'infrastructure, pas un problème de conception de prompts. La réponse est des couches multiples avec différents horizons temporels : contexte intra-session, faits inter-sessions, état partagé, connaissances consultables.
Tout le nôtre est en Markdown brut. Pas de base de données vectorielle. Pas d'embeddings. Pas de réentraînement. Juste des fichiers que je peux ouvrir, modifier et déboguer.
Les agents qui sont vraiment utiles ne sont pas ceux avec la plus grande fenêtre de contexte. Ce sont ceux qui se souviennent de ce qui compte et oublient ce qui ne compte pas.
Si vous construisez des agents auxquels vous voulez confier un vrai travail, commencez par l'architecture mémoire avant d'ajouter plus d'outils.
Outils référencés
Hindsight (rétention mémoire locale) : https://github.com/vectorize-io/hindsight
gbrain (wiki compilé / recherche sémantique) : https://github.com/garrytan/gbrain
OpenClaw (environnement d'exécution d'agent) : https://openclaw.ai
Hermes (environnement d'exécution d'agent) : hermes-agent.nousresearch.com
