Système de mémoire des agents Hermes : comment fonctionne réellement la mémoire persistante de l’IA

Vous connaissez la procédure. Vous ouvrez une discussion avec un agent IA, lui expliquez votre projet, partagez vos préférences, faites avancer le travail, puis fermez l’onglet. Vous revenez la semaine suivante, et c’est comme parler à un étranger : tout le contexte est parti, chaque préférence oubliée, le projet à réexpliquer de zéro.

Ce n’est pas un bug. C’est ainsi que les grands modèles de langage fonctionnent par conception. Ils sont sans état : chaque requête est indépendante, chaque réponse générée à partir du prompt que vous envoyez à l’instant T, sans mémoire, sans histoire, et sans continuité au-delà des jetons contenus dans la fenêtre de contexte actuelle.

Pour des interactions à tour unique, cela convient. Posez une question, obtenez une réponse, passez à autre chose. Mais pour les agents — des systèmes censés agir d’une session à l’autre, apprendre de leurs erreurs et évoluer avec vous — l’absence d’état constitue une limite architecturale majeure. C’est l’un des problèmes centraux non résolus dans les systèmes d’IA auto-hébergés.

L’industrie a tenté de résoudre ce problème. LangChain a ajouté des modules de mémoire. OpenAI a introduit des assistants avec des fils de discussion. Des frameworks comme Letta, Zep et Cognee ont construit des architectures entières autour d’une mémoire persistante. Databricks a publié des travaux sur le « scaling de mémoire » — l’idée que la performance des agents s’améliore avec l’expérience accumulée. Depuis 2024, des papiers de benchmark dédiés, des revues sur la mémoire épisodique et un écosystème d’outils en croissance rapide ont émergé pour adresser ce qui est de plus en plus reconnu comme l’un des problèmes centraux non résolus dans l’IA agentique.

La plupart de ces approches partagent un problème commun : elles traitent la mémoire comme une idée après coup — une base de données à interroger, une fenêtre de contexte à bourrer, un système de récupération qui ajoute latence et bruit plutôt que clarté.

Hermes Agent adopte une approche fondamentalement différente. La mémoire n’est pas quelque chose que l’agent récupère lorsqu’il en a besoin. C’est quelque chose que l’agent est à tout moment — intégré au prompt système, curaté, borné et toujours actif. Elle est assez petite pour être rapide, assez structurée pour être utile, et assez disciplinée pour savoir quoi oublier.

Cet article explique exactement comment cela fonctionne.

Partie 1 : Le problème de la mémoire des agents IA

Pourquoi « Ajouter du contexte » ne suffit pas pour les agents

La solution évidente à l’IA sans état est d’ajouter du contexte. Attachez la conversation précédente. Incluez la documentation du projet. Envoyez l’historique complet.

Un temps, cela fonctionne. Vous avez une fenêtre de contexte de 128K jetons. Vous pouvez y insérer beaucoup de texte.

Mais le contexte n’est pas la mémoire — il y a une différence réelle et importante entre les deux. Le contexte est tout ce qui vous est montré à l’instant présent ; la mémoire est ce que vous conservez activement et transmettez.

Le contexte n’a pas de curation. C’est un dump : à mesure qu’il grandit, le modèle doit traiter des milliers de jetons d’historique irrelevant pour trouver le seul fait dont il a besoin. Cela coûte en jetons et en argent, augmente la latence et finit par atteindre le plafond.

La mémoire est curatée. C’est la distillation de l’expérience en quelque chose de compact et d’actionnable. Elle ne grandit pas indéfiniment — elle consolide, met à jour et oublie.

La mémoire humaine fonctionne de la même manière. Vous ne vous souvenez pas de chaque conversation que vous avez jamais eue. Vous vous souvenez des parties importantes : avec qui vous parlez, ce qui leur tient à cœur, ce sur quoi vous vous êtes mis d’accord, ce que vous avez appris. Le reste est soit oublié, soit searchable lorsque vous en avez besoin.

Le paysage de la recherche

L’espace de la mémoire des agents IA a explosé depuis 2024, avec des suites de benchmark dédiées, une littérature scientifique en croissance et un écart de performance mesurable entre les différentes approches architecturales. Voici où en sont les choses.

Letta (anciennement MemGPT) a été l’un des premiers frameworks à traiter la mémoire persistante comme une préoccupation de premier ordre, atteignant 21,7K étoiles GitHub. Il utilise un modèle en trois couches inspiré des systèmes d’exploitation : mémoire de base (petite, toujours dans le contexte), mémoire de rappel (historique de conversation searchable) et mémoire archivistique (stockage à froid à long terme). L’intuition que toute la mémoire n’est pas égale était correcte. L’implémentation, cependant, exige que les agents tournent entièrement à l’intérieur du runtime Letta — l’adopter signifie adopter toute la plateforme, pas seulement une couche de mémoire.

Zep / Graphiti se concentre sur la mémoire conversationnelle avec un suivi temporel des entités — les faits portent des fenêtres de validité afin que le graphe sache quand quelque chose était vrai. C’est performant pour les chatbots qui ont besoin de graphes de relations, moins adapté aux agents autonomes suivant les faits environnementaux et les conventions de projet.

Cognee est conçu pour l’extraction de connaissances à partir de documents et de données structurées, avec plus de 30 connecteurs d’ingestion et un backend de graphe de connaissances. Il excelle dans les connaissances institutionnelles et les pipelines RAG, mais est moins centré sur la mémoire personnelle de l’agent. Voir l’auto-hébergement de Cognee avec des LLM locaux pour un guide pratique d’installation.

Hindsight fait du rappel basé sur des graphes de connaissances avec des relations d’entités et un outil de synthèse reflect unique qui effectue une synthèse inter-mémoire — combinant plusieurs mémoires en nouvelles intuitions. Il figure parmi les meilleurs performeurs dans les benchmarks de mémoire d’agents et est disponible en tant que fournisseur de mémoire pour Hermes Agent.

Mem0 gère l’extraction de mémoire côté serveur via l’analyse LLM, nécessitant une configuration minimale. Le papier de recherche Mem0, publié à ECAI 2025 (arXiv:2504.19413), a benchmarké dix approches distinctes de mémoire IA et validé l’approche d’extraction sélective — stocker des faits discrets, déduplicer et ne récupérer que ce qui est pertinent. Mem0 a grandi pour atteindre environ 48K étoiles GitHub et supporte 21 intégrations de framework. Le compromis est la dépendance au cloud et le coût.

La recherche de Databricks sur le scaling de mémoire a introduit le concept que la performance des agents s’améliore avec l’expérience accumulée. Leur architecture détient des prompts système, des actifs d’entreprise et des mémoires épisodiques/semantiques scoupées au niveau organisation et utilisateur, validant l’idée que la qualité de la mémoire compte autant que la capacité du modèle.

Le fil conducteur à travers la plupart des frameworks est qu’ils traitent la mémoire comme un problème de récupération : stockez-la quelque part, interrogez-la quand nécessaire, injectez-la dans le contexte. Hermes fait l’inverse — la mémoire n’est pas récupérée à la demande, elle est injectée au démarrage de la session et toujours présente. Toujours active, toujours disponible, curatée pour rester utile.

Partie 2 : Architecture — Deux fichiers, un cerveau

Le système de mémoire intégré d’Hermes Agent vit dans deux fichiers.

• ~/.hermes/memories/MEMORY.md — Notes personnelles de l’agent (2 200 caractères, ~800 jetons)
• ~/.hermes/memories/USER.md — Profil utilisateur (1 375 caractères, ~500 jetons)

C’est toute la surface de mémoire persistante : deux fichiers, moins de 3 600 caractères au total, moins de 1 300 jetons. Cela semble délibérément petit parce que c’est le cas — et c’est exactement l’intention de conception.

MEMORY.md : Les notes de l’agent

C’est là que l’agent stocke tout ce qu’il apprend sur son environnement, le projet, les outils, les conventions et les leçons apprises. Voici à quoi cela ressemble :

Le projet de l'utilisateur est un microservice Go sur ~/code/gateway utilisant gRPC + PostgreSQL
Cette machine tourne sous Ubuntu 22.04, a Docker et kubectl installés
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase

Ce ne sont pas des logs. Ce sont des faits. Denses, déclaratifs, chargés d’information. Pas de timestamps, pas de remplissage, pas de « le 5 janvier, l’utilisateur m’a demandé de… »

USER.md : Le profil utilisateur

C’est là que l’agent stocke tout ce qu’il sait sur vous.

L'utilisateur est un développeur full-stack à l'aise avec TypeScript, Go et Python.
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase.
L'utilisateur utilise principalement Linux Ubuntu 22.04.
L'utilisateur déploie sur AWS en utilisant Terraform.

Identité, rôle, préférences, compétences techniques, style de communication, trucs qui énervent. Les choses qui font que l’agent répond différemment à vous qu’à quiconque d’autre.

Le motif de l’instantané figé

Au démarrage de la session, les deux fichiers sont chargés depuis le disque et injectés comme un bloc figé dans le prompt système. Voici à quoi cela ressemble :

══════════════════════════════════════════════
MÉMOIRE (vos notes personnelles) [7% — 166/2 200 caractères]

Le projet de l’utilisateur est un microservice Go sur ~/code/gateway utilisant gRPC + PostgreSQL § Cette machine tourne sous Ubuntu 22.04, a Docker et kubectl installés § L’utilisateur préfère snake_case pour les noms de variables et évite camelCase §

══════════════════════════════════════════════ PROFIL UTILISATEUR (qui est l’utilisateur) [8% — 110/1 375 caractères] ══════════════════════════════════════════════ L’utilisateur est un développeur full-stack à l’aise avec TypeScript, Go et Python. § L’utilisateur préfère snake_case pour les noms de variables et évite camelCase. §

Le format utilise des en-têtes, des pourcentages d'utilisation, des comptes de caractères et des délimiteurs `§` (signe section). Les entrées peuvent être sur plusieurs lignes. Il est conçu pour être analysable par le modèle tout en restant lisible par l'humain.

Pourquoi figé ? [Mise en cache des préfixes](https://www.glukhov.org/fr/llm-performance/). Le prompt système est le même à chaque tour d'une session. En gardant la mémoire statique après le démarrage de la session, le modèle peut mettre en cache le calcul du préfixe et ne traiter que les parties variables — la conversation. C'est une optimisation de performance significative. Vous ne recalculiez pas l'attention sur les mêmes jetons de mémoire à chaque tour.

Les modifications apportées pendant une session persistent sur le disque immédiatement, mais n'apparaissent dans le prompt système qu'au démarrage de la session suivante. Les réponses des outils montrent toujours l'état en direct, mais l'esprit du modèle ne change pas en plein milieu de session. Cela empêche le modèle de courir après sa propre queue — mettre à jour la mémoire puis réagir à sa propre mise à jour dans la même conversation.

### Les limites de caractères comme fonctionnalité

2 200 caractères. 1 375 caractères. Ce ne sont pas des limites arbitraires. Ce sont des contraintes de conception qui forcent la curation.

Une mémoire illimitée est un passif. Elle encourage à tout y jeter, à jamais consolider et à devenir du bruit à la fin. Une mémoire bornée force l'agent à être sélectif. Qu'est-ce qui est vraiment important ? De quoi aurai-je besoin à nouveau ? Quoi compresser sans perdre de sens ?

Lorsque la mémoire est pleine, l'agent ne rate pas silencieusement. Il reçoit une erreur avec les entrées actuelles et l'utilisation, puis suit un workflow :

1. Lire les entrées actuelles depuis la réponse d'erreur
2. Identifier les entrées supprimables ou consolidables
3. Utiliser `replace` pour fusionner les entrées liées en versions plus courtes
4. Ajouter la nouvelle entrée

C'est ainsi que la mémoire reste utile. Ce n'est pas une base de données. C'est une collection curatée de faits importants.

### Sécurité : Analyse d'injection de prompt

Chaque entrée de mémoire est analysée avant acceptation. Le système bloque les tentatives d'injection de prompt, l'exfiltration de credentials, les backdoors SSH et les caractères Unicode invisibles.

La mémoire est également déduplicée. Les entrées dupliquées exactes sont rejetées automatiquement. Cela empêche les adversaires d'essayer d'injecter du contenu malveillant via des soumissions répétées.

---

## Partie 3 : Quand la mémoire s'active — Déclencheurs et décisions

La question la plus courante sur la mémoire d'Hermes Agent est quand elle sauvegarde réellement quelque chose.

La réponse est : constamment, mais sélectivement. L'agent gère sa propre mémoire via l'outil `memory`, et la décision de sauvegarder est pilotée par une combinaison de signaux explicites et de motifs implicites.

### Déclencheurs d'écriture : Quand l'agent décide-t-il de sauvegarder ?

L'agent sauvegarde la mémoire de manière proactive. Il n'attend pas que vous le demandiez. Voici ce qui le déclenche.

**Corrections utilisateur.** Lorsque vous corrigez l'agent, c'est un signal pour se souvenir. « Ne fais plus ça. » « Utilise ceci à la place. » « Souviens-toi de ça. » Ce sont des instructions explicites pour mettre à jour la mémoire.

Exemple : vous demandez à l'agent de configurer un environnement Python. Il suggère `pip`. Vous dites « J'utilise `poetry` pour tout. » L'agent sauvegarde : `L'utilisateur préfère utiliser le gestionnaire de paquets 'poetry' pour tous les projets Python.`

**Préférences découvertes.** L'agent observe des motifs et infère des préférences. Si vous utilisez constamment un certain outil, framework ou workflow, cela est sauvegardé.

Exemple : après vous avoir vu utiliser `poetry` à plusieurs reprises sur différents projets, l'agent le sauvegarde comme préférence.

**Faits environnementaux.** Des choses sur la machine, le projet, les outils installés. Ceux-ci sont découverts par exploration et sauvegardés comme faits.

Exemple : l'agent vérifie ce qui est installé et sauvegarde : `Cette machine tourne sous Ubuntu 22.04, a Docker et kubectl installés.`

**Conventions de projet.** Comment le projet est structuré, quels outils il utilise, quels motifs il suit. Ceux-ci sont découverts par inspection de code et sauvegardés.

Exemple : `Le projet de l'utilisateur est un microservice Go sur ~/code/gateway utilisant gRPC + PostgreSQL.`

**Workflows complexes complétés.** Après avoir complété une tâche qui a nécessité 5+ appels d'outils, l'agent considère sauvegarder l'approche comme une compétence ou du moins noter ce qui a fonctionné.

**Particularités des outils et contournements.** Quand l'agent découvre quelque chose de non évident sur un outil, API ou système — une limitation, un contournement, une convention — il le sauvegarde.

**Ce qui est ignoré :**

- Informations triviales ou évidentes
- Choses facilement redécouvrables
- Dumps de données brutes
- Éphémères spécifiques à la session
- Informations déjà dans les fichiers de contexte (SOUL.md, AGENTS.md)

### Déclencheurs de lecture : Quand l'agent fait-il un rappel ?

La mémoire n'est pas récupérée — elle est toujours là. Mais il y a différents niveaux d'accès.

**Début de session (automatique).** MEMORY.md et USER.md sont injectés dans le prompt système. L'agent les a dès le premier jeton. Pas besoin de requête, pas de latence, pas d'appel d'outil. C'est la mémoire de base — toujours active.

**`session_search` (à la demande).** Quand l'agent a besoin de trouver quelque chose dans les conversations passées qui n'est pas dans la mémoire de base, il utilise l'outil `session_search`. Cela interroge SQLite (`~/.hermes/state.db`) avec une recherche en texte plein FTS5 et une summarisation Gemini Flash.

Exemple : vous demandez « Avons-nous discuté du réseau Docker la semaine dernière ? » L'agent recherche l'historique de session et retourne un résumé de la conversation pertinente.

**Outils de fournisseur externe (quand configuré).** Quand un fournisseur de mémoire externe est actif, l'agent a des outils supplémentaires disponibles : `honcho_search`, `hindsight_recall`, `mem0_search`, etc. Ceux-ci sont utilisés quand l'agent détermine qu'un contexte externe est nécessaire.

### L'arbre de décision

Voici comment l'agent pèse « est-ce que ça vaut la peine de se souvenir ? » :

Est-ce une correction ou une instruction explicite ? OUI → Sauvegarder dans la mémoire NON → Est-ce une préférence ou un motif ? OUI → Sauvegarder dans le profil utilisateur NON → Est-ce un fait environnemental ou une convention ? OUI → Sauvegarder dans la mémoire NON → Est-ce facilement redécouvrable ? OUI → Ignorer NON → Est-ce spécifique à la session ? OUI → Ignorer NON → Sauvegarder dans la mémoire

L'agent ne surpense pas cela. Il sauvegarde de manière proactive, consolide quand c'est plein, et fait confiance aux limites de caractères pour garder les choses serrées.

---

## Partie 4 : Mémoire interne vs Bases de connaissances externes

C'est là que la confusion arrive souvent. Hermes Agent a une *mémoire interne* (MEMORY.md, USER.md, fournisseurs externes) et des *bases de connaissances externes* (LLM Wiki, Obsidian, Notion, ArXiv, système de fichiers), et ils servent des rôles complètement différents. C'est similaire à la distinction entre les pipelines de [génération augmentée par la récupération](https://www.glukhov.org/fr/rag/) et la mémoire de travail de l'agent — la récupération externe est bonne pour les recherches de connaissances profondes, pas pour porter l'identité et les préférences. La mémoire interne est le cerveau de l'agent — toujours active, curatée, portée dans chaque session. Les bases de connaissances externes sont sa bibliothèque — des ressources de référence vastes consultées à la demande.

### La distinction

**Mémoire interne (le cerveau) :**

- Petite, persistante, injectée dans le prompt système
- Contient : préférences utilisateur, conventions de l'agent, leçons immédiates
- Toujours « en tête » pendant la conversation
- Curatée, bornée, activement gérée
- Exemples : MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Bases de connaissances externes (la bibliothèque) :**

- Vastes, en référence uniquement, accédées à la demande
- Contiennent : documents, papiers, code, notes, bases de données
- Accédées via des outils quand nécessaire
- Pas « mémorisées » — consultées
- Exemples : LLM Wiki, Obsidian, Notion, ArXiv, système de fichiers, GitHub

### Comment elles se rapportent

L'agent *accède* aux bases externes via des outils quand nécessaire. Il ne les « mémorise » pas — il les consulte.

**LLM Wiki (llm-wiki) :** Base de connaissances Markdown interliée de Karpathy pour construire et interroger des connaissances de domaine. L'agent utilise la compétence `llm-wiki` pour lire, chercher et interroger. C'est une ressource de référence, pas de la mémoire.

**[Obsidian](https://www.glukhov.org/fr/knowledge-management/tools/obsidian-for-personal-knowledge-management/) :** Coffres de notes personnelles avec liens bidirectionnels. L'agent utilise la compétence `obsidian` pour lire, chercher et créer des notes. Obsidian fait partie de l'écosystème plus large de [gestion des connaissances personnelles](https://www.glukhov.org/fr/knowledge-management/) auquel Hermes peut accéder comme ressource de bibliothèque.

**Notion/Airtable :** Bases de données structurées et wikis accédés via API. L'agent les interroge quand nécessaire.

**ArXiv :** Dépôts de papiers académiques. L'agent cherche et extrait des papiers quand il recherche un sujet.

**Système de fichiers :** Code du projet, documentation, configurations. L'agent lit les fichiers quand il travaille sur un projet.

### Le motif de distillation

Voici l'intuition clé : les intuitions critiques des bases externes peuvent être *distillées* dans la mémoire interne.

Exemple : l'agent lit un papier d'ArXiv sur le scaling de mémoire pour les agents IA. Il ne sauvegarde pas le papier entier dans la mémoire. Il sauvegarde la conclusion clé : `Scaling de mémoire : la performance de l'agent s'améliore avec l'expérience accumulée via l'interaction utilisateur et le contexte métier stockés en mémoire.`

La ressource externe est vaste. La mémoire interne est la distillation.

### Quand utiliser laquelle

**Mémoire interne pour :**

- « Qui aide-je ? »
- « Que préfère-t-il ? »
- « Qu'avons-nous appris récemment ? »
- « Quelle est la configuration du projet ? »
- « Quels outils sont disponibles ? »

**Bases de connaissances externes pour :**

- « Quelle est la dernière recherche sur X ? »
- « Qu'y a-t-il dans la documentation de mon projet ? »
- « Qu'avons-nous discuté le mois dernier ? »
- « Quelle est l'API pour ce service ? »
- « Quelle est la structure du code ? »

L'agent comprend la différence et utilise chacun de manière appropriée — il ne confond pas consulter un document avec se souvenir de quelque chose qu'il a appris sur vous et votre environnement.

---

## Partie 5 : Comment ça fonctionne réellement

Regardons la mécanique.

### L'outil `memory`

L'agent gère la mémoire via un seul outil avec trois actions : `add`, `replace`, `remove`.

Il n'y a pas d'action `read` — le contenu de la mémoire est auto-injecté dans le prompt système. L'agent n'a pas besoin de le lire parce qu'il est toujours là.

**`add`** — Ajoute une nouvelle entrée.

```python
memory(action="add", target="memory",
       content="L'utilisateur tourne sous macOS 14 Sonoma, utilise Homebrew, a Docker Desktop installé.")

replace — Remplace une entrée existante en utilisant la correspondance de sous-chaîne.

memory(action="replace", target="memory",
       old_text="mode sombre",
       content="L'utilisateur préfère le mode clair dans VS Code, mode sombre dans le terminal")

remove — Supprime une entrée en utilisant la correspondance de sous-chaîne.

memory(action="remove", target="memory",
       old_text="fait temporaire du projet")

Correspondance de sous-chaîne

replace et remove utilisent de courtes sous-chaînes uniques via old_text. Vous n’avez pas besoin du texte complet de l’entrée. Cela rend les éditions chirurgicales possibles sans connaître le contenu exact.

Si une sous-chaîne correspond à plusieurs entrées, une erreur est retournée demandant une correspondance plus spécifique. L’agent affine alors sa requête.

Stockages cibles : memory vs user

Le paramètre target détermine quel fichier est mis à jour.

• memory — Notes personnelles de l’agent. Faits environnementaux, conventions de projet, particularités des outils, leçons apprises.
• user — Profil utilisateur. Identité, rôle, fuseau horaire, préférences de communication, trucs qui énervent, habitudes de workflow.

Gestion de la capacité

Quand la mémoire est >80% pleine, l’agent consolide. Il fusionne les entrées liées, supprime les faits obsolètes et compresse l’information.

Les bonnes entrées de mémoire sont compactes et denses en information :

L'utilisateur tourne sous macOS 14 Sonoma, utilise Homebrew, a Docker Desktop installé. Shell : zsh avec oh-my-zsh. Éditeur : Neovim avec le plugin Telescope.

Les mauvaises entrées de mémoire sont vagues ou verbeuses :

L'utilisateur a un projet.
Le 5 janvier 2026, l'utilisateur m'a demandé de regarder son projet qui est situé sur ~/code/gateway et utilise Go avec gRPC et PostgreSQL pour la couche de base de données.

La première est dense et utile. La seconde est soit trop vague, soit trop verbeuse.

Recherche de session vs Mémoire persistante

session_search et la mémoire persistante servent des objectifs différents.

Règle de base : utilisez la mémoire pour les faits critiques qui devraient toujours être dans le contexte. Utilisez la recherche de session pour les recherches historiques.

Partie 6 : Fournisseurs de mémoire externes — Les 8 options comparées

Au-delà des fichiers intégrés MEMORY.md et USER.md, Hermes Agent supporte 8 plugins de fournisseurs de mémoire externe pour des connaissances persistantes et transversales aux sessions.

Un seul fournisseur externe peut être actif à la fois. Les fichiers intégrés sont toujours actifs aux côtés du fournisseur externe — additif, pas de remplacement.

Activation

hermes memory setup   # Sélecteur interactif + configuration
hermes memory status  # Vérifier ce qui est actif
hermes memory off     # Désactiver le fournisseur externe

Ou manuellement dans ~/.hermes/config.yaml :

memory:
  provider: openviking  # ou honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Comparaison des fournisseurs

Analyse détaillée

Honcho

Idéal pour : systèmes multi-agents, contexte transversal aux sessions, alignement utilisateur-agent.

Honcho tourne aux côtés de la mémoire existante — USER.md reste tel quel, et Honcho ajoute une couche de contexte supplémentaire. Il modélise les conversations comme des pairs échangeant des messages — un pair utilisateur plus un pair IA par profil Hermes, tous partageant un espace de travail.

Outils : honcho_profile (lire/mettre à jour la carte du pair), honcho_search (recherche sémantique), honcho_context (contexte de session — résumé, représentation, carte, messages), honcho_reasoning (synthétisé par LLM), honcho_conclude (créer/supprimer des conclusions).

Paramètres de configuration clés :

• contextCadence (défaut 1) : Tours minimum entre actualisations de la couche de base
• dialecticCadence (défaut 2) : Tours minimum entre appels LLM peer.chat() (1-5 recommandé)
• dialecticDepth (défaut 1) : Passes .chat() par invocation (clampé 1-3)
• recallMode (défaut ‘hybrid’) : hybrid (auto+outils), context (injection uniquement), tools (outils uniquement)
• writeFrequency (défaut ‘async’) : Timing de vidage : async, turn, session, ou entier N
• observationMode (défaut ‘directional’) : directional (tout activé) ou unified (pool partagé)

Architecture : Injection de contexte à deux couches — couche de base (résumé de session + représentation + carte du pair) + supplément dialectique (raisonnement LLM). Sélectionne automatiquement prompts à froid vs chauds.

Cartographie multi-pair : L’espace de travail est un environnement partagé à travers les profils. Le pair utilisateur (peerName) est une identité humaine globale. Le pair IA (aiPeer) est un par profil Hermes (hermes par défaut, hermes.<profile> pour les autres).

Configuration :

hermes memory setup  # sélectionner "honcho"
# ou legacy : hermes honcho setup

Config : $HERMES_HOME/honcho.json (local au profil) ou ~/.honcho/config.json (global).

Gestion de profil :

hermes profile create coder --clone  # Crée hermes.coder avec espace de travail partagé
hermes honcho sync                   # Backfill des pairs IA pour les profils existants

OpenViking

Idéal pour : gestion des connaissances auto-hébergée avec navigation structurée.

OpenViking fournit une hiérarchie de système de fichiers avec chargement par niveaux. C’est gratuit, auto-hébergé, et vous donne le contrôle total sur votre stockage de mémoire.

Outils : viking_search, viking_read (par niveaux), viking_browse, viking_remember, viking_add_resource.

Configuration :

pip install openviking
openviking-server
hermes memory setup  # sélectionner "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Idéal pour : gestion de mémoire sans intervention avec extraction automatique.

Mem0 gère l’extraction de mémoire côté serveur. Vous ne configurez rien — ça marche simplement. Compromis : dépendance cloud et coût.

Outils : mem0_profile, mem0_search, mem0_conclude.

Configuration :

pip install mem0ai
hermes memory setup  # sélectionner "mem0"
echo "MEM0_API_KEY=votre-clé" >> ~/.hermes/.env

Config : $HERMES_HOME/mem0.json (user_id : hermes-user, agent_id : hermes).

Hindsight

Idéal pour : rappel basé sur graphe de connaissances avec relations d’entités.

Hindsight construit un graphe de connaissances de votre mémoire, extrayant entités et relations. Son outil reflect unique effectue une synthèse inter-mémoire — combinant plusieurs mémoires en nouvelles intuitions.

Outils : hindsight_retain, hindsight_recall, hindsight_reflect (synthèse inter-mémoire unique).

Configuration :

hermes memory setup  # sélectionner "hindsight"
echo "HINDSIGHT_API_KEY=votre-clé" >> ~/.hermes/.env

Auto-installe hindsight-client (cloud) ou hindsight-all (local). Nécessite >= 0.4.22.

Config : $HERMES_HOME/hindsight/config.json

• mode : cloud ou local
• recall_budget : low / mid / high
• memory_mode : hybrid / context / tools
• auto_retain / auto_recall : true (défaut)

Interface locale : hindsight-embed -p hermes ui start

Holographic

Idéal pour : configurations axées sur la confidentialité avec stockage uniquement local.

Holographic utilise l’algèbre HRR (Holographic Reduced Representation) pour l’encodage de mémoire, avec scoring de confiance pour la fiabilité de la mémoire. Pas de dépendance cloud — tout tourne localement sur votre propre matériel.

Outils : 2 outils pour les opérations de mémoire via algèbre HRR.

Configuration :

hermes memory setup  # sélectionner "holographic"

Pas de dépendances. Tout tourne localement.

RetainDB

Idéal pour : mises à jour haute fréquence avec compression delta.

RetainDB utilise la compression delta pour stocker efficacement les mises à jour de mémoire. C’est basé sur le cloud avec un coût de 20$/mois, mais la compression signifie moins de transfert de données et des mises à jour plus rapides.

Outils : retaindb_profile (profil utilisateur), retaindb_search (recherche sémantique), retaindb_context (contexte pertinent à la tâche), retaindb_remember (stocker avec type + importance), retaindb_forget (supprimer mémoires).

Configuration :

hermes memory setup  # sélectionner "retaindb"

ByteRover

Idéal pour : environnements contraints en bande passante avec extraction pré-compression.

ByteRover compresse la mémoire avant l’extraction, réduisant l’utilisation de bande passante. Disponible en modes local ou cloud.

Outils : 3 outils pour les opérations de mémoire.

Configuration :

hermes memory setup  # sélectionner "byterover"

Supermemory

Idéal pour : workflows d’entreprise avec clôture de contexte et ingestion de graphe de session.

Supermemory fournit la clôture de contexte (isolant la mémoire par contexte) et l’ingestion de graphe de session (important des historiques de conversation entiers). C’est basé sur le cloud et payant, mais conçu pour la gestion de mémoire à l’échelle de l’entreprise.

Outils : 4 outils pour les opérations de mémoire.

Configuration :

hermes memory setup  # sélectionner "supermemory"

Comment choisir

• Besoin de support multi-agent ? Honcho
• Voulez auto-hébergé et gratuit ? OpenViking ou Holographic
• Voulez zéro config ? Mem0
• Voulez des graphes de connaissances ? Hindsight
• Voulez la compression delta ? RetainDB
• Voulez l’efficacité de bande passante ? ByteRover
• Voulez des fonctionnalités d’entreprise ? Supermemory
• Voulez la confidentialité (local uniquement) ? Holographic

Pour les configurations de fournisseur par profil complètes et les motifs de workflow réels, voir Configuration de production d’Hermes Agent.

Partie 7 : La philosophie

Pourquoi la mémoire bornée bat la mémoire illimitée

L’instinct est de rendre la mémoire aussi grande que possible. Stocker tout. Récupérer ce dont vous avez besoin.

La mémoire bornée fonctionne mieux. Voici pourquoi.

La curation force la qualité. Quand vous avez un espace limité, vous ne sauvegardez que ce qui compte. Vous compressez, consolidez et priorisez. La mémoire illimitée encourage à tout y jeter et à jamais nettoyer.

La vitesse compte. 1 300 jetons dans le prompt système est rapide. 100 000 jetons récupérés d’une base de données est lent. La mémoire devrait être instantanée, pas une requête.

Le bruit dégrade la performance. Plus de mémoire n’est pas une meilleure mémoire. C’est une mémoire plus bruyante. Le modèle doit distinguer le signal du bruit, et cela prend de l’attention — de l’attention qui devrait être dépensée sur la tâche réelle.

Oublier est une fonctionnalité. La mémoire humaine oublie. Ce n’est pas un bug — c’est ainsi que nous priorisons. Les agents devraient aussi oublier. Tout ne mérite pas d’être rappelé.

Le problème de « l’oubli »

Les agents ont besoin de désapprendre. Pas juste oublier, mais activement supprimer l’information obsolète.

Voici comment Hermes Agent le gère :

• Action remove : Supprimer les entrées qui ne sont plus pertinentes.
• Action replace : Mettre à jour les entrées avec de nouvelles informations.
• Pression de capacité : Quand la mémoire est pleine, l’agent consolide et supprime les anciennes entrées.
• Analyse de sécurité : Bloque les entrées malveillantes ou corrompues.

Oublier n’est pas un échec — c’est de la maintenance. Un agent qui ne peut pas désapprendre finira par porter autant de bruit que de signal.

Scaling de mémoire

Databricks a introduit le concept de « scaling de mémoire » : un agent avec des milliers d’utilisateurs fonctionne-t-il mieux qu’un avec un seul utilisateur ?

Leur recherche suggère oui, mais avec des réserves. Le scaling de mémoire nécessite :

1. Extraction de qualité : Toutes les interactions ne valent pas la peine d’être rappelées. L’agent doit extraire des intuitions, pas des logs.
2. Récupération efficace : Les mémoires récupérées doivent être pertinentes. Le bruit dégrade la performance.
3. Généralisation : Les mémoires devraient être des motifs, pas des spécificités. « L’utilisateur préfère Python » scale. « L’utilisateur a exécuté la commande X au timestamp Y » ne scale pas.

La mémoire bornée d’Hermes Agent supporte naturellement le scaling de mémoire. En forçant la curation, elle assure que les mémoires sont généralisables, compactes et utiles.

Ce que cela signifie pour l’avenir

La mémoire devient la fosse concurrentielle dans l’IA agentique — pas le modèle lui-même, mais ce que le modèle porte entre les sessions. Deux agents avec des modèles sous-jacents identiques peuvent performer très différemment : l’un se souvient de vos préférences, votre environnement, et vos erreurs passées ; l’autre démarre à froid chaque fois.

La question n’est plus si les agents devraient avoir une mémoire persistante. C’est réglé : ils doivent. La question ouverte est comment concevoir cette mémoire bien — quoi garder, quoi jeter, comment la rendre instantanée, et comment empêcher qu’elle devienne du bruit.

La réponse d’Hermes Agent est de garder la mémoire petite, curatée et toujours active — pas une base de données à interroger, mais un modèle de travail de l’utilisateur que l’agent porte avec lui dans chaque conversation.

Conclusion

Le système de mémoire d’Hermes Agent est délibérément simple : deux fichiers, limites de caractères fermes, pas de pipeline de récupération, pas de base de données vectorielle, et pas de latence par requête. Ce qui semble être une contrainte est tout le point.

Ça marche parce que ça traite la mémoire comme un cerveau fonctionne plutôt que comme une base de données — petit, curaté et toujours actif. L’agent ne récupère pas la mémoire quand il en a besoin ; la mémoire est simplement toujours là, tissée dans le prompt système dès le premier jeton de chaque session.

Les fournisseurs de mémoire externes étendent ce système pour les utilisateurs qui en ont besoin : graphes de connaissances, support multi-agent, stockage auto-hébergé, fonctionnalités d’entreprise. Mais le noyau reste le même : borné, curaté, toujours disponible.

Et les bases de connaissances externes — LLM Wiki, Obsidian, Notion, ArXiv — servent un rôle différent. C’est la bibliothèque, pas le cerveau. L’agent les consulte, ne les mémorise pas. Les intuitions critiques sont distillées dans la mémoire interne ; le reste reste dans la bibliothèque.

C’est ainsi qu’un agent IA se souvient de vous. Pas en stockant tout, mais en se souvenant de ce qui compte.

Hermes Agent a été publié par Nous Research en février 2026 et a atteint plus de 64 000 étoiles GitHub d’ici avril 2026 (v0.9.0), avec plus de 242 contributeurs. Il est open-source et disponible sur github.com/NousResearch/hermes-agent. Pour l’installation, la configuration et les guides de workflow, voir la vue d’ensemble d’Hermes Agent.