Vous est-il déjà arrivé de garder un même chat ouvert du lundi au vendredi, de voir le contexte s’alourdir et renchérir à chaque réponse — sans que Hermes paraisse pour autant plus malin, ni même se souvenir de la préférence que vous lui aviez confiée la semaine passée ? Un développeur a partagé cette semaine sa propre version de l’histoire (I think I used the Hermes Agent wrong), et sa conclusion mérite qu’on s’y attarde : le problème tient peut-être à ceci — il n’a presque jamais mis fin à une session.

Faisant tourner Hermes sur un Raspberry Pi relié à Telegram, il est resté 18 jours sur seulement 5 sessions : chaque soir la Pi s’éteignait, chaque matin Hermes reprenait en silence la session précédente. Résultat : sur 1 990 messages, Hermes n’a utilisé proactivement session_search (l’outil de rappel inter-sessions) que 9 fois, et les fichiers mémoire ont à peine bougé. La raison n’est pas que l’agent soit devenu plus bête. Tout ce qui comptait se trouvait encore dans la fenêtre de contexte — il n’y avait donc rien à mémoriser. Or, la mémoire à long terme de Hermes est explicitement conçue dans l’hypothèse que les sessions se terminent.

Comment fonctionne réellement la mémoire de Hermes

Hermes conserve deux types de mémoire persistante, et comprendre chacun d’eux explique pourquoi les frontières comptent.

Les notes inter-sessions : MEMORY.md et USER.md. Chaque profile détient ces fichiers texte (plus SOUL.md, facultatif) : USER.md stocke des faits vous concernant, MEMORY.md des notes et préférences accumulées par Hermes. Au démarrage d’une nouvelle session, les deux fichiers sont injectés dans le contexte, si bien que Hermes « se souvient » de qui vous êtes et de ce qu’il a appris. Mais leur taille est plafonnée — les valeurs par défaut dans le code source sont memory_char_limit: 2200 et user_char_limit: 1375, soit environ 800 et 500 tokens. Près du plafond, Hermes doit recourir à son outil de mémoire pour fusionner, élaguer et prioriser — en conservant ce qui compte le plus.

Le magasin d’historique complet : state.db. Chaque message est conservé dans une base SQLite locale. session_search est l’outil qui permet à Hermes de regarder au-delà de la session en cours — « comment avais-je corrigé cet échec de CI la dernière fois ? ». C’est l’autre moitié de la conception : quand le contexte ne peut pas tout contenir, la récupération ramène les vieux détails.

Et quand l’écriture a-t-elle lieu ? Outre l’usage explicite de l’outil de mémoire en pleine conversation, Hermes exécute un background review : après chaque tour, il revoit la conversation en asynchrone et distille ce qui mérite d’être conservé — leçons, corrections, préférences. Cette boucle ne fonctionne correctement que si les sessions ont des fins naturelles : consolider un lot en fin de session, l’injecter au démarrage suivant, et recommencer.

Ce qui se passe quand vous ne terminez jamais une session

Appliquez cette conception à une session unique de 18 jours, et le mode de défaillance saute aux yeux :

• Les fichiers mémoire deviennent de la décoration. MEMORY.md/USER.md s’injectent au démarrage de la session — dans une méga-session, leur contenu est déjà dans le contexte, Hermes n’a donc jamais besoin des fichiers pour « se rappeler » quoi que ce soit, et le background review n’y voit rien qui vaille une mise à jour. Ils se périment en silence.
• session_search se déclenche rarement. L’outil existe pour le cas « absent du contexte, mais présent dans l’historique ». Dans une session sans fin, la semaine dernière est encore dans la fenêtre : la récupération n’a donc aucune mission. Neuf utilisations pour 1 990 messages, ce n’est pas de la stupidité — c’est un outil qui n’a rien à faire.
• Coût et latence grimpent. Chaque tour renvoie au modèle un historique toujours plus volumineux ; la facture de tokens augmente avec la longueur de la session. Près de la limite de la fenêtre, la compression entre en jeu et replie les anciens contenus dans des résumés — des résumés avec pertes, où les détails s’évaporent en silence.
• Vous perdez la stratification de la mémoire. La méga-session fusionne le contexte à court terme et la mémoire à long terme dans un même pot. Se souvenir de tout revient à ne se souvenir de rien avec précision : les préférences durables qui devraient tenir dans une note et les détails ponctuels qui relèvent de la recherche mijotent dans le même bouillon.

Quand repartir de zéro, quand reprendre

Bonne nouvelle : la règle est simple. La tâche est-elle toujours en cours ?

Reprenez la session quand :

• La même tâche reste inachevée — simplement mise en pause (vous vous êtes arrêté au milieu d’un long document) ;
• Un contexte transitoire (un chemin de fichier, le code exact que vous déboguez) sera nécessaire dès l’étape suivante et ne mérite pas d’être réexpliqué ;
• Vous alternez entre plusieurs tâches dans un même terminal et souhaitez conserver intact l’historique de chaque fil.

Démarrez une nouvelle session quand :

• La dernière tâche est livrée ou manifestement terminée — même « fini pour l’instant » compte ;
• Le sujet a changé et les deux tâches ne partagent aucun contexte à reporter ;
• Le contexte est déjà volumineux (surveillez la consommation de tokens dans la barre d’état ou dans des vues du type hermes status) et la nouvelle tâche n’utilisera pas l’ancien contenu ;
• Vous voulez que Hermes se souvienne réellement de cette conversation — y mettre fin laisse le background review distiller les enseignements.

La bonne façon de passer à autre chose : avant d’entamer quoi que ce soit de neuf, demandez à Hermes d’écrire en mémoire les conclusions qui méritent d’être gardées, ou archivez la conversation avec la commande /save vue précédemment. Quand vous reprenez, l’astuce de reprise hermes chat -c par terminal garde chaque terminal sur son propre fil. Et si les données de session viennent à mal se comporter, notre guide de terrain des incidents de session vous guide du diagnostic à la récupération.

Faites des frontières de session une habitude

L’histoire de ce développeur mérite d’être partagée parce qu’il n’a pas rencontré de bug — il a buté sur une inadéquation d’usage, utilisant un système de mémoire conçu pour de multiples sessions comme s’il s’agissait d’un fil unique sans fin. Pas besoin de clore vos sessions minuteur en main ; ouvrez simplement une nouvelle session naturellement quand une tâche se termine. L’injection des fichiers, la consolidation par background review et la récupération par session_search peuvent alors faire leur travail. Les sessions délimitées donnent à la mémoire un cycle — et un Hermes qui se souvient vraiment de vous, c’est celui pour lequel vous l’avez installé.