La plupart des interfaces de chat IA que tu as utilisées n'ont pas vraiment de mémoire. Elles ont une fenêtre de contexte, ce qui est très différent. Ce que tu as dit plus tôt dans la même conversation est encore sous les yeux du modèle. Ce que tu as dit dans la conversation d'hier a disparu. Le lendemain, tu repars de zéro, et l'assistant se présente comme un inconnu.
Hermes Agent, c'est autre chose. Il a une vraie couche de mémoire — séparée du contexte de conversation — qui apprend des choses sur toi au fil du temps, les transporte d'une session et d'une plateforme à l'autre, et fait que le bot se comporte comme la même entité à chaque fois que tu lui parles. Ce billet explique comment ça marche concrètement, quelles décisions comptent, et ce que l'interface mémoire interchangeable de la v0.7.0 a changé.
Mémoire courte vs mémoire longue
D'abord, la distinction qui compte.
La mémoire courte dans Hermes, c'est la fenêtre de contexte de la session en cours. C'est une tranche de l'historique de conversation que l'agent est en train d'avoir, gérée par une stratégie de compression proactive : quand le contexte approche de la limite du modèle, Hermes lance un passage de résumé qui condense les tours plus anciens en un résumé structuré tout en conservant les échanges les plus récents à l'identique. La compression a été affinée au fil des releases — résumés structurés avec mises à jour itératives dans la v0.4.0, protection de fin de budget tokens, endpoint de résumé configurable, et support de modèle de secours. Pour les longues conversations, ça garde silencieusement l'agent rapide et économique sans perdre le contexte important.
La mémoire longue, c'est la partie intéressante. C'est un stock de faits, de préférences, de corrections et de modèles utilisateur qui vit en dehors de la conversation. Quand tu dis au bot « je m'appelle Alice » sur Telegram aujourd'hui, ce fait est écrit en mémoire longue. Demain, quand tu lui poses une question sur Slack, le fait est récupéré et injecté dans le contexte avant que l'agent ne voie ton message. Le modèle ne voit toujours que ce qui tient dans sa fenêtre, mais la fenêtre est amorcée avec les choses qu'il devrait savoir sur toi.
La mémoire courte est un tampon. La mémoire longue est une personne.
Honcho : ce que c'est et pourquoi ça compte
Le provider de mémoire longue par défaut dans Hermes est Honcho, une librairie conçue spécifiquement pour la mémoire native IA. Le boulot de Honcho, c'est de tourner derrière l'agent et de faire trois choses précises :
- 1.Observer. Chaque message utilisateur et chaque réponse de l'agent alimentent Honcho sous forme de flux d'événements. Honcho construit un modèle utilisateur interne à partir de ce flux — pas l'historique brut du chat, mais des faits structurés et des préférences inférés de la conversation.
- 2.Raisonner sur l'utilisateur. Honcho fait tourner une petite couche « dialectique » qui essaie de construire une image cohérente de qui tu es, ce que tu veux, et ce que tu as corrigé. Ce n'est pas juste de l'extraction de mots-clés — c'est un modèle mental de l'utilisateur en continu.
- 3.Injecter. À chaque nouveau tour, Honcho produit un court extrait de contexte résumant ce qu'il pense être pertinent à ton sujet, que Hermes ajoute en préfixe au system prompt. L'extrait évolue au fur et à mesure que Honcho en apprend davantage.
Deux détails méritent qu'on s'y arrête parce qu'ils passent facilement inaperçus.
Premièrement, les écritures Honcho sont asynchrones. L'agent ne bloque pas sur une écriture mémoire. Il répond, et la couche mémoire traite l'échange en arrière-plan. Les longues conversations ne paient pas de taxe de latence pour les mises à jour mémoire, et une panne du backend mémoire n'arrête pas le bot — tu perds les mises à jour pendant la panne, mais l'assistant continue de parler.
Deuxièmement, le rappel Honcho est placé en dehors du préfixe système mis en cache. La fonctionnalité de prompt caching d'Anthropic (utilisée intensivement avec des modèles comme Claude Sonnet 4.6) a besoin que le system prompt soit stable d'un tour à l'autre pour que le cache fonctionne. L'extrait injecté par Honcho change à chaque tour, donc Hermes l'ajoute délibérément après la section système en cache. Le cache marche toujours pour les parties statiques ; la couche mémoire dynamique marche toujours pour les parties qui changent. C'est le genre de compromis mécanique qui n'apparaît jamais dans les notes de version mais qui décide si ta facture mensuelle est à 50 ou à 500 $.
Isolation multi-utilisateurs en mode gateway
Le gateway Hermes fait passer plusieurs utilisateurs par le même processus agent. La mémoire longue doit être par utilisateur, sinon les allergies d'Alice finissent dans les suggestions de recettes de Bob. La v0.3.0 a ajouté une isolation multi-utilisateurs correcte pour Honcho dans le gateway, ce qui veut dire concrètement :
- •Chaque ID utilisateur du gateway correspond à un peer Honcho distinct, et les écritures mémoire sont scopées par peer.
- •Les sessions de chat de groupe héritent par défaut des sessions par utilisateur, donc même un canal partagé écrit des flux mémoire séparés pour chaque participant.
- •L'isolation mémoire par profil (v0.5.0/v0.6.0) fait que si tu fais tourner plusieurs profils Hermes sur la même machine, la mémoire de chaque profil est un univers séparé. Changer de profil ne fait pas fuiter un persona dans un autre.
Rien de tout ça n'est visible pour les utilisateurs. Tout ça ensemble, c'est la raison pour laquelle le bot ne se trompe pas de personne.
L'interface mémoire interchangeable (v0.7.0)
Pendant les cinq premières releases de Hermes, Honcho était câblé en dur. Dans la v0.7.0, la couche mémoire a été refactorisée en une vraie interface provider — une petite ABC Python que n'importe quel backend mémoire peut implémenter. Le changement est architecturalement modeste et pratiquement énorme.
L'interface permet de remplacer le backend mémoire sans toucher au cœur de Hermes :
- •Honcho est le provider de référence (et toujours le défaut). Complet, avec un vrai modèle utilisateur et une isolation multi-utilisateurs correcte.
- •Supermemory a été ajouté dans la v0.8.0 comme second provider de premier rang, avec support multi-conteneurs, modes de recherche configurables et templating d'identité.
- •mem0, OpenViking, RetainDB, Hindsight et ByteRover ont tous des plugins mémoire communautaires dans le système de plugins Hermes, avec des niveaux d'intégration variés.
- •Tu peux aussi écrire le tien. L'ABC est petite : implémente
write(),recall(), quelques hooks de cycle de vie, et enregistre-le comme plugin.
Le provider mémoire intégré — le défaut sans dépendance si tu n'as rien configuré d'autre — est un stock de faits basé sur SQLite qui gère l'essentiel : écrire des faits, les rappeler par pertinence, les scoper par utilisateur. Il n'est pas aussi malin que Honcho, mais il n'a besoin d'aucun service externe, et pour un assistant personnel sur un VPS à 5 $ c'est souvent tout ce qu'il faut.
Ce que ça débloque en silence
La mémoire interchangeable, c'est le genre de changement architectural qui ressemble à du travail de maintenance dans les notes de version. « Refactorisé la mémoire en interface provider » ne fait pas les gros titres. Ce que ça fait vraiment, c'est découpler la question « qu'est-ce qu'un assistant IA devrait retenir sur toi » de la question « comment fonctionne Hermes ».
Tu peux maintenant remplacer Honcho par un backend mémoire adapté à ton cas — un vector store pour ceux qui veulent de la recherche sémantique sur une base de connaissances personnelle, une base de données en graphe pour ceux qui veulent des relations d'entités explicites, un store SQLite purement local pour ceux qui ne veulent pas que des données de mémoire quittent leur machine, un service mémoire interne d'entreprise pour les équipes. L'agent ne change pas. Seul ce qui se trouve derrière l'interface memory change.
C'est la bonne abstraction pour un projet qui veut durer quelques années. La mémoire est personnelle, et le bon backend mémoire pour toi n'est pas forcément le bon pour quelqu'un d'autre. Le rôle de Hermes, c'est de bien se comporter avec la couche mémoire que tu branches — et de ne pas se mettre en travers.