Pourquoi nos agents d'IA dorment : construire une mémoire qui se met à jour toute seule

En mars, vous donnez à un agent l'adresse du serveur de préproduction. En juin, le serveur déménage et vous lui donnez la nouvelle adresse. Une mémoire qui se contente d'accumuler les informations possède désormais les deux. La première n'est pas fausse, à proprement parler. Elle était vraie à l'époque. Mais de temps en temps, l'agent la choisira avec une assurance totale, comme quelqu'un qui vous indique le chemin d'un restaurant fermé depuis des années.

C'est le problème de la plupart des systèmes de mémoire pour agents d'IA. Faire en sorte qu'un agent se souvienne est facile. Les ennuis commencent quand ses souvenirs ne sont plus à jour.

Nous avons fini par intégrer notre propre mémoire à Sno Station. Je n'en avais pas particulièrement envie. Il existe déjà de bons outils de mémoire, certains avec des dizaines de milliers d'étoiles sur GitHub, et le monde n'a pas besoin d'un dixième fournisseur de mémoire. Ce n'est pas ce que nous cherchons à devenir. Mais nous avions besoin de trois choses, et nous ne les avons pas trouvées réunies.

Une mémoire pour tous les agents

La première chose est simple à dire. Nous utilisons plusieurs agents : Claude Code, Codex, parfois OpenClaw et Hermes. Chacun a sa propre conception de la mémoire, et la mémoire de chacun s'arrête à sa porte.

Vous dites donc à Claude Code que l'équipe déploie le jeudi, et le vendredi, Codex ne le sait pas. C'est vous qui transmettez l'information de l'un à l'autre. Vous êtes le câble.

Dans Sno Station, chaque personne dispose d'un seul espace de stockage de mémoire, chiffré et situé sur sa propre machine. Chaque agent y lit et y écrit au moyen d'un petit plugin. Ce plugin enregistre discrètement ce qui mérite d'être conservé pendant que vous travaillez et rappelle ce qui est utile au début d'une session. Sous le capot, un seul composant écrit dans ce stockage, si bien que deux agents ne peuvent pas écraser leurs données respectives.

C'est aussi ce qui permet le passage de relais. Supposons qu'un agent atteigne son quota au milieu d'une tâche et que l'autre prenne la suite. Le second ne part pas de zéro. Il sait ce que savait le premier. Sans mémoire partagée, passer le relais revient simplement à demander à un second agent de vous faire tout réexpliquer.

Et cela signifie que la mémoire vous appartient, plutôt qu'à un environnement d'exécution. Remplacez l'agent par un autre l'année prochaine : ce qu'il a appris sur vous et sur votre travail restera en place.

Remplacer au lieu d'empiler

La deuxième chose, c'est le serveur de préproduction.

Beaucoup de systèmes de mémoire se contentent d'ajouter. Chaque nouveau fait rejoint la pile. Rien n'en sort. La démonstration se passe bien. Quelques mois plus tard, vous avez changé de travail, l'API a changé, et l'agent se souvient encore de votre ancien patron. Une mémoire qui ne fait qu'ajouter conserve toutes les versions et laisse le modèle faire le tri au pire moment.

La nôtre fonctionne autrement, selon une règle stricte. Lorsqu'un nouveau fait contredit un ancien, un modèle examine les deux et donne l'une de trois réponses : remplacer, conserver ou incertain. Il n'a pas d'autre réponse possible. Le modèle porte le jugement. Du code ordinaire fait le reste. L'ancien souvenir est marqué comme retiré, le nouveau prend sa place, et seuls les souvenirs actuels sont présentés à un agent.

Le modèle ne dispose d'aucun bouton de suppression. J'insiste là-dessus. Il ne peut rien enlever de lui-même, et un souvenir retiré reste disponible si vous devez un jour vérifier ce qui était vrai autrefois. C'est un peu comme la différence entre barrer une ligne dans un registre et en arracher la page.

Quelle est la fiabilité du jugement ?

Le jugement est la partie risquée. Si le modèle remplace un fait qu'il aurait dû conserver, vous perdez quelque chose de vrai. C'est pire que le désordre.

Nous avons donc entraîné un petit modèle à nous pour cette seule décision, puis l'avons comparé à un modèle de pointe issu d'un grand laboratoire. Même épreuve pour les deux : 223 paires de faits, un ancien et un plus récent, avec pour chacune une bonne réponse connue.

Notre modèle a choisi la bonne action dans 97,5 pour cent des cas. Le modèle de pointe, dans 96,8 pour cent.

Le chiffre qui m'importe davantage concerne les remplacements erronés, les cas où un fait vrai aurait été écarté. Notre modèle l'a fait dans 3,2 pour cent des cas. Le modèle de pointe, dans 4,1 pour cent.

Je ne veux pas en faire trop. C'est une petite épreuve, 223 questions, datant de juin, et les deux modèles y sont proches du maximum. Nous en avons depuis préparé une plus difficile. Ce n'est pas non plus une comparaison avec d'autres outils de mémoire. Nous ne l'avons pas encore faite, et je ne vais pas citer les chiffres de quelqu'un d'autre comme si c'étaient les nôtres.

Ce que cela nous indique, c'est qu'un petit modèle tournant sur une seule carte graphique peut prendre cette décision à peu près aussi bien que les plus grands. C'est important parce que ce jugement intervient constamment et qu'il porte sur des choses que vous préféreriez ne transmettre à personne.

Pourquoi dormir ?

La troisième chose concerne le moment où ce travail s'effectue.

Vous ne pouvez pas faire tout cela pendant que l'agent travaille. Chaque nouveau fait impose de repasser sur tout ce dont l'agent se souvient déjà. C'est lent, et l'agent a une tâche à finir. Le gros du travail se fait donc lorsque les agents sont inactifs.

En interne, nous appelons cette passe REM, du nom de la phase du sommeil pendant laquelle les gens semblent classer les événements de la journée. J'ai d'abord résisté à ce nom. Je le trouvais un peu mignon. Mais il est juste. La passe parcourt les sessions de la journée. Les anciens faits sont retirés et les contradictions sont réglées. Il reste ensuite moins de choses à mémoriser, et celles qui restent correspondent mieux à votre façon de travailler aujourd'hui. La mémoire est censée diminuer pendant la nuit, à l'inverse d'une pile.

Vous choisissez quelle quantité de ces données quitte votre machine. Avec le réglage le plus privé, aucune ne la quitte. Le modèle de votre propre agent se charge de la consolidation et tout reste en local. Avec le réglage par défaut, ce sont les abonnements de vos agents qui fournissent la capacité de réflexion. Et si vous y consentez, nos modèles prennent les décisions les plus difficiles, comme celle de remplacer ou de conserver un fait évoquée plus haut.

Je dois préciser où nous en sommes. Le stockage partagé et la règle de remplacement sont utilisés ici tous les jours. La passe de sommeil est l'élément le plus récent et, sur nos propres machines, elle ne s'exécute pas encore toutes les nuits. Elle s'ignorait elle-même à cause d'une erreur de configuration, que nous sommes en train de corriger. Je préfère vous le dire plutôt que de vous laisser le découvrir.

Pourquoi tout repose dessus

Voici ce que je n'avais pas compris au départ. Je pensais que la mémoire était une fonctionnalité. Elle ressemble davantage à un plancher.

La revue nocturne, durant laquelle les agents relisent leurs propres sessions et consignent des leçons, a besoin d'un endroit où conserver ces leçons. Le passage de relais entre agents en a besoin aussi. Il en va de même pour un historique de ce qu'un agent a fait et de la fréquence à laquelle il a réussi du premier coup. Plus tard, tout ce que nous construirons dans le cloud sera tiré de ce que contient cette base.

Rien de tout cela ne vaudrait la peine d'être construit sur une pile qui ne fait que grandir. Il faut une mémoire qui puisse se tromper le lundi et être corrigée le mardi, sans qu'une personne ait à intervenir.

Quand la mémoire se trompe, l'agent suivant hérite de l'erreur et vous devez la réexpliquer.

Jusqu'au prochain déménagement du serveur.

Sno Station est open source. Vous le trouverez sur sno.ai.