Hermes Agent Memory System: hoe persistent AI-geheugen daadwerkelijk werkt

Je kent de procedure. Je opent een chat met een AI-agent, legt je project uit, deelt je voorkeuren, laat werk doen en sluit het tabblad. Als je de volgende week terugkomt, lijkt het alsof je tegen een vreemde praat — alle context is weg, elke voorkeur vergeten, het project moet opnieuw van begin af aan worden uitgelegd.

Dit is geen bug. Zo werken Large Language Models (LLM’s) nu eenmaal. Ze zijn staatloos: elke aanvraag is onafhankelijk, elk antwoord wordt gegenereerd op basis van de prompt die je nu stuurt, zonder geheugen, zonder geschiedenis en zonder continuïteit buiten de tokens in de huidige contextvenster.

Voor interacties met één beurt is dat prima. Stel een vraag, krijg een antwoord, ga verder. Maar voor agents — systemen die over sessies heen dingen moeten doen, van fouten moeten leren en met je mee moeten evolueren — is staatloosheid een harde architectuurbeperking. Het is een van de centrale, nog niet opgeloste problemen in zelfgehoste AI-systemen.

De industrie heeft geprobeerd dit op te lossen. LangChain voegde geheugensmodules toe. OpenAI introduceerde assistenten met threads. Frameworks zoals Letta, Zep en Cognee bouwden hele architecturen rondom persistent geheugen. Databricks publiceerde over “memory scaling” — het idee dat de prestaties van agents verbeteren met opgebouwde ervaring. Sinds 2024 zijn er speciale benchmarkpapers, overzichten van episodisch geheugen en een snel groeiend ecosysteem van tools ontstaan om aan te sluiten bij wat steeds vaker wordt gezien als een van de centrale, nog niet opgeloste problemen in agentic AI.

De meeste van deze aanpakken delen een gemeenschappelijk probleem: ze behandelen geheugen als een afterthought — een database die je queryt, een contextvenster dat je vult, een retrieval-systeem dat latentie en ruis toevoegt in plaats van duidelijkheid.

Hermes Agent kiest voor een fundamenteel andere aanpak. Geheugen is iets wat de agent niet ophaalt wanneer nodig. Het is iets wat de agent is te allen tijde — ingebouwd in de system prompt, gecureerd, begrensd en altijd actief. Het is klein genoeg om snel te zijn, gestructureerd genoeg om nuttig te zijn, en gedisciplineerd genoeg om te weten wat vergeten moet worden.

Dit artikel legt precies uit hoe dat werkt.

Deel 1: Het AI-Agent Geheugenprobleem

Waarom “Gewoon Context Toevoegen” Niet Schaleerbaar is voor Agents

De voor de hand liggende oplossing voor staatloze AI is het toevoegen van context. Voeg het vorige gesprek toe. Neem de projectdocumentatie mee. Stuur de hele geschiedenis.

Een tijdlang werkt dat. Je hebt een contextvenster van 128K tokens. Je kunt daar veel tekst in kwijt.

Maar context is geen geheugen — er is een echt en belangrijk verschil tussen beide. Context is alles wat je nu te zien krijgt; geheugen is wat je actief bewaart en meeneemt.

Context heeft geen curatie. Het is een dump: naarmate het groeit, moet het model duizenden tokens onrelevante geschiedenis verwerken om het ene feite te vinden dat het nodig heeft. Dat kost tokens en geld, verergert latentie en stuit uiteindelijk tegen het plafond.

Geheugen is gecureerd. Het is de distillatie van ervaring tot iets compacts en uitvoerbaars. Het groeit niet onbeperkt — het consolideert, update en vergeten.

Menselijk geheugen werkt op dezelfde manier. Je herinnert je niet elk gesprek dat je ooit hebt gevoerd. Je herinnert je de delen die belangrijk zijn: met wie je praat, waar ze zich zorgen over maken, wat je hebt afgesproken, wat je hebt geleerd. De rest is ofwel vergeten ofwel zoekbaar wanneer je het nodig hebt.

Het Onderzoekslandschap

De ruimte voor AI-agent geheugen is sinds 2024 geëxplodeerd, met speciale benchmarksuites, een groeiende onderzoeksliteratuur en een meetbaar prestatieverschil tussen verschillende architecturaanse benaderingen. Hier is waar de zaken staan.

Letta (voorheen MemGPT) was een van de eerste frameworks die persistent geheugen als een eerste-class aandachtspunt behandelde, met 21.7K GitHub-sterren. Het gebruikt een op een OS geïnspireerd drielaags model: kerngeheugen (klein, altijd in context), herinneringsgeheugen (zoekbare gespreksgeschiedenis) en archiefgeheugen (langdurige koude opslag). Het inzicht dat niet alle geheugens gelijk zijn, was correct. De implementatie vereist echter dat agents volledig binnen de Letta-runtime draaien — adoptie betekent het overnemen van het hele platform, niet alleen een geheugenlaag.

Zep / Graphiti richt zich op conversationeel geheugen met temporele entity-tracking — feiten hebben geldigheidsvensters zodat de grafiek weet wanneer iets waar was. Het is sterk voor chatbots die relatiegrafieken nodig hebben, maar minder geschikt voor autonome agents die omgevingsfeiten en projectconventies bijhouden.

Cognee is gebouwd voor kennisextractie uit documenten en gestructureerde data, met 30+ innameconnectoren en een knowledge-graph-backend. Het excelleert in institutionele kennis en RAG-pijplijnen, maar is minder gericht op persoonlijk agentengeheugen. Zie zelfhosting van Cognee met lokale LLM’s voor een praktische instellingsgids.

Hindsight doet knowledge-graph-gebaseerde recall met entity-relaties en een unieke reflect-samenstellingstool die cross-geheugensamenstelling uitvoert — het combineren van meerdere herinneringen tot nieuwe inzichten. Het behoort tot de top performers op agentengeheugen-benchmarks en is beschikbaar als geheugenprovider voor Hermes Agent.

Mem0 behandelt geheugenextractie server-side via LLM-analyse, met minimale configuratie nodig. Het Mem0-onderzoekspaper, gepubliceerd op ECAI 2025 (arXiv:2504.19413), benchmarkte tien verschillende aanpakken voor AI-geheugen en valideerde de selectieve extractiebenadering — het opslaan van discrete feiten, deduplicatie en alleen het ophalen wat relevant is. Mem0 is gegroeid naar ongeveer 48K GitHub-sterren en ondersteunt 21 framework-integraties. De afweging is cloud-afhankelijkheid en kosten.

Databricks’ memory scaling-onderzoek introduceerde het concept dat agentenprestaties verbeteren met opgebouwde ervaring. Hun architectuur houdt system prompts, enterprise-assets en episodisch/semantisch geheugen vast op organisatie- en gebruikersniveau, en valideert het idee dat geheugenkwaliteit net zo belangrijk is als modelcapaciteit.

De gemeenschappelijke noemer in de meeste frameworks is dat ze geheugen behandelen als een retrieval-probleem: sla het ergens op, query het wanneer nodig, injecteer het in de context. Hermes doet het tegenovergestelde — geheugen wordt niet op verzoek opgehaald, het wordt bij het start van de sessie geïnjecteerd en altijd aanwezig. Altijd actief, altijd beschikbaar, gecureerd genoeg om nuttig te blijven.

Deel 2: Architectuur — Twee Bestanden, Eén Brein

Het ingebouwde geheugensysteem van Hermes Agent bestaat uit twee bestanden.

• ~/.hermes/memories/MEMORY.md — Persoonlijke notities van de agent (2.200 karakters, ~800 tokens)
• ~/.hermes/memories/USER.md — Gebruikersprofiel (1.375 karakters, ~500 tokens)

Dat is het hele persistente geheugenoppervlak: twee bestanden, minder dan 3.600 karakters in totaal, minder dan 1.300 tokens. Het ziet er bewust klein uit omdat het dat ook is — en dat is precies de ontwerpintentie.

MEMORY.md: De Notities van de Agent

Hier slaat de agent alles op wat het leert over zijn omgeving, het project, tools, conventies en lessen die zijn geleerd. Zo ziet het eruit:

Het project van de gebruiker is een Go-microservice op ~/code/gateway met gebruik van gRPC + PostgreSQL
Deze machine draait Ubuntu 22.04, heeft Docker en kubectl geïnstalleerd
Gebruiker geeft de voorkeur aan snake_case voor variablenamen en vermijdt camelCase

Dit zijn geen logs. Het zijn feiten. Dicht, declaratief, informatiepakketten. Geen tijdstempels, geen wolligheid, geen “op 5 januari vroeg de gebruiker me om…”

USER.md: Het Gebruikersprofiel

Hier slaat de agent alles op wat het over jou weet.

Gebruiker is een full-stack developer die vertrouwd is met TypeScript, Go en Python.
Gebruiker geeft de voorkeur aan snake_case voor variablenamen en vermijdt camelCase.
Gebruiker gebruikt voornamelijk Linux Ubuntu 22.04.
Gebruiker deployt naar AWS met behulp van Terraform.

Identiteit, rol, voorkeuren, technische vaardigheden, communicatiestijl, irritaties. Het spul dat ervoor zorgt dat de agent anders op jou reageert dan op iedereen anders.

Het Frozen Snapshot-Patroon

Bij het begin van een sessie worden beide bestanden van de schijf geladen en als een bevroren blok geïnjecteerd in de system prompt. Zo ziet het eruit:

══════════════════════════════════════════════
GEHEUGEN (je persoonlijke notities) [7% — 166/2.200 karakters]
══════════════════════════════════════════════
Het project van de gebruiker is een Go-microservice op ~/code/gateway met gebruik van gRPC + PostgreSQL
§
Deze machine draait Ubuntu 22.04, heeft Docker en kubectl geïnstalleerd
§
Gebruiker geeft de voorkeur aan snake_case voor variablenamen en vermijdt camelCase
§

══════════════════════════════════════════════
GEBRUIKERSPROFIEL (wie de gebruiker is) [8% — 110/1.375 karakters]
══════════════════════════════════════════════
Gebruiker is een full-stack developer die vertrouwd is met TypeScript, Go en Python.
§
Gebruiker geeft de voorkeur aan snake_case voor variablenamen en vermijdt camelCase.
§

Het formaat gebruikt headers, gebruikspercentages, karakteraantallen en § (sectieteken) als scheidingstekens. Items kunnen meerdere regels beslaan. Het is ontworpen om parsebaar te zijn door het model terwijl het menselijk leesbaar blijft.

Waarom bevroren? Prefix caching. De system prompt is hetzelfde over elke beurt in een sessie. Door het geheugen statisch te houden na het start van de sessie, kan het model de prefix-berekening cachen en alleen de variabele delen verwerken — het gesprek. Dit is een significante prestatieoptimalisatie. Je berekent de attention niet opnieuw over dezelfde geheugentokens bij elke beurt.

Wijzigingen die tijdens een sessie worden gemaakt, worden onmiddellijk naar de schijf geschreven, maar ze verschijnen pas in de system prompt bij het begin van de volgende sessie. Tool-antwoorden tonen altijd de live-status, maar het “brein” van het model verandert niet midden in een sessie. Dit voorkomt dat het model in zijn eigen staart bijt — het updaten van geheugen en dan reageren op zijn eigen update in hetzelfde gesprek.

Karakterlimieten als Functie

2.200 karakters. 1.375 karakters. Dit zijn geen willekeurige limieten. Het zijn ontwerpbepalingen die curatie forceren.

Onbeperkt geheugen is een last. Het moedigt aan om alles erin te dumpen, nooit te consolideren en uiteindelijk ruis te worden. Begrensd geheugen dwingt de agent om selectief te zijn. Wat is echt belangrijk? Wat heb ik opnieuw nodig? Wat kan ik comprimeren zonder betekenis te verliezen?

Wanneer het geheugen vol is, faalt de agent niet stil. Het krijgt een foutmelding met de huidige items en het gebruik, en volgt dan een workflow:

1. Lees huidige items van de foutrespons
2. Identificeer verwijderbare of consolideerbare items
3. Gebruik replace om gerelateerde items samen te voegen tot kortere versies
4. Voeg het nieuwe item toe

Zo blijft geheugen nuttig. Het is geen database. Het is een gecureerde collectie feiten die ertoe doen.

Beveiliging: Prompt Injection Scanning

Elk geheugenitem wordt gescand voordat het wordt geaccepteerd. Het systeem blokkeert pogingen tot prompt injection, credential-exfiltratie, SSH-backdoors en onzichtbare Unicode-karakters.

Geheugen wordt ook gedupliceerd. Exacte dubbele items worden automatisch afgewezen. Dit voorkomt dat tegenstanders proberen om kwaadaardige inhoud te injecteren door herhaalde inzendingen.

Deel 3: Wanneer Geheugen Actief Wordt — Triggers & Beslissingen

De meest gestelde vraag over het geheugen van Hermes Agent is wanneer het iets echt opslaat.

Het antwoord is: constant, maar selectief. De agent beheert zijn eigen geheugen via de memory-tool, en de beslissing om op te slaan wordt gedreven door een combinatie van expliciete signalen en impliciete patronen.

Schrijftiggers: Wanneer Beslist de Agent om op te SLaan?

De agent slaat geheugen proactief op. Het wacht niet tot je het vraagt. Dit zijn de triggers.

Gebruikerscorrecties. Wanneer je de agent corrigeert, is dat een signaal om te onthouden. “Doe dat niet opnieuw.” “Gebruik dit in plaats daarvan.” “Onthoud dit.” Dit zijn expliciete instructies om het geheugen bij te werken.

Voorbeeld: je vraagt de agent om een Python-omgeving te configureren. Het suggereert pip. Je zegt: “Ik gebruik poetry voor alles.” De agent slaat op: Gebruiker geeft de voorkeur aan de 'poetry' package manager voor alle Python-projecten.

Ontdekte voorkeuren. De agent observeert patronen en inferent voorkeuren. Als je consequent een bepaalde tool, framework of workflow gebruikt, wordt het opgeslagen.

Voorbeeld: nadat je poetry meerdere keren hebt gebruikt in verschillende projecten, slaat de agent het op als een voorkeur.

Omgevingsfeiten. Dingen over de machine, het project, de geïnstalleerde tools. Deze worden ontdekt door verkennen en opgeslagen als feiten.

Voorbeeld: de agent checkt wat er geïnstalleerd is en slaat op: Deze machine draait Ubuntu 22.04, heeft Docker en kubectl geïnstalleerd.

Projectconventies. Hoe het project is gestructureerd, welke tools het gebruikt, welke patronen het volgt. Deze worden ontdekt door code-inspectie en opgeslagen.

Voorbeeld: Het project van de gebruiker is een Go-microservice op ~/code/gateway met gebruik van gRPC + PostgreSQL.

Voltooide complexe workflows. Na het voltooien van een taak die 5+ tool-aanroepen kostte, overweegt de agent om de aanpak op te slaan als een vaardigheid of tenminste te noteren wat werkte.

Tool-quirks en workarounds. Wanneer de agent iets niet-voor de hand liggends ontdekt over een tool, API of systeem — een beperking, een workaround, een conventie — slaat het het op.

Wat wordt overgeslagen:

• Triviale of voor de hand liggende informatie
• Dingen die makkelijk opnieuw kunnen worden ontdekt
• Raw data-dumps
• Sessiespecifieke ephemera
• Informatie die al in contextbestanden staat (SOUL.md, AGENTS.md)

Leestiggers: Wanneer Herinnert de Agent Zich?

Geheugen wordt niet opgehaald — het is er altijd. Maar er zijn verschillende niveaus van toegang.

Sessie-start (automatisch). MEMORY.md en USER.md worden geïnjecteerd in de system prompt. De agent heeft ze vanaf de eerste token. Geen query nodig, geen latentie, geen tool-aanroep. Dit is het kerngeheugen — altijd actief.

session_search (op verzoek). Wanneer de agent iets nodig heeft uit vorige gesprekken dat niet in het kerngeheugen zit, gebruikt het de session_search-tool. Dit queryt SQLite (~/.hermes/state.db) met FTS5 full-text search en Gemini Flash-summarisatie.

Voorbeeld: je vraagt “Hebben we vorige week Docker-netwerking besproken?” De agent doorzoekt de sessiegeschiedenis en retourneert een samenvatting van het relevante gesprek.

Externe provider-tools (wanneer geconfigureerd). Wanneer een extern geheugenprovider actief is, heeft de agent extra tools beschikbaar: honcho_search, hindsight_recall, mem0_search, enz. Deze worden gebruikt wanneer de agent bepaalt dat externe context nodig is.

De Beslissingboom

Zo weegt de agent “is dit het waard om te onthouden?”:

Is dit een correctie of expliciete instructie?
  JA → Sla op in geheugen
  NEE → Is dit een voorkeur of patroon?
    JA → Sla op in gebruikersprofiel
    NEE → Is dit een omgevingsfeit of conventie?
      JA → Sla op in geheugen
      NEE → Is dit makkelijk opnieuw te ontdekken?
        JA → Sla over
        NEE → Is dit sessiespecifiek?
          JA → Sla over
          NEE → Sla op in geheugen

De agent denkt hier niet te lang over. Het slaat proactief op, consolideert wanneer het vol is, en vertrouwt op de karakterlimieten om het strak te houden.

Deel 4: Intern Geheugen vs. Externe Kennisbases

Hier ontstaan vaak verwarringen. Hermes Agent heeft intern geheugen (MEMORY.md, USER.md, externe providers) en externe kennisbases (LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem), en ze dienen volledig verschillende rollen. Dit is vergelijkbaar met het onderscheid tussen retrieval-augmented generation pijplijnen en agent-werkgeheugen — externe retrieval is goed voor diepe kennisopzoeken, niet voor het dragen van identiteit en voorkeuren. Intern geheugen is het brein van de agent — altijd actief, gecureerd, meegenomen in elke sessie. Externe kennisbases zijn de bibliotheek — uitgestrekte referentiebronnen die op verzoek worden geraadpleegd.

Het Onderscheid

Intern Geheugen (het brein):

• Klein, persistent, geïnjecteerd in system prompt
• Bevat: gebruikersvoorkeuren, agentconventies, directe lessen
• Altijd “in gedachten” tijdens het gesprek
• Gecureerd, begrensd, actief beheerd
• Voorbeelden: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Externe Kennisbases (de bibliotheek):

• Uitgestrekt, alleen referentie, op verzoek toegankelijk
• Bevat: documenten, papers, code, notities, databases
• Toegankelijk via tools wanneer nodig
• Niet “herinnerd” — opgezocht
• Voorbeelden: LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem, GitHub

Hoe Ze Relatie Hebben

De agent toegankelijk externe bases via tools wanneer nodig. Het “herinnert” ze niet — het zoekt ze op.

LLM Wiki (llm-wiki): Karpathy’s onderling verbonden Markdown-kennisbasis voor het bouwen en queryen van domeinkennis. De agent gebruikt de llm-wiki-vaardigheid om het te lezen, doorzoeken en queryen. Het is een referentiebron, geen geheugen.

Obsidian: Persoonlijke notitie-vaults met bidirectionale links. De agent gebruikt de obsidian-vaardigheid om notities te lezen, doorzoeken en te maken. Obsidian is onderdeel van het bredere persoonlijke kennismanagement ecosysteem dat Hermes kan gebruiken als bibliotheekbron.

Notion/Airtable: Gestructureerde databases en wikis toegankelijk via API. De agent queryt ze wanneer nodig.

ArXiv: Academische paper-repositories. De agent doorzoekt en extract papers wanneer het een onderwerp onderzoekt.

Bestandssysteem: Projectcode, documentatie, configuraties. De agent leest bestanden wanneer het aan een project werkt.

Het Distillatiepatroon

Hier is het cruciale inzicht: cruciale inzichten uit externe bases kunnen worden gedistilleerd naar intern geheugen.

Voorbeeld: de agent leest een paper van ArXiv over memory scaling voor AI-agents. Het slaat niet het hele paper op in het geheugen. Het slaat de kernboodschap op: Memory scaling: agentenprestaties verbeteren met opgebouwde ervaring via gebruikersinteractie en business-context opgeslagen in geheugen.

De externe bron is uitgestrekt. Het interne geheugen is de distillatie.

Wanneer Welke Gebruiken

Intern geheugen voor:

• “Wie help ik?”
• “Wat zijn hun voorkeuren?”
• “Wat hebben we zojuist geleerd?”
• “Wat is de projectsetup?”
• “Welke tools zijn beschikbaar?”

Externe kennisbases voor:

• “Wat is het laatste onderzoek naar X?”
• “Wat staat in de documentatie van mijn project?”
• “Wat hebben we vorige maand besproken?”
• “Wat is de API voor deze service?”
• “Wat is de code-structuur?”

De agent begrijpt het verschil en gebruikt elk op de juiste manier — het verwardt het opzoeken van een document niet met het herinneren van iets dat het over jou en je omgeving heeft geleerd.

Deel 5: Hoe Het Eigenlijk Werkt

Laten we kijken naar de mechanica.

De memory-Tool

De agent beheert geheugen via één tool met drie acties: add, replace, remove.

Er is geen read-actie — geheugeninhoud wordt automatisch geïnjecteerd in de system prompt. De agent hoeft het niet te lezen omdat het er altijd is.

add — Voegt een nieuw item toe.

memory(action="add", target="memory",
       content="Gebruiker draait macOS 14 Sonoma, gebruikt Homebrew, heeft Docker Desktop geïnstalleerd.")

replace — Vervangt een bestaand item met behulp van substring-matching.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="Gebruiker geeft de voorkeur aan light mode in VS Code, dark mode in terminal")

remove — Verwijdert een item met behulp van substring-matching.

memory(action="remove", target="memory",
       old_text="tijdelijk projectfeit")

Substring-Matching

replace en remove gebruiken korte unieke substrings via old_text. Je hoeft niet de volledige itemtekst te kennen. Dit maakt chirurgische bewerkingen mogelijk zonder de exacte inhoud te kennen.

Als een substring overeenkomt met meerdere items, wordt een foutmelding geretourneerd die een specifiekere match vraagt. De agent verfijnt dan zijn query.

Doelopslag: memory vs user

De target-parameter bepaalt welk bestand wordt bijgewerkt.

• memory — Persoonlijke notities van de agent. Omgevingsfeiten, projectconventies, tool-quirks, geleerde lessen.
• user — Gebruikersprofiel. Identiteit, rol, tijdzone, communicatievoorkeuren, irritaties, gewoontes.

Capaciteitsbeheer

Wanneer het geheugen >80% vol is, consolideert de agent. Het voegt gerelateerde items samen, verwijdert verouderde feiten en comprimeert informatie.

Goede geheugenitems zijn compact en informatiedicht:

Gebruiker draait macOS 14 Sonoma, gebruikt Homebrew, heeft Docker Desktop geïnstalleerd. Shell: zsh met oh-my-zsh. Editor: Neovim met Telescope-plugin.

Slechte geheugenitems zijn vaag of wollig:

Gebruiker heeft een project.
Op 5 januari 2026 vroeg de gebruiker me om naar hun project te kijken, dat zich bevindt op ~/code/gateway en Go gebruikt met gRPC en PostgreSQL voor de databaselayer.

Het eerste is dicht en nuttig. Het tweede is ofwel te vaag ofwel te wollig.

Sessiezoeken vs. Persistent Geheugen

session_search en persistent geheugen dienen verschillende doelen.

Regel van duim: gebruik geheugen voor cruciale feiten die altijd in context moeten zijn. Gebruik sessiezoeken voor historische opzoeken.

Deel 6: Externe Geheugenproviders — Alle 8 Opties Vergelijken

Naast de ingebouwde MEMORY.md en USER.md, ondersteunt Hermes Agent 8 externe geheugenprovider-plugins voor persistente, cross-sessiekennis.

Alleen één externe provider kan op een gegeven moment actief zijn. De ingebouwde bestanden zijn altijd actief naast de externe provider — additief, niet vervangend.

Activering

hermes memory setup   # Interactieve kiezer + configuratie
hermes memory status  # Controleren wat actief is
hermes memory off     # Externe provider uitschakelen

Of handmatig in ~/.hermes/config.yaml:

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

Provider Vergelijking

Gedetailleerde Uitsplitsing

Honcho

Best voor: multi-agent systemen, cross-sessie context, gebruikers-agent uitlijning.

Honcho draait naast bestaand geheugen — USER.md blijft zoals het is, en Honcho voegt een extra laag context toe. Het modelleert gesprekken als peers die berichten uitwisselen — één gebruikers-peer plus één AI-peer per Hermes-profiel, allemaal delen van een workspace.

Tools: honcho_profile (lezen/bijwerken peer-kaart), honcho_search (semantisch zoeken), honcho_context (sessiecontext — samenvatting, representatie, kaart, berichten), honcho_reasoning (LLM-gesynthetiseerd), honcho_conclude (maken/verwijderen conclusies).

Belangrijkste config-knoppen:

• contextCadence (standaard 1): Minimale beurten tussen basislaag-verversing
• dialecticCadence (standaard 2): Minimale beurten tussen peer.chat() LLM-aanroepen (1-5 aanbevolen)
• dialecticDepth (standaard 1): .chat() passages per invocatie (clamped 1-3)
• recallMode (standaard ‘hybrid’): hybrid (auto+tools), context (alleen injecteren), tools (alleen tools)
• writeFrequency (standaard ‘async’): Flush-timing: async, turn, session, of integer N
• observationMode (standaard ‘directional’): directional (alle aan) of unified (gedeelde pool)

Architectuur: Tweelaagse contextinjectie — basislaag (sessiesamenvatting + representatie + peer-kaart) + dialectisch supplement (LLM-redenering). Selecteert automatisch cold-start vs warm prompts.

Multi-peer mapping: Workspace is een gedeelde omgeving over profielen. Gebruikers-peer (peerName) is een globale menselijke identiteit. AI-peer (aiPeer) is één per Hermes-profiel (hermes standaard, hermes.<profiel> voor anderen).

Setup:

hermes memory setup  # selecteer "honcho"
# of legacy: hermes honcho setup

Config: $HERMES_HOME/honcho.json (profiel-lokaal) of ~/.honcho/config.json (globaal).

Profielbeheer:

hermes profile create coder --clone  # Maakt hermes.coder met gedeelde workspace
hermes honcho sync                   # Vult AI-peers terug voor bestaande profielen

OpenViking

Best voor: zelfgehoste kennismanagement met gestructureerd browsen.

OpenViking biedt een bestandssysteemhiërarchie met gelaagde laden. Het is gratis, zelfgehost, en geeft je volledige controle over je geheugenopslag.

Tools: viking_search, viking_read (gelaagd), viking_browse, viking_remember, viking_add_resource.

Setup:

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

Mem0

Best voor: hands-off geheugenbeheer met auto-extractie.

Mem0 behandelt geheugenextractie server-side. Je configureert niets — het werkt gewoon. Afweging: cloud-afhankelijkheid en kosten.

Tools: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # selecteer "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

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

Hindsight

Best voor: knowledge-graph-gebaseerde recall met entity-relaties.

Hindsight bouwt een kennisgrafiek van je geheugen, met extractie van entities en relaties. Zijn unieke reflect-tool voert cross-geheugensamenstelling uit — het combineren van meerdere herinneringen tot nieuwe inzichten.

Tools: hindsight_retain, hindsight_recall, hindsight_reflect (unieke cross-geheugensamenstelling).

Setup:

hermes memory setup  # selecteer "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Installeert automatisch hindsight-client (cloud) of hindsight-all (lokaal). Vereist >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud of local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (standaard)

Lokale UI: hindsight-embed -p hermes ui start

Holographic

Best voor: privacy-gerichte setups met alleen lokale opslag.

Holographic gebruikt HRR (Holographic Reduced Representation) algebra voor geheugenencodering, met vertrouwensscore voor geheugenbetrouwbaarheid. Geen cloud-afhankelijkheid — alles draait lokaal op je eigen hardware.

Tools: 2 tools voor geheugenoperaties via HRR-algebra.

Setup:

hermes memory setup  # selecteer "holographic"

Geen afhankelijkheden. Alles draait lokaal.

RetainDB

Best voor: hoge frequentie updates met delta-compressie.

RetainDB gebruikt delta-compressie om geheugenupdates efficiënt op te slaan. Het is cloud-gebaseerd met een kosten van $20/maand, maar de compressie betekent minder datatransfer en snellere updates.

Tools: retaindb_profile (gebruikersprofiel), retaindb_search (semantisch zoeken), retaindb_context (taakrelevante context), retaindb_remember (opslaan met type + belangrijkheid), retaindb_forget (verwijderen herinneringen).

Setup:

hermes memory setup  # selecteer "retaindb"

ByteRover

Best voor: bandbreedte-beperkte omgevingen met pre-compressie extractie.

ByteRover comprimeert geheugen voordat extractie, waardoor bandbreedtegebruik wordt verlaagd. Beschikbaar in lokale of cloud-modi.

Tools: 3 tools voor geheugenoperaties.

Setup:

hermes memory setup  # selecteer "byterover"

Supermemory

Best voor: enterprise-workflows met context-fencing en sessiegrafiek-inname.

Supermemory biedt context-fencing (isolatie van geheugen per context) en sessiegrafiek-inname (importeren van volledige gespreksgeschiedenissen). Het is cloud-gebaseerd en betaald, maar ontworpen voor enterprise-schaal geheugenbeheer.

Tools: 4 tools voor geheugenoperaties.

Setup:

hermes memory setup  # selecteer "supermemory"

Hoe te Kiezen

• Heb je multi-agent ondersteuning nodig? Honcho
• Wil je zelfgehost en gratis? OpenViking of Holographic
• Wil je zero-config? Mem0
• Wil je kennisgrafieken? Hindsight
• Wil je delta-compressie? RetainDB
• Wil je bandbreedte-efficiëntie? ByteRover
• Wil je enterprise-functies? Supermemory
• Wil je privacy (alleen lokaal)? Holographic

Voor volledige profiel-per-profiel provider-configuraties en real-world workflow-patronen, zie Hermes Agent production setup.

Deel 7: De Filosofie

Waarom Begrensd Geheugen Beter is dan Onbeperkt Geheugen

De instinctieve neiging is om geheugen zo groot mogelijk te maken. Sla alles op. Haal op wat je nodig hebt.

Begrensd geheugen werkt beter. Hier is waarom.

Curatie forceert kwaliteit. Wanneer je beperkte ruimte hebt, sla je alleen op wat belangrijk is. Je comprimeert, consolideert en prioriteert. Onbeperkt geheugen moedigt aan om alles erin te dumpen en nooit op te ruimen.

Snelheid telt. 1.300 tokens in de system prompt is snel. 100.000 tokens opgehaald uit een database is langzaam. Geheugen moet direct zijn, geen query.

Ruis vermindert prestaties. Meer geheugen is niet beter geheugen. Het is ruisiger geheugen. Het model moet onderscheid maken tussen signaal en ruis, en dat kost attention — attention die besteed zou moeten worden aan de daadwerkelijke taak.

Vergeten is een functie. Menselijk geheugen vergiet. Dat is geen bug — het is hoe we prioriteren. Agents moeten ook vergeten. Niet alles verdient om onthouden te worden.

Het “Vergeten” Probleem

Agents moeten onthouden. Niet alleen vergeten, maar actief verouderde informatie verwijderen.

Zo behandelt Hermes Agent dit:

• remove-actie: Verwijder items die niet langer relevant zijn.
• replace-actie: Update items met nieuwe informatie.
• Capaciteitsdruk: Wanneer het geheugen vol is, consolideert de agent en verwijdert oude items.
• Beveiligingsscan: Blokkeert kwaadaardige of gecorrumpeerde items.

Vergeten is geen falen — het is onderhoud. Een agent dat niet kan onthouden, zal uiteindelijk evenveel ruis als signaal dragen.

Memory Scaling

Databricks introduceerde het concept van “memory scaling”: presteert een agent met duizenden gebruikers beter dan één met een enkele gebruiker?

Hun onderzoek suggereert van wel, maar met nuances. Memory scaling vereist:

1. Kwaliteitsextractie: Niet alle interacties zijn het waard om te onthouden. De agent moet inzichten extraheren, geen logs.
2. Effectieve retrieval: Opgehaalde herinneringen moeten relevant zijn. Ruis vermindert prestaties.
3. Generalisatie: Herinneringen moeten patronen zijn, geen specificiteiten. “Gebruiker geeft de voorkeur aan Python” schaalt. “Gebruiker voerde commando X uit op tijdstip Y” doet dat niet.

Het begrensde geheugen van Hermes Agent ondersteunt natuurlijk memory scaling. Door curatie te forceren, zorgt het ervoor dat herinneringen generaliseerbaar, compact en nuttig zijn.

Wat Dit Betekent voor de Toekomst

Geheugen wordt de concurrentievoordeel in agentic AI — niet het model zelf, maar wat het model meeneemt tussen sessies in. Twee agents met identieke onderliggende modellen kunnen zeer verschillend presteren: de één onthoudt je voorkeuren, je omgeving en je vorige fouten; de ander start elke keer koud.

De vraag is niet langer of agents persistent geheugen moeten hebben. Dat is beslist: ze moeten. De open vraag is hoe dat geheugen goed te ontwerpen — wat te behouden, wat te verwerpen, hoe het direct te maken, en hoe te voorkomen dat het ruis wordt.

Het antwoord van Hermes Agent is om geheugen klein, gecureerd en altijd actief te houden — geen database die je queryt, maar een werkmodel van de gebruiker dat de agent meeneemt in elk gesprek.

Conclusie

Het geheugensysteem van Hermes Agent is bewust simpel: twee bestanden, strikte karakterlimieten, geen retrieval-pijplijn, geen vector database, en geen per-query latentie. Wat klinkt als een beperking, is het hele punt.

Het werkt omdat het geheugen behandelt op de manier waarop een brein werkt in plaats van de manier waarop een database doet — klein, gecureerd en altijd actief. De agent haalt geheugen niet op wanneer het het nodig heeft; het geheugen is er simpelweg altijd, geweven in de system prompt vanaf de eerste token van elke sessie.

Externe geheugenproviders breiden dit systeem uit voor gebruikers die meer nodig hebben: kennisgrafieken, multi-agent ondersteuning, zelfgehoste opslag, enterprise-functies. Maar de kern blijft hetzelfde: begrensd, gecureerd, altijd beschikbaar.

En externe kennisbases — LLM Wiki, Obsidian, Notion, ArXiv — dienen een andere rol. Ze zijn de bibliotheek, niet het brein. De agent zoekt ze op, herinnert ze niet. Cruciale inzichten worden gedistilleerd naar intern geheugen; de rest blijft in de bibliotheek.

Zo onthoudt een AI-agent jou. Niet door alles op te slaan, maar door te onthouden wat ertoe doet.

Hermes Agent werd in februari 2026 uitgebracht door Nous Research en bereikte meer dan 64.000 GitHub-sterren in april 2026 (v0.9.0), met 242+ bijdragers. Het is open-source en beschikbaar op github.com/NousResearch/hermes-agent. Voor installatie, configuratie en workflow-gidsen, zie het Hermes Agent overzicht.