Système de mémoire de l'agent 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, vous expliquez votre projet, vous partagez vos préférences, vous effectuez quelques tâches, puis vous fermez l’onglet. Vous revenez la semaine suivante et c’est comme si vous parliez à un inconnu — tout le contexte a disparu, chaque préférence est oubliée, le projet doit être réexpliqué depuis le début.

Ce n’est pas un bug. C’est ainsi que les grands modèles de langage (LLM) sont conçus. Ils sont sans état (stateless) : chaque requête est indépendante, chaque réponse est générée à partir du prompt que vous envoyez à l’instant présent, sans mémoire, sans historique et sans continuité au-delà des tokens de la fenêtre de contexte actuelle.

Pour des interactions à tour unique, cela convient parfaitement. Posez une question, obtenez une réponse, passez à autre chose. Mais pour les agents — des systèmes censés faire des choses à travers plusieurs sessions, apprendre de leurs erreurs et évoluer avec vous — l’absence d’état est 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 threads. Des frameworks comme Letta, Zep et Cognee ont construit des architectures entières autour de la mémoire persistante. Databricks a publié des travaux sur le « scaling de la mémoire » — l’idée que la performance d’un agent s’améliore avec l’expérience accumulée. Des articles de référence dédiés, des études sur la mémoire épisodique et un écosystème d’outils en pleine croissance ont émergé depuis 2024 pour traiter ce qui est de plus en plus reconnu comme l’un des problèmes centraux de l’IA agentique.

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

Hermes Agent adopte une approche fondamentalement différente. La mémoire n’est pas quelque chose que l’agent récupère quand il en a besoin. C’est quelque chose que l’agent est à tout moment — intégré dans le prompt système, organisé, limité 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 de l’agent IA

Pourquoi « simplement ajouter du contexte » ne permet pas de passer à l’échelle pour les agents

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

Pendant un certain temps, cela fonctionne. Vous disposez d’une fenêtre de contexte de 128K. Vous pouvez y mettre beaucoup de texte.

Mais le contexte n’est pas la mémoire — il existe une différence réelle et importante entre les deux. Le contexte est tout ce qui vous est montré en ce moment même ; la mémoire est ce que vous gardez activement et que vous transportez avec vous.

Le contexte ne bénéficie d’aucune sélection. C’est un déversement brut : à mesure qu’il croît, le modèle doit traiter des milliers de tokens d’historique non pertinent pour trouver le seul fait dont il a besoin. Cela coûte des tokens et de l’argent, aggrave la latence et finit par atteindre un plafond.

La mémoire est organisée. C’est la distillation de l’expérience en quelque chose de compact et d’actionnable. Elle ne croît 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 qui comptent : à qui vous parlez, ce qui les intéresse, ce sur quoi vous vous êtes mis d’accord, ce que vous avez appris. Le reste est soit oublié, soit consultable quand 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 tests dédiées, une littérature de recherche croissante et un écart de performance mesurable entre les différentes approches architecturales. Voici où nous en sommes.

Letta (anciennement MemGPT) a été l’un des premiers frameworks à traiter la mémoire persistante comme une priorité de premier ordre, atteignant 21,7K étoiles sur GitHub. Il utilise un modèle à trois niveaux inspiré des systèmes d’exploitation : la mémoire centrale (petite, toujours dans le contexte), la mémoire de rappel (historique de conversation consultable) et la mémoire d’archivage (stockage à froid à long terme). L’idée que toute la mémoire n’est pas égale était correcte. L’implémentation, cependant, exige que les agents s’exécutent entièrement à l’intérieur de l’environnement d’exécution 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 une information était vraie. C’est très efficace pour les chatbots ayant besoin de graphes de relations, mais moins adapté aux agents autonomes suivant les faits de l’environnement 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 la connaissance institutionnelle et les pipelines RAG, mais se concentre moins sur la mémoire personnelle de l’agent. Consultez l’auto-hébergement de Cognee avec des LLM locaux pour un guide de configuration pratique.

Hindsight effectue un rappel basé sur un graphe de connaissances avec des relations entre entités et un outil de synthèse unique reflect qui réalise une synthèse multi-mémoires — combinant plusieurs souvenirs en de nouvelles perspectives. Il figure parmi les meilleurs performeurs sur les benchmarks de mémoire d’agent et est disponible comme fournisseur de mémoire pour Hermes Agent.

Mem0 gère l’extraction de la mémoire côté serveur via l’analyse par LLM, nécessitant une configuration minimale. L’article de recherche Mem0, publié à l’ECAI 2025 (arXiv:2504.19413), a comparé dix approches distinctes de la mémoire IA et a validé l’approche de l’extraction sélective — stocker des faits discrets, dédupliquer et ne récupérer que ce qui est pertinent. Mem0 a atteint environ 48K étoiles sur GitHub et prend en charge 21 intégrations de frameworks. Le compromis réside dans la dépendance au cloud et le coût.

Les recherches de Databricks sur le passage à l’échelle de la mémoire ont introduit le concept selon lequel la performance de l’agent s’améliore avec l’expérience accumulée. Leur architecture conserve les prompts système, les actifs de l’entreprise et les mémoires épisodiques/sémantiques définis au niveau de l’organisation et de l’utilisateur, validant l’idée que la qualité de la mémoire compte autant que la capacité du modèle.

Le point commun à la plupart des frameworks est qu’ils traitent la mémoire comme un problème de récupération : la stocker quelque part, la questionner quand nécessaire, l’injecter 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ébut de la session et est toujours présente. Toujours active, toujours disponible, suffisamment organisée pour rester utile.

Partie 2 : Architecture

Lisez cette partie de haut en bas — les couches et le rappel/stockage par tour d’abord, ensuite ce qui réside dans MEMORY.md et USER.md, puis comment attacher un fournisseur externe.

Deux couches

Hermes empile la mémoire en deux couches :

1. Intégrée — MEMORY.md et USER.md, basée sur des fichiers, toujours active. Limites strictes de 2 200 caractères (notes de l’agent) et 1 375 caractères (profil utilisateur).
2. Un fournisseur externe (optionnel) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, et les autres que vous activez via la configuration. Un seul backend externe fonctionne à la fois. Il ajoute la récupération et la rétention aux côtés des fichiers ; il ne les remplace pas.

Le modèle mental est additif — des fichiers de base gelés plus au maximum un plugin. Des hooks de préchargement (prefetch) et de synchronisation (sync) orchestrent la couche externe ; les deux fichiers restent injectés séparément en tant que partie intégrante du prompt système gelé.

Flux d’exécution (prefetch et sync)

Le rappel se produit avant que le modèle ne réponde ; la persistance se produit après le message de l’assistant. Dans le gestionnaire de mémoire de Hermes Agent, cela correspond au prefetch à l’entrée et au sync à la sortie. Les noms ci-dessous correspondent à l’implémentation (MemoryManager, prefetch / sync_turn / queue_prefetch par fournisseur).

Message utilisateur
    |
    v
MemoryManager.prefetch_all(query)        <-- phase de rappel
    |
    +-- provider.prefetch(query)        <-- chaque fournisseur externe cherche dans son stockage
    |
    v
Contexte injecté dans le tour LLM
    |
    v
Le LLM répond (message de l'assistant)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- phase de stockage
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- recherche en arrière-plan pour le tour suivant

Les fichiers intégrés MEMORY.md et USER.md ne sont pas récupérés via prefetch_all — ils font déjà partie du prompt système gelé. Les backends externes se branchent sur prefetch_all / sync_all ; queue_prefetch permet à un fournisseur de préparer la récupération pour le tour suivant sans bloquer la réponse actuelle.

Trois chemins vers la mémoire à long terme

1. Outil memory intégré. Le modèle appelle memory avec add, replace, ou remove lorsque les instructions indiquent que quelque chose doit persister — faits durables, préférences, corrections, notes sur l’environnement. target='user' maintient USER.md ; target='memory' maintient MEMORY.md. Exemple de forme : memory(action='add', target='user', content='…').

2. Rétention passive sur les fournisseurs externes. À chaque tour, le framework invoque le chemin de synchronisation du fournisseur afin que la conversation puisse être découpée en segments, résumée ou extraite sans que le modèle n’ait à nommer chaque fait. Le comportement diffère selon le backend — par exemple, Hindsight regroupe les tours et exécute une rétention structurée avec des entités et des relations ; Honcho envoie le dialogue via son pipeline dialectique ; les piles de type Mem0 et Supermemory extraient les faits passivement à partir des tours.

3. Outils spécifiques au fournisseur. Lorsque le plugin les expose, des écritures explicites telles que honcho_conclude, hindsight_retain, ou honcho_profile stockent des segments durables à la demande.

Rappel automatique versus outils de fournisseur

La mémoire centrale n’a pas besoin d’un outil de lecture — elle est déjà présente dans le prompt. Les backends externes ajoutent soit une injection automatique via le prefetch (pas d’appel d’outil de rappel distinct pour cette partie du contexte), soit des outils de récupération explicites (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect, et consorts) lorsque le modèle a besoin d’une requête plus précise que le prefetch seul.

Modes de rappel (fournisseurs externes)

Les plugins prennent en charge un mode de rappel configurable (généralement recall_mode à côté de memory.provider dans la configuration) qui échange des tokens contre du contrôle.

Lorsqu’aucun fournisseur externe n’est défini (memory.provider vide ou non défini), seuls les fichiers intégrés et la recherche de session s’appliquent — pas de prefetch/sync via un plugin.

Chemins sur le disque et budgets

La mémoire intégrée de Hermes Agent réside dans deux fichiers.

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

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

MEMORY.md : Les notes de l’agent

C’est ici 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 à ~/code/gateway utilisant gRPC + PostgreSQL
Cette machine tourne sous Ubuntu 22.04, possède Docker et kubectl installés
L'utilisateur préfère le snake_case pour les noms de variables et évite le camelCase

Ce ne sont pas des journaux de bord (logs). Ce sont des faits. Denses, déclaratifs, chargés d’informations. Pas de horodatage, pas de superflu, pas de « le 5 janvier, l’utilisateur m’a demandé de… ».

USER.md : Le profil utilisateur

C’est ici 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 le snake_case pour les noms de variables et évite le 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, agacements. Ce qui fait que l’agent vous répond différemment qu’à n’importe qui d’autre.

Le modèle de l’instantané gelé (Frozen Snapshot)

Au début de la session, les deux fichiers sont chargés depuis le disque et injectés sous forme de bloc gelé dans le prompt système. Voici à quoi cela ressemble :

══════════════════════════════════════════════
MEMORY (vos notes personnelles) [7% — 166/2 200 caractères]
══════════════════════════════════════════════
Le projet de l'utilisateur est un microservice Go à ~/code/gateway utilisant gRPC + PostgreSQL
§
Cette machine tourne sous Ubuntu 22.04, possède Docker et kubectl installés
§
L'utilisateur préfère le snake_case pour les noms de variables et évite le 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 le snake_case pour les noms de variables et évite le camelCase.
§

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

Pourquoi gelé ? Pour le caching de préfixe. Le prompt système est le même pour chaque tour d’une session. En gardant la mémoire statique après le début de la session, le modèle peut mettre en cache le calcul du préfixe et ne traiter que les parties variables — la conversation. Il s’agit d’une optimisation de performance significative. Vous ne recalculez pas l’attention sur les mêmes tokens de mémoire à chaque tour.

Les modifications effectuées pendant une session sont enregistrées immédiatement sur le disque, mais elles n’apparaissent dans le prompt système qu’au prochain démarrage de session. Les réponses des outils montrent toujours l’état en direct, mais l’« esprit » du modèle ne change pas en milieu de session. Cela empêche le modèle de tourner en rond — à mettre à jour la mémoire pour ensuite réagir à sa propre mise à jour dans la même conversation.

Les limites de caractères comme une 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 sélection.

Une mémoire illimitée est un fardeau. Elle encourage à tout déverser sans jamais consolider, finissant par devenir du bruit. Une mémoire limitée force l’agent à être sélectif. Qu’est-ce qui est réellement important ? De quoi aurais-je besoin à nouveau ? Qu’est-ce qui peut être compressé sans perdre de sens ?

Lorsque la mémoire est pleine, l’agent ne se contente pas d’échouer silencieusement. Il reçoit une erreur avec les entrées actuelles et l’utilisation, puis suit un flux de travail :

1. Lire les entrées actuelles à partir de la réponse d’erreur
2. Identifier les entrées supprimables ou consolidables
3. Utiliser replace pour fusionner des 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 organisée de faits qui comptent.

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 d’identifiants, les portes dérobées SSH et les caractères Unicode invisibles.

La mémoire est également dédupliquée. Les entrées strictement identiques sont automatiquement rejetées. Cela empêche les adversaires de tenter d’injecter du contenu malveillant par des soumissions répétées.

Fournisseurs de mémoire externes (activation et liens)

Au-delà de MEMORY.md et USER.md intégrés, Hermes Agent peut attacher un seul plugin de mémoire externe à la fois — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover ou Supermemory — pour une connaissance persistante entre les sessions. Un seul fournisseur externe est actif à la fois ; les deux fichiers de base restent chargés à ses côtés (ajout, pas remplacement).

Activez et inspectez les fournisseurs avec hermes memory setup, hermes memory status, et hermes memory off, ou configurez memory.provider et recall_mode dans ~/.hermes/config.yaml. Les modèles d’identifiants varient (par exemple HINDSIGHT_API_KEY, clés Honcho sous $HERMES_HOME/honcho.json) ; utilisez hermes memory setup pour un câblage interactif.

Structure YAML minimale (uniquement intégrée) :

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Exemple d’activation pour un backend (remplacez hindsight par honcho, mem0, supermemory ou d’autres pris en charge par votre installation) :

memory:
  provider: "hindsight"

Pour le tableau comparatif complet, les notes sur la dépendance aux LLM et aux embeddings, les détails par fournisseur et la relation entre ces backends et OpenClaw ou d’autres piles, consultez la comparaison des fournisseurs de mémoire d’agent.

Pour le câblage spécifique au profil et les flux de travail de production, consultez la configuration de production de Hermes Agent. Le hub de la mémoire des systèmes d’IA répertorie ce guide ainsi que les articles connexes sur Cognee et la couche de connaissance.

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

La question la plus courante concernant la mémoire de Hermes Agent est de savoir quand il enregistre réellement quelque chose.

La réponse est : constamment, mais de manière sélective. L’agent gère sa propre mémoire via l’outil memory, et la décision d’enregistrer est dictée par une combinaison de signaux explicites et de modèles implicites.

Déclencheurs d’écriture : Quand l’agent décide-t-il d’enregistrer ?

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

Corrections de l’utilisateur. Lorsque vous corrigez l’agent, c’est un signal pour s’en souvenir. « Ne refais plus ça. » « Utilise plutôt ceci. » « Retiens bien cela. » 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 enregistre : 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 modèles et en déduit des préférences. Si vous utilisez systématiquement un certain outil, framework ou flux de travail, cela est enregistré.

Exemple : après vous avoir vu utiliser poetry plusieurs fois dans différents projets, l’agent l’enregistre comme une préférence.

Faits sur l’environnement. Des choses concernant la machine, le projet, les outils installés. Ils sont découverts par l’exploration et enregistrés comme des faits.

Exemple : l’agent vérifie ce qui est installé et enregistre : Cette machine tourne sous Ubuntu 22.04, possède Docker et kubectl installés.

Conventions de projet. La structure du projet, les outils utilisés, les modèles suivis. Ils sont découverts par l’inspection du code et enregistrés.

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

Flux de travail complexes terminés. Après avoir accompli une tâche nécessitant plus de 5 appels d’outils, l’agent envisage d’enregistrer l’approche comme une compétence ou note au moins ce qui a fonctionné.

Particularités des outils et solutions de contournement. Lorsque l’agent découvre quelque chose de non évident sur un outil, une API ou un système — une limitation, une astuce, une convention — il l’enregistre.

Ce qui est ignoré :

• Les informations triviales ou évidentes
• Les choses facilement redécouvrables
• Les déversements de données brutes
• L’éphémère spécifique à une session
• Les informations déjà présentes dans les fichiers de contexte (SOUL.md, AGENTS.md)

Déclencheurs de lecture : Quand l’agent se rappelle-t-il ?

La mémoire n’est pas récupérée — elle est toujours là. Mais il existe 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 possède dès le premier token. Pas de requête, pas de latence, pas d’appel d’outil. C’est la mémoire centrale — toujours active.

session_search (à la demande). Lorsque l’agent doit trouver quelque chose issu de conversations passées qui ne figure pas dans la mémoire centrale, il utilise l’outil session_search. Celui-ci interroge SQLite (~/.hermes/state.db) avec une recherche plein texte FTS5 et une summarisation par Gemini Flash. Utilisez cela lorsque la question ressemble à « nous en avons déjà parlé » plutôt qu’à « retiens ce fait pour toujours ».

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

Outils de fournisseur externe (lorsqu’ils sont configurés). Lorsqu’un fournisseur de mémoire externe est actif, le framework exécute également une étape de préchargement automatique avant chaque réponse (voir Partie 2). Des outils supplémentaires tels que honcho_search, hindsight_recall, ou mem0_search servent à des recherches ciblées lorsque l’agent choisit une récupération explicite — selon le recall_mode, l’injection automatique, les outils, ou les deux, peuvent être actifs.

L’arbre de décision

Voici comment l’agent évalue si « cela vaut la peine d’être retenu » :

Est-ce une correction ou une instruction explicite ?
  OUI → Enregistrer dans la mémoire
  NON → Est-ce une préférence ou un modèle ?
    OUI → Enregistrer dans le profil utilisateur
    NON → Est-ce un fait d'environnement ou une convention ?
      OUI → Enregistrer dans la mémoire
      NON → Est-ce facilement redécouvrable ?
        OUI → Ignorer
        NON → Est-ce spécifique à la session ?
          OUI → Ignorer
          NON → Enregistrer dans la mémoire

L’agent ne se prend pas trop la tête. Il enregistre de manière proactive, consolide quand c’est plein et fait confiance aux limites de caractères pour garder l’ensemble concis.

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

C’est ici que la confusion survient souvent. Hermes Agent possède 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 elles servent des rôles totalement différents. Cela ressemble à la distinction entre les pipelines de génération augmentée par récupération et la mémoire de travail de l’agent — la récupération externe est bonne pour les recherches de connaissances approfondies, pas pour porter l’identité et les préférences. La mémoire interne est le cerveau de l’agent — toujours actif, organisé, transporté dans chaque session. Les bases de connaissances externes sont sa bibliothèque — de vastes ressources de référence consultées à la demande.

La distinction

Mémoire interne (le cerveau) :

• Petite, persistante, injectée dans le prompt système
• Contient : préférences de l’utilisateur, conventions de l’agent, leçons immédiates
• Toujours « à l’esprit » pendant la conversation
• Organisée, limitée, gérée activement
• Exemples : MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Bases de connaissances externes (la bibliothèque) :

• Vastes, uniquement pour la référence, accessibles à la demande
• Contient : documents, articles, code, notes, bases de données
• Accessibles 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 sont liées

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) : La base de connaissances Markdown interconnecté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 une mémoire.

Obsidian : Coffres de notes personnels 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 dans lequel Hermes peut puiser comme ressource de bibliothèque.

Notion/Airtable : Bases de données structurées et wikis accessibles via API. L’agent les interroge quand nécessaire.

ArXiv : Répertoires d’articles académiques. L’agent recherche et extrait des articles lorsqu’il fait des recherches sur un sujet.

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

Le modèle de distillation

Voici l’idée clé : les enseignements critiques provenant des bases externes peuvent être distillés dans la mémoire interne.

Exemple : l’agent lit un article sur ArXiv concernant le passage à l’échelle de la mémoire pour les agents IA. Il n’enregistre pas l’article entier en mémoire. Il enregistre la conclusion clé : Passage à l'échelle de la 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é en mémoire.

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

Quand utiliser quoi

Mémoire interne pour :

• « Qui est-ce que j’aide ? »
• « Que préfèrent-ils ? »
• « Qu’avons-nous appris à l’instant ? »
• « Quelle est la configuration du projet ? »
• « Quels outils sont disponibles ? »

Bases de connaissances externes pour :

• « Quelles sont les dernières recherches sur X ? »
• « Que contient la documentation de mon projet ? »
• « De quoi 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 chacune de manière appropriée — il ne confond pas la consultation d’un document avec le rappel de quelque chose qu’il a appris sur vous et votre environnement.

Partie 5 : Comment cela fonctionne réellement

Examinons la mécanique.

L’outil memory

L’agent gère la mémoire via un outil unique 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 car il est toujours présent.

add — Ajoute une nouvelle entrée.

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

replace — Remplace une entrée existante en utilisant une 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, le mode sombre dans le terminal")

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

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

Correspondance de sous-chaîne (Substring Matching)

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 permet des modifications chirurgicales sans connaître le contenu exact.

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

Cibles de stockage : memory vs user

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

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

Gestion de la capacité

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

De bonnes entrées de mémoire sont compactes et denses en informations :

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

De 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é à ~/code/gateway et qui 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 d’or : utilisez la mémoire pour les faits critiques qui doivent toujours être dans le contexte. Utilisez la recherche de session pour les consultations historiques.

Partie 6 : La Philosophie

Pourquoi une mémoire limitée est meilleure qu’une mémoire illimitée

L’instinct est de rendre la mémoire aussi grande que possible. Tout stocker. Récupérer ce dont on a besoin.

Une mémoire limitée fonctionne mieux. Voici pourquoi.

La sélection impose la qualité. Lorsque l’espace est limité, vous ne sauvegardez que ce qui compte. Vous compressez, consolidez et priorisez. Une mémoire illimitée encourage à tout déverser sans jamais faire de nettoyage.

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

Le bruit dégrade la performance. Plus de mémoire ne signifie pas une meilleure mémoire. Cela signifie une mémoire plus bruyante. Le modèle doit distinguer le signal du bruit, et cela demande de l’attention — une attention qui devrait être consacrée à 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 retenu.

Le problème de l’« oubli »

Les agents doivent désapprendre. Pas seulement oublier, mais supprimer activement les informations obsolètes.

Voici comment Hermes Agent gère cela :

• Action remove : Supprime les entrées qui ne sont plus pertinentes.
• Action replace : Met à jour les entrées avec de nouvelles informations.
• Pression de capacité : Lorsque 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 transporter autant de bruit que de signal.

Passage à l’échelle de la mémoire (Memory Scaling)

Databricks a introduit le concept de « memory scaling » : est-ce qu’un agent avec des milliers d’utilisateurs est plus performant qu’un agent avec un seul utilisateur ?

Leurs recherches suggèrent que oui, mais avec des nuances. Le passage à l’échelle de la mémoire nécessite :

1. Une extraction de qualité : Toutes les interactions ne valent pas la peine d’être mémorisées. L’agent doit extraire des enseignements, pas des journaux de bord.
2. Une récupération efficace : Les mémoires récupérées doivent être pertinentes. Le bruit dégrade la performance.
3. La généralisation : Les mémoires doivent être des modèles, pas des détails spécifiques. « L’utilisateur préfère Python » passe à l’échelle. « L’utilisateur a exécuté la commande X à l’horodatage Y » ne passe pas.

La mémoire limitée de Hermes Agent favorise naturellement le passage à l’échelle. En imposant la sélection, elle garantit que les mémoires sont généralisables, compactes et utiles.

Ce que cela signifie pour l’avenir

La mémoire devient le rempart concurrentiel de l’IA agentique — pas le modèle lui-même, mais ce que le modèle transporte d’une session à l’autre. Deux agents avec des modèles sous-jacents identiques peuvent se comporter de manière très différente : l’un se souvient de vos préférences, de votre environnement et de vos erreurs passées ; l’autre repart de zéro à chaque fois.

La question n’est plus de savoir si les agents doivent avoir une mémoire persistante. C’est réglé : ils le doivent. La question ouverte est la manière de concevoir cette mémoire correctement — que garder, que rejeter, comment la rendre instantanée et comment éviter qu’elle ne devienne du bruit.

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

Conclusion

Le système de mémoire de Hermes Agent est délibérément simple : deux fichiers, des limites de caractères strictes, 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 en réalité l’objectif même.

Cela fonctionne parce que le système traite la mémoire comme le ferait un cerveau plutôt que comme une base de données — petite, organisée et toujours active. 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 token de chaque session.

Les fournisseurs de mémoire externes étendent ce système pour les utilisateurs qui en ont besoin de plus : graphes de connaissances, support multi-agents, stockage auto-hébergé, fonctionnalités d’entreprise. Mais le cœur reste le même : limité, organisé, toujours disponible.

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

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

Hermes Agent a été publié par Nous Research en février 2026 et a atteint plus de 64 000 étoiles sur GitHub en 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 flux de travail, consultez la présentation de Hermes Agent.