De meeste AI-chatinterfaces die je hebt gebruikt, hebben niet echt een geheugen. Ze hebben een contextvenster, en dat is iets heel anders. Wat je eerder in hetzelfde gesprek hebt gezegd, ziet het model nog. Wat je in het gesprek van gisteren hebt gezegd, is weg. De volgende dag begin je weer van nul, en de assistent stelt zich opnieuw voor alsof jullie vreemden zijn.
Hermes Agent is anders. Het heeft een echte geheugenlaag — los van de gesprekscontext — die in de loop der tijd dingen over je leert, die dingen meeneemt over sessies en platforms heen, en de bot elke keer dat je praat als dezelfde entiteit laat aanvoelen. Dit artikel gaat over hoe dat in de praktijk werkt, welke ontwerpkeuzes ertoe doen, en wat de plugbare geheugeninterface van v0.7.0 veranderde.
Kortetermijngeheugen vs langetermijngeheugen
Eerst het onderscheid dat ertoe doet.
Kortetermijngeheugen in Hermes is het sessiecontextvenster. Het is een schijf van de gespreksgeschiedenis waar de agent nu mee bezig is, beheerd met een proactieve compressiestrategie: als de context de limiet van het model nadert, draait Hermes een samenvattingsronde die oudere beurten comprimeert tot een gestructureerde samenvatting, terwijl de meest recente uitwisselingen letterlijk bewaard blijven. De compressie is door meerdere releases heen bijgesteld — gestructureerde samenvattingen met iteratieve updates in v0.4.0, token-budgetbescherming aan de staart, een configureerbaar samenvattings-endpoint, en fallback-modelondersteuning. Bij lange gesprekken houdt dit de agent stilletjes snel en goedkoop zonder belangrijke context te verliezen.
Langetermijngeheugen is het interessante deel. Het is een opslag van feiten, voorkeuren, correcties en gebruikersmodellen die buiten het gesprek leeft. Als je vandaag op Telegram tegen de bot zegt "ik heet Alice", wordt dat feit naar het langetermijngeheugen geschreven. Morgen, als je iets vraagt op Slack, wordt dat feit eruit gehaald en in de context geïnjecteerd voordat de agent je bericht ziet. Het model krijgt nog steeds alleen wat in zijn venster past, maar dat venster is gevuld met dingen die het over je zou moeten weten.
Kortetermijngeheugen is een buffer. Langetermijngeheugen is een persoon.
Honcho: wat het is en waarom het ertoe doet
De standaard langetermijngeheugenprovider in Hermes is Honcho, een library die speciaal is gebouwd voor AI-native geheugen. De taak van Honcho is achter de agent draaien en drie specifieke dingen doen:
- 1.Observeren. Elk gebruikersbericht en elk agentantwoord vloeit Honcho in als een eventstroom. Honcho bouwt een intern gebruikersmodel uit die stroom — geen ruwe chatgeschiedenis, maar gestructureerde feiten en voorkeuren die uit het gesprek zijn afgeleid.
- 2.Redeneren over de gebruiker. Honcho draait een kleine "dialectische" laag die probeert een samenhangend beeld op te bouwen van wie je bent, wat je wilt en wat je hebt gecorrigeerd. Dit is geen keyword-extractie — het is een doorlopend mentaal model van de gebruiker.
- 3.Injecteren. Bij elke nieuwe beurt produceert Honcho een kort contextfragment dat samenvat wat het denkt dat belangrijk is over jou, en Hermes plakt dit vóór de systeemprompt. Het fragment verandert naarmate Honcho meer leert.
Twee details verdienen extra aandacht omdat ze makkelijk gemist worden.
Ten eerste zijn Honcho-schrijfacties asynchroon. De agent blokkeert niet op een geheugenschrijfactie. Hij antwoordt, en de geheugenlaag verwerkt de uitwisseling op de achtergrond. Dit betekent dat lange gesprekken geen latencybelasting betalen voor geheugen-updates, en een storing van de geheugenbackend de bot niet stopt — je verliest updates tijdens de storing, maar de assistent blijft praten.
Ten tweede wordt Honcho-recall bewust buiten de gecachete systeemprefix gehouden. De prompt-cachingfunctie van Anthropic (intensief gebruikt bij modellen als Claude Sonnet 4.6) wil dat de systeemprompt stabiel is tussen beurten zodat de cache raakt. Het geïnjecteerde fragment van Honcho verandert elke beurt, dus Hermes voegt het bewust na het gecachete systeemdeel toe. De cache werkt nog steeds voor de statische delen; de dynamische geheugenlaag werkt nog steeds voor de delen die veranderen. Dit is het soort mechanische afweging dat niet in releasenotes terechtkomt maar bepaalt of je maandelijkse rekening $50 of $500 is.
Multi-gebruikersisolatie in gatewaymodus
De standaard Hermes-gateway stuurt meerdere gebruikers door hetzelfde agentproces. Langetermijngeheugen moet per gebruiker zijn, anders belanden Alice' allergieën in Bobs kooksuggesties. De v0.3.0-release voegde goede multi-gebruikersisolatie toe voor Honcho binnen de gateway, wat in de praktijk betekent:
- •Elke gateway-user-ID mapt naar een aparte Honcho-peer, en geheugen-schrijfacties zijn per peer gescoped.
- •Groepschatsessies erven standaard per-gebruikersessies, dus een gedeeld kanaal schrijft nog steeds aparte geheugenstromen voor elke deelnemer.
- •Profielgebonden geheugenisolatie (v0.5.0/v0.6.0) betekent dat als je meerdere Hermes-profielen op dezelfde machine draait, het geheugen van elk profiel een apart universum is. Wisselen van profiel lekt niet van de ene persona in de andere.
Niets hiervan is zichtbaar voor gebruikers. Het is allemaal de reden dat de bot niet per ongeluk de verkeerde persoon onthoudt.
De plugbare geheugeninterface (v0.7.0)
De eerste vijf releases van Hermes hadden Honcho hardcoded. In v0.7.0 werd de geheugenlaag gerefactord naar een echte providerinterface — een kleine Python ABC die elke geheugenbackend kan implementeren. De verandering is architecturaal bescheiden en praktisch enorm.
De interface laat je geheugenbackends wisselen zonder de kern van Hermes aan te raken:
- •Honcho is de referentieprovider (en nog steeds de standaard). Volledig uitgerust, bouwt een echt gebruikersmodel, en handelt multi-gebruikersisolatie correct af.
- •Supermemory werd in v0.8.0 toegevoegd als tweede eersteklas provider, met multi-containerondersteuning, configureerbare zoekmodi en identiteitstemplating.
- •mem0, OpenViking, RetainDB, Hindsight en ByteRover hebben allemaal community-geheugenplugins in het Hermes-pluginsysteem, met wisselende integratiediepte.
- •Je kunt ook je eigen schrijven. De ABC is klein: implementeer
write(),recall(), een paar lifecycle-hooks, en registreer als plugin.
De ingebouwde geheugenprovider — de standaard zonder dependencies als je verder niets hebt ingesteld — is een op SQLite gebaseerde feitenopslag die de basis dekt: feiten schrijven, ophalen op relevantie, scopen per gebruiker. Niet zo slim als Honcho, maar heeft geen externe service nodig, en voor een persoonlijke assistent op een VPS van $5 is het vaak alles wat je nodig hebt.
Wat dit stilletjes ontgrendelt
Plugbaar geheugen is het soort architectuurwijziging dat er in releasenotes uitziet als huishoudelijk werk. "Geheugen gerefactord naar een providerinterface" is geen krantenkop. Maar wat het in werkelijkheid doet is de vraag "wat moet een AI-assistent over je onthouden" losmaken van de vraag "hoe werkt Hermes."
Je kunt Honcho nu vervangen door een geheugenbackend die is afgestemd op jouw use case — een vector store voor mensen die semantisch zoeken willen in een persoonlijke kennisbank, een graph database voor mensen die expliciete entiteitsrelaties willen, een puur lokale SQLite-opslag voor mensen die geen geheugendata hun machine af willen laten gaan, een bedrijfsinterne geheugendienst voor teams. De agent verandert niet. Alleen wat er achter de memory-interface zit.
Dat is de juiste abstractie voor een project dat er over een paar jaar nog wil zijn. Geheugen is persoonlijk, en de juiste geheugenbackend voor jou is niet per se de juiste voor iemand anders. De taak van Hermes is een goede buur zijn voor welke geheugenlaag je ook aansluit, en niet in de weg zitten.