Les agents ont ignoré la consigne de lire la mémoire dans 7 sessions sur 7 : analyse de 13 000 logs

L'équipe de kaeru, qui développe une mémoire à long terme pour des agents IA comme Claude Code, Codex et Cursor, a publié l'analyse de ses propres logs : plus de 13 000 fichiers de sessions de travail, de juin à septembre. Résultat principal : dans les 7 sessions où l'agent a vu la consigne « tu peux relire les raisonnements enregistrés », il ne les a jamais relus. Pourtant, il a exécuté 751 fois une autre consigne, « relie cette entrée à la précédente ».

Pendant plusieurs mois, les auteurs ont conçu leur produit « au feeling », puis ont vérifié comment les agents utilisent réellement la mémoire. Beaucoup d'hypothèses se sont révélées fausses, et la plupart des conclusions valent au-delà de kaeru : pour quiconque écrit un serveur MCP, des hooks ou de longues instructions pour des agents.

Ce qu'est kaeru et ce qui a été vérifié

kaeru est un serveur local auquel l'agent se connecte via MCP, le protocole standard d'appel d'outils externes. Au fil du travail, l'agent écrit lui-même des entrées : observations, décisions, tâches avec échéance, hypothèses accompagnées du résultat de leur vérification. Les entrées sont reliées entre elles par des liens pondérés, ce qui permet de conserver une chaîne de raisonnement entière.

Un fait corrigé n'est pas écrasé : l'ancienne version est clôturée par une date. À l'entrée dans un projet, l'agent reçoit une synthèse : ce qui est en vigueur, ce qui est en retard, quels raisonnements existent déjà. Tout cela ne fonctionne que si l'agent lit la mémoire avant de poser sa question, enregistre ce qu'il a établi et signale ce qui est périmé.

Les auteurs détaillent honnêtement les limites : il s'agit de leurs propres logs, pas d'un échantillon du marché. Les échantillons varient selon les sections, de milliers d'événements à sept sessions ou aux logs d'un seul utilisateur. L'étude a mesuré le comportement des agents, pas le bénéfice : l'équipe ne sait pas encore combien de temps ou de tokens la mémoire fait économiser par tâche, et prépare son propre benchmark.

La dette est honorée, l'option est ignorée

À l'entrée dans un projet, l'équipe a ajouté la consigne « ce projet contient des raisonnements enregistrés, tu peux les lire ». En quatre jours, le modèle l'a vue dans 7 sessions et ne l'a jamais suivie, alors que, sur la même période, les agents ont enregistré 17 nouveaux raisonnements. Ils sont prêts à écrire, pas à relire.

Une autre consigne, « relie cette entrée à celle dont elle est issue », arrivait juste après l'écriture et a été exécutée 751 fois. C'est l'action la plus fréquente de tout le produit. Dans la version 0.8, le lien se précise directement dans l'appel d'écriture, et une consigne distincte devient inutile. La différence tient au moment : la seconde prolonge ce que l'agent est déjà en train de faire, la première lui demande de lâcher sa tâche pour s'occuper d'autre chose.

La synthèse suit le même schéma. Face à la ligne « 2 entrées en suspens, en attente de décision », les agents ont examiné 8 fois les entrées litigieuses, et les tâches en retard sont clôturées avec régularité. La ligne « tu peux relire les raisonnements enregistrés », elle, n'a jamais déclenché la moindre action. Désormais, tout dans la synthèse est formulé comme une dette.

Hooks, instructions tronquées et paramètres facultatifs

Sur les logs d'un seul utilisateur, 80% des questions de l'agent à l'humain ont été posées sans aucun accès à la mémoire dans les dix minutes précédentes ; la médiane était de 74 minutes depuis la dernière lecture. L'équipe a donc créé un hook, un script que le client exécute à un moment donné. Quand l'agent s'apprête à rendre la main à l'humain, le hook cherche dans la mémoire des éléments sur le sujet et envoie une seule fois l'agent les lire.

La première version repérait une sollicitation de l'humain grâce au signe « ? ». Sur 2 608 arrêts de l'agent, elle a repéré 201 des 1 164 sollicitations, soit 17%.

Dans 856 cas, il s'agissait de demandes à l'impératif : « dis-moi », « envoie le rapport », « j'ai besoin de ta réponse sur le fournisseur ». Les agents demandent plus souvent qu'ils ne questionnent.

La découverte la plus désagréable : le client tronquait l'instruction du serveur MCP à 2 048 caractères, et personne ne l'a remarqué pendant deux mois. Parmi les outils mentionnés avant la coupure, 9% n'étaient pas utilisés. Parmi ceux mentionnés après la coupure, 31% ne l'étaient pas, soit autant que pour les outils absents de l'instruction. Pour le modèle, la fin de l'instruction n'existait tout simplement pas. Aujourd'hui, le texte d'introduction de kaeru occupe 1 499 caractères.

Les paramètres suivent la même logique. Le poids d'un lien était facultatif, avec une valeur par défaut. Sur 6 003 appels aux outils de mémoire, les agents ont créé 1 262 liens et n'ont jamais renseigné le poids. Dans la version 0.8, il est devenu obligatoire. Pour les rappels, la durée d'affichage est obligatoire depuis le début : « le certificat expire » et « revérifie le chiffre avant de le citer » exigent des délais différents, et seul l'auteur de l'entrée les connaît.

Le nettoyage en arrière-plan, qui ne demande rien à l'agent, a donné les meilleurs résultats : dès le premier passage, il a lui-même réparti par couches 33 entrées accumulées.

La conclusion pratique de l'équipe tient en cinq règles :

• ce qui est nécessaire doit arriver tout seul, dans une réponse que l'agent reçoit de toute façon ;
• formuler comme une dette : « en attente de décision » plutôt que « tu peux regarder » ;
• suggérer au moment de l'action, et non tout d'un coup au début de la session ;
• rendre les paramètres obligatoires sans valeur par défaut ;
• garder l'instruction courte et vérifier quelle part en parvient au modèle dans votre client.

Les sources de kaeru sont publiées sur GitHub, et le prochain article de la série montrera à quoi ressemble une journée de travail à la lumière de ces conclusions.