Hermes Agent : comprendre les 4 couches de mémoire persistante

Quand on parle de mémoire persistante dans Hermes, beaucoup de gens mettent plusieurs choses très différentes dans le même sac.

Ils disent “mémoire”, alors qu’ils parlent parfois de la mémoire native injectée dans le prompt. D’autres fois, ils parlent simplement de l’historique des sessions. D’autres encore parlent des profiles, alors qu’ils ont surtout un problème de mélange de contextes. Et dès qu’un provider externe arrive dans la discussion, tout finit par se brouiller.

Le vrai sujet de ce tuto est donc simple :

quand on parle de mémoire persistante dans Hermes, de quoi parle-t-on exactement ?

La réponse courte, c’est que la mémoire Hermes n’est pas une seule chose.

En pratique, il faut distinguer quatre couches :

1. la mémoire native Hermes
2. les sessions et l’historique
3. les profiles comme frontière de contexte
4. les providers mémoire externes

Ces couches peuvent toutes persister dans le temps. Mais elles ne servent pas au même usage.

Ce que tu auras à la fin
Une vision nette des 4 couches, de leur rôle réel, de leurs limites, des commandes qui comptent vraiment, et d’une idée simple pour décider de laquelle tu as besoin.

Pourquoi le sujet est souvent mal compris

La confusion vient d’un glissement très banal.

Quand Hermes “se souvient” de quelque chose, on a vite tendance à appeler ça mémoire sans préciser le mécanisme exact. Or entre “être toujours injecté dans le contexte”, “être retrouvable dans l’historique”, “être isolé dans un autre profile” et “être délégué à un backend mémoire externe”, on ne parle pas du tout du même comportement.

Le résultat, c’est qu’on mélange des outils qui ne répondent pas à la même question.

La mémoire native sert à garder un petit noyau de faits durables immédiatement disponibles.
Les sessions servent à retrouver ce qui s’est vraiment dit ou fait auparavant.
Les profiles servent à éviter que plusieurs vies d’Hermes se contaminent entre elles.
Les providers externes servent à dépasser le cadre natif quand le besoin devient plus riche, plus structuré ou plus automatique.

Autrement dit, la bonne question n’est pas : “quel système mémoire est le plus puissant ?”

La bonne question est : “de quelle couche ai-je réellement besoin ?”

Couche 1 — La mémoire native Hermes

C’est la couche la plus importante à comprendre, parce que beaucoup de malentendus commencent ici.

La mémoire native Hermes est compacte, bornée et pensée pour rester petite. Officiellement, elle repose sur deux fichiers : MEMORY.md pour les notes utiles à l’agent, et USER.md pour le profil utilisateur. Ces deux mémoires sont stockées dans ~/.hermes/memories/ et injectées dans le prompt système au début de chaque session.

C’est la première chose à retenir : la mémoire native est de la mémoire active injectée, pas juste un historique dormant.

Si Hermes garde un fait là-dedans, il l’a sous les yeux à la session suivante. C’est ce qui la rend utile pour les préférences stables, les conventions de projet, quelques faits d’environnement, ou les habitudes durables qui changent vraiment la qualité des réponses.

Mais cette mémoire a aussi une limite volontaire. Elle est petite. On n’est pas du tout sur une base de connaissances générale. On est sur un carnet de bord compact.

C’est une force, pas une faiblesse.

Plus une mémoire injectée grossit, plus elle coûte du contexte et plus elle apporte du bruit. La mémoire native Hermes reste donc utile précisément parce qu’elle ne cherche pas à tout retenir.

Il y a un autre détail très important : l’injection est figée au démarrage de la session. Si l’agent ajoute ou modifie une mémoire pendant la conversation, elle est bien persistée sur disque, mais elle ne réapparaît dans le prompt qu’à la session suivante.

En clair, la mémoire native est parfaite pour :

• quelques préférences durables
• des conventions de travail
• des faits d’environnement qui reviennent souvent
• des corrections stables à ne pas refaire

Elle est mauvaise pour :

• stocker beaucoup d’informations
• servir de base documentaire
• remplacer un historique détaillé
• absorber tous les cas temporaires

Couche 2 — Les sessions et l’historique

La deuxième couche, c’est l’historique des conversations.

Hermes enregistre automatiquement les sessions CLI et gateway. Cela permet de reprendre une conversation, de lister les sessions, d’en reprendre une par ID ou par nom, et surtout de rechercher dans le passé.

Mais il faut être très clair sur un point : les sessions ne sont pas la même chose que la mémoire active.

Le fait qu’une information existe dans l’historique ne veut pas dire qu’elle sera injectée automatiquement dans le prompt à chaque nouvelle session. C’est justement toute la différence entre la couche 1 et la couche 2.

La mémoire native dit : “ceci doit rester toujours à portée de main”.

L’historique dit : “ceci a existé, tu peux le retrouver”.

Cette différence change tout.

Si ton besoin réel, c’est “Hermes doit toujours se rappeler que je préfère des réponses courtes”, on est dans la mémoire native.

Si ton besoin réel, c’est “je veux retrouver ce qu’on a dit mardi dernier sur un bug ou une idée”, on est dans les sessions.

L’historique est donc plus large, plus fidèle au passé réel, mais aussi moins immédiat. Il faut aller le retrouver.

En pratique, les premières commandes utiles sont :

• hermes sessions list
• hermes -c
• hermes --resume <id>

Tu peux donc reprendre la dernière session, ou en relancer une précise. C’est très utile, mais ce n’est pas la même chose qu’une mémoire qui accompagne toutes les nouvelles conversations.

Couche 3 — Les profiles comme frontière de contexte

Ici, il faut éviter une confusion fréquente : un profile n’est pas une “mémoire plus forte”. C’est d’abord une frontière de contexte.

Le sujet est détaillé dans Hermes Agent : quand un seul profile ne suffit plus. Ici, retiens seulement l’essentiel : chaque profile embarque sa propre config, sa propre mémoire native, ses propres sessions, ses propres skills, ses propres tâches et son propre état. Quand plusieurs usages n’ont plus intérêt à cohabiter, cette séparation évite beaucoup de faux problèmes mémoire.

Autrement dit, parfois ton problème n’est pas : “Hermes manque de mémoire”.

Ton problème est : “j’ai mis trop de choses différentes dans le même Hermes”.

Quand un même profile mélange usage perso, projet, gateway, cron et essais divers, tu peux avoir l’impression qu’il faut ajouter un système mémoire plus puissant. En réalité, tu as peut-être juste besoin de moins de mélange.

Le bon réflexe, ici, n’est pas forcément d’ajouter un provider externe. C’est parfois simplement de créer un deuxième Hermes propre.

Couche 4 — Les providers mémoire externes

La quatrième couche, c’est celle qu’on appelle souvent “la vraie mémoire persistante”, alors qu’elle n’est en réalité qu’une couche supplémentaire.

Hermes supporte officiellement plusieurs providers mémoire externes. Ils sont additifs. Ils ne remplacent pas la mémoire native. Ils viennent à côté. La mémoire native continue d’exister, et un seul provider externe peut être actif à la fois.

C’est un point essentiel.

Un provider externe n’est pas la version pro de MEMORY.md. C’est une autre famille d’outils pour des besoins qui dépassent le cadre natif.

En pratique, ces providers répondent à des besoins comme :

• une mémoire plus longue
• une recherche plus sémantique
• une structuration plus riche
• une extraction plus automatique
• une intégration dans un système mémoire déjà existant

Ils deviennent donc logiques quand tu as besoin de plus qu’un carnet compact, plus qu’un historique consultable, et plus qu’une séparation propre par profiles.

Ils deviennent inutiles quand tu essaies juste de réparer une mémoire native mal remplie, un historique que tu n’utilises pas, ou un profile qui mélange tout.

Quatre mini scénarios pour voir la différence

Cas 1 — La mémoire native suffit largement

Tu utilises Hermes dans un contexte stable. Il doit retenir quelques préférences, quelques conventions de travail, deux ou trois faits d’environnement, et éviter de refaire les mêmes erreurs.

Ici, la bonne couche est la mémoire native.

Tu gagnes une continuité simple et peu coûteuse. Le point de vigilance est simple : n’essaie pas d’y faire entrer tout le monde.

Cas 2 — Le vrai besoin, c’est retrouver ce qui s’est dit

Tu ne veux pas qu’Hermes garde tout activement en tête. Tu veux surtout pouvoir retrouver une discussion, une décision, un morceau de debug, ou un échange ancien.

Ici, la bonne couche est l’historique des sessions.

Tu gagnes un vrai passé consultable, plus fidèle et plus large que la mémoire native. En revanche, ce n’est pas du rappel instantané injecté en continu.

Cas 3 — Le problème, c’est le mélange de contextes

Tu as un Hermes qui te sert à tout : usage perso, projet, gateway, tâches cron, essais divers. Tu sens du bruit partout et tu commences à te dire qu’il faudrait une meilleure mémoire.

Ici, le bon remède est souvent un profile séparé, pas un backend mémoire plus ambitieux.

Tu gagnes une séparation nette entre plusieurs vies d’Hermes. Le vrai point de vigilance, c’est de ne pas créer dix profiles pour un faux besoin.

Cas 4 — Un provider externe devient enfin logique

Tu as déjà un découpage propre. Les profiles sont clairs. L’historique est utilisé. La mémoire native est propre mais trop petite pour ton usage. Et maintenant, tu veux une mémoire plus longue, plus structurée, plus sémantique, ou plus automatique.

Là, oui, un provider externe devient cohérent.

Tu gagnes un autre niveau de rappel, de structuration ou d’automatisation selon le provider choisi. Mais tu dois surveiller le coût, la complexité et le risque de surdimensionner ton besoin réel.

Les premières commandes vraiment utiles

Il y a une idée simple à garder en tête : toutes les commandes mémoire ne parlent pas de la même couche.

Pour la couche provider externe, les trois commandes les plus utiles sont :

• hermes memory setup
• hermes memory status
• hermes memory off

Le point important, c’est que ces commandes concernent la couche externe, pas la mémoire native en général. Quand tu fais hermes memory off, tu ne supprimes pas la mémoire Hermes. Tu désactives seulement le provider externe pour revenir à la mémoire native seule.

Pour l’historique, les premières commandes utiles sont souvent :

• hermes sessions list
• hermes -c
• hermes --resume <id>

Pour les profiles, les premières commandes utiles au début restent :

• hermes profile create <nom>
• hermes profile create <nom> --clone
• hermes profile use <nom>
• hermes profile show <nom>

Là encore, retiens surtout la logique : --clone copie la base utile, puis repart avec des sessions et une mémoire fraîches. Si tu veux le détail du découpage profile par profile, va lire Hermes Agent : quand un seul profile ne suffit plus.

Comment choisir la bonne couche

Tu peux te poser quatre questions très simples.

Est-ce que cette information doit être toujours disponible dès le démarrage ?
Si oui, pense mémoire native.

Est-ce que j’ai surtout besoin de retrouver une discussion passée ou une action ancienne ?
Si oui, pense sessions et historique.

Est-ce que le vrai problème vient d’un mélange entre plusieurs usages d’Hermes ?
Si oui, pense profiles avant de penser provider.

Est-ce que j’ai déjà stabilisé les trois couches précédentes, mais que mon besoin dépasse encore ce cadre ?
Si oui, alors seulement regarde les providers externes.

Ce qu’il vaut mieux stabiliser avant d’ajouter un provider externe

Avant de brancher une mémoire externe, il vaut mieux vérifier trois choses.

La première : ta mémoire native est-elle réellement utile, ou déjà remplie de choses moyennes ?

La deuxième : utilises-tu vraiment les sessions, ou laisses-tu dormir un historique que tu pourrais déjà exploiter ?

La troisième : tes profiles sont-ils propres, ou as-tu simplement entassé plusieurs contextes dans le même agent ?

Tant que ces trois points ne sont pas clairs, ajouter un provider externe risque surtout d’ajouter de la complexité.

Les erreurs les plus fréquentes

La première erreur, c’est de traiter l’historique comme si c’était une mémoire active. Ce n’est pas le cas.

La deuxième, c’est de croire qu’un provider externe va corriger un mauvais découpage de profiles.

La troisième, c’est de vouloir trop stocker dans la mémoire native.

La quatrième, c’est d’ajouter un provider juste parce qu’il a l’air plus avancé.

La cinquième, c’est de mélanger la question du stockage et la question du rappel.

Ce que tu ne dois pas faire

• Ne parle pas de la mémoire Hermes comme d’une seule feature.
• Ne branche pas un provider externe pour réparer un profile mal découpé.
• Ne prends pas l’historique pour une mémoire active.
• Ne transforme pas la mémoire native en fourre-tout.
• Et surtout, n’oublie pas le point central de ce tuto : plus de mémoire n’est pas forcément mieux.

Plus de mémoire peut aussi vouloir dire plus de bruit, plus de coûts, plus de confusion, et une couche de plus à maintenir.

La suite logique

Une fois ce point compris, la question mémoire devient beaucoup plus simple.

Tu n’as plus besoin de demander “quel backend mémoire est le plus fort ?”. Tu peux enfin demander : “quelle couche répond à mon besoin réel ?”

C’est ce qui évite de suréquiper ton setup trop tôt.