Het Hermes Agent Memory-systeem: hoe persistente AI-geheugen werkt

U kent het patroon. U opent een chat met een AI-agent, legt uw project uit, deelt uw voorkeuren, laat werk uitvoeren en sluit de tabblad. Als u de volgende week terugkomt, voelt het alsof u tegen een vreemde praat: alle context is verdwenen, elke voorkeur vergeten en het project moet opnieuw van begin af aan worden uitgelegd.

Dit is geen bug. Dit is hoe Large Language Models (LLM’s) per ontwerp werken. Ze zijn stateless: elk verzoek is onafhankelijk, elk antwoord wordt gegenereerd op basis van de prompt die u op dat moment verzendt, zonder geheugen, zonder geschiedenis en zonder continuïteit buiten de tokens in de huidige contextvenster.

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

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

De meeste van deze benaderingen 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 helderheid.

Hermes Agent kiest een fundamenteel andere aanpak. Geheugen is iets wat de agent niet ophaalt wanneer het nodig is. Het is iets wat de agent altijd is — 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 — de Hermes-specifieke laag binnen het cross-framework model in Geheugensystemen in AI-Assistants en de bredere stack in AI-Assistent Architectuur. Voor activatie- en inspectiecommando’s (hermes memory, hermes dump, log tailing), combineer het met de Hermes Agent CLI cheat sheet. Voor het complementaire aspect van Hermes “langetermijnkennis” — herbruikbare procedures in SKILL.md in plaats van gecureerde geheugenbestanden — zie Hermes Agent Skill Authoring — SKILL.md Structuur en Best Practices.

Deel 1: Het AI-Agent Geheugenprobleem

Waarom “Voeg Simpelweg Context Toe” Niet Schaleert voor Agents

De voor de hand liggende oplossing voor stateless AI is het toevoegen van context. Voeg het vorige gesprek toe. Sluit de projectdocumentatie in. Stuur de volledige geschiedenis.

Voor een tijdje werkt dat. Je hebt een contextvenster van 128K. Je kunt veel tekst daarin kwijt.

Maar context is geen geheugen — er is een echt en belangrijk verschil tussen hen. Context is alles wat je nu te zien krijgt; geheugen is wat je actief bewaart en mee naar voren draagt.

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

Geheugen is gecureerd. Het is de distillatie van ervaring tot iets compacts en actieerbaars. Het groeit niet oneindig — 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, wat hen belangrijk vinden, wat je hebt afgesproken, wat je hebt geleerd. De rest is ofwel vergeten of zoekbaar wanneer je het nodig hebt.

Het Onderzoekslandschap

De ruimte voor AI-agent geheugen is geëxplodeerd sinds 2024, met dedicated benchmark suites, een groeiende onderzoeksliteratuur en een meetbaar prestatieverschil tussen verschillende architectuurbenaderingen. Hier is waar de zaken staan.

Letta (voorheen MemGPT) was een van de eerste frameworks die persistent geheugen als een eerste klas bezorgdheid behandelde, met 21.7K GitHub stars. Het gebruikt een OS-geïnspireerd driedelig model: core geheugen (klein, altijd in context), recall geheugen (zoekbare gespreksgeschiedenis) en archiefgeheugen (langetermijn koude opslag). Het inzicht dat niet alle geheugen gelijk is, was correct. De implementatie vereist echter dat agents volledig binnen de Letta runtime draaien — adoptie betekent het adopteren van het hele platform, niet slechts een geheugenlaag.

Zep / Graphiti richt zich op conversatiegeheugen met temporele entity tracking — feiten hebben validiteitsvensters 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 volgen.

Cognee is gebouwd voor knowledge extraction uit documenten en gestructureerde data, met 30+ ingestion connectors en een knowledge graph backend. Het excelleert in institutionele kennis en RAG-pijplijnen, maar is minder gericht op persoonlijk agentgeheugen. Zie self-hosting Cognee met lokale LLM’s voor een praktische setupgids.

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

Mem0 behandelt memory extraction server-side via LLM-analyse, wat minimale configuratie vereist. Het Mem0-onderzoeksartikel, gepubliceerd op ECAI 2025 (arXiv:2504.19413), benchmarkte tien verschillende benaderingen tot AI-geheugen en valideerde de selectieve extractieaanpak — het opslaan van discrete feiten, deduplicatie en alleen het ophalen wat relevant is. Mem0 is gegroeid tot ongeveer 48K GitHub stars en ondersteunt 21 framework-integraties. De afweging is cloud-afhankelijkheid en kosten.

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

De rode draad door de meeste frameworks heen 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 vraag opgehaald, het wordt bij sessiestart geïnjecteerd en is altijd aanwezig. Altijd actief, altijd beschikbaar, gecureerd genoeg om nuttig te blijven.

Deel 2: Architectuur

Lees dit deel van boven naar beneden — lagen en per-turn recall/store eerst, dan wat er in MEMORY.md en USER.md staat, dan hoe je een externe provider koppelt.

Twee lagen

Hermes stapelt geheugen in twee lagen:

1. Ingebouwd — MEMORY.md en USER.md, bestand-gebaseerd, altijd actief. Harde limieten van 2.200 karakters (agent notities) en 1.375 karakters (gebruikersprofiel).
2. Eén externe provider (optioneel) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory en peers die je via config inschakelt. Slechts één externe backend draait tegelijk. Het voegt retrieval en retentie toe naast de bestanden; het vervangt ze niet.

Het mentale model is additief — bevroren core-bestanden plus maximaal één plugin. Prefetch en sync hooks orkestreren de externe laag; de twee bestanden blijven apart geïnjecteerd als onderdeel van de bevroren system prompt.

Runtime flow (prefetch en sync)

Recall gebeurt voordat het model antwoordt; persistentie gebeurt na het assistentbericht. In de geheugenmanager van Hermes Agent komt dit overeen met prefetch bij binnenkomst en sync bij uitgang. Namen hieronder komen overeen met de implementatieoppervlakte (MemoryManager, per-provider prefetch / sync_turn / queue_prefetch).

Gebruikersbericht
    |
    v
MemoryManager.prefetch_all(query)        <-- recall fase
    |
    +-- provider.prefetch(query)        <-- elke externe provider zoekt in zijn store
    |
    v
Context geïnjecteerd in LLM turn
    |
    v
LLM reageert (assistentbericht)
    |
    v
MemoryManager.sync_all(gebruiker, assistent)  <-- store fase
    |
    +-- provider.sync_turn(gebruiker, assistent)
    +-- provider.queue_prefetch(gebruiker)    <-- achtergrondzoeken naar de volgende turn

Ingebouwde MEMORY.md en USER.md worden niet opgehaald via prefetch_all — ze zijn al onderdeel van de bevroren system prompt. Externe backends sluiten aan op prefetch_all / sync_all; queue_prefetch laat een provider retrieval verwarmen voor de volgende turn zonder het huidige antwoord te blokkeren.

Drie paden naar langetermijngeheugen

1. Ingebouwde memory tool. Het model roept memory aan met add, replace of remove wanneer instructies zeggen dat iets persistent moet zijn — duurzame feiten, voorkeuren, correcties, omgevingsnotities. target='user' onderhoudt USER.md; target='memory' onderhoudt MEMORY.md. Voorbeeldvorm: memory(action='add', target='user', content='…').

2. Passieve retentie op externe providers. Elke turn roept het framework het sync-pad van de provider aan zodat conversatie kan worden chunked, samengevat of geëxtraheerd zonder dat het model elk feit noemt. Gedrag verschilt per backend — bijvoorbeeld Hindsight batcht turns en voert gestructureerde retentie uit met entiteiten en relaties; Honcho stuurt dialoog door zijn dialectische pijplijn; Mem0- en Supermemory-stacks extraheren feiten passief uit turns.

3. Provider-specifieke tools. Wanneer de plugin ze blootlegt, slaan expliciete writes zoals honcho_conclude, hindsight_retain of honcho_profile duurzame slices op bij vraag.

Automatisch recall versus provider tools

Core geheugen heeft geen leestool nodig — het is al in de prompt. Externe backends voegen ofwel automatische injectie van prefetch toe (geen apart recall tool-uitroep voor dat stukje context) of expliciete retrieval tools (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect en peers) wanneer het model een scherpere query nodig heeft dan alleen prefetch.

Recall modi (externe providers)

Plugins ondersteunen een configureerbare recall mode (doorgaans recall_mode naast memory.provider in config) die tokens ruilt voor controle.

Wanneer geen externe provider is ingesteld (memory.provider leeg of niet ingesteld), gelden alleen de ingebouwde bestanden en sessiezoektocht — geen prefetch/sync van een plugin.

Padnen op disk en budgets

Het ingebouwde geheugen van Hermes Agent bevindt zich in twee bestanden.

• ~/.hermes/memories/MEMY.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 totaal, minder dan 1.300 tokens. Het ziet er bewust klein uit omdat het dat 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. Zo ziet het eruit:

Gebruikersproject is een Go microservice op ~/code/gateway met gRPC + PostgreSQL
Deze machine draait Ubuntu 22.04, heeft Docker en kubectl geïnstalleerd
Gebruiker verkent snake_case voor variablenamen en vermijdt camelCase

Dit zijn geen logs. Het zijn feiten. Dicht, declaratief, informatie-rijk. Geen tijdstempels, geen fluff, 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 comfortabel met TypeScript, Go en Python.
Gebruiker verkent snake_case voor variablenamen en vermijdt camelCase.
Gebruiker gebruikt voornamelijk Linux Ubuntu 22.04.
Gebruiker deployt naar AWS met Terraform.

Identiteit, rol, voorkeuren, technische vaardigheden, communicatiestijl, irritaties. Het stuff dat de agent anders laat reageren op jou dan op iedereen else.

Het Frozen Snapshot Patroon

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

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

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

Het formaat gebruikt headers, gebruikspercentages, karakteraantallen en § (sectiekenmerk) delimiters. Items kunnen meerdere regels bevatten. Het is ontworpen om parsebaar te zijn door het model terwijl het mens-leesbaar blijft.

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

Veranderingen gemaakt tijdens een sessie worden direct op disk gepersisteerd, maar ze verschijnen pas in de system prompt bij de volgende sessiestart. Tool-antwoorden tonen altijd de live staat, maar het “brein” van het model verandert niet midden in een sessie. Dit voorkomt dat het model in zijn eigen staart rent — geheugen updaten en dan reageren op zijn eigen update in hetzelfde gesprek.

Karakterlimieten als een Feature

2.200 karakters. 1.375 karakters. Dit zijn geen willekeurige limieten. Het zijn ontwerpbeperkingen 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 forceert de agent om selectief te zijn. Wat is echt belangrijk? Wat zal ik opnieuw nodig hebben? Wat kan worden gecomprimeerd zonder betekenis te verliezen?

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

1. Lees huidige items uit foutreactie
2. Identificeer verwijderbare of te consolideren items
3. Gebruik replace om gerelateerde items te samenvoegen tot kortere versies
4. Voeg het nieuwe item toe

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

Beveiliging: Prompt Injectie Scanning

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

Geheugen wordt ook gedupliceerd. Exacte duplicaten worden automatisch afgewezen. Dit voorkomt dat tegenstanders proberen om maliciuze content te injecteren via herhaalde inzendingen.

Externe geheugenproviders (activatie en links)

Naast ingebouwd MEMORY.md en USER.md kan Hermes Agent één externe geheugenplugin koppelen op een tijd — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover of Supermemory — voor persistente, cross-sessie kennis. Slechts één externe provider is actief op een tijd; de twee core-bestanden blijven geladen naast het (additief, niet vervanging).

Activeer en inspecteer providers met hermes memory setup, hermes memory status en hermes memory off, of stel memory.provider en recall_mode in ~/.hermes/config.yaml in. Credential patronen variëren (bijvoorbeeld HINDSIGHT_API_KEY, Honcho keys onder $HERMES_HOME/honcho.json); gebruik hermes memory setup voor interactieve wiring.

Minimale ingebouwde-only YAML vorm:

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

Voorbeeld activatie voor één backend (vervang hindsight door honcho, mem0, supermemory of anderen die je installatie ondersteunt):

memory:
  provider: "hindsight"

Voor de volledige vergelijkingstabel, LLM en embedding afhankelijkheid notities, per-provider breakdowns en hoe deze backends relateren tot OpenClaw en andere stacks, zie Agent geheugenproviders vergeleken.

Voor profiel-specifieke wiring en productieworkflows, zie Hermes Agent productiesetup. De AI Systemen Geheugen hub lijst deze gids plus gerelateerde Cognee en knowledge-layer artikelen.

Deel 3: Wanneer Geheugen Aangaat — Triggers & Beslissingen

De meest voorkomende vraag over Hermes Agent’s geheugen 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. Hier 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 geheugen te updaten.

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' pakketmanager voor alle Python-projecten.

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

Voorbeeld: nadat het je meerdere keren poetry heeft zien gebruiken in verschillende projecten, slaat het het op als voorkeur.

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

Voorbeeld: de agent controleert wat er is geïnstalleerd 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: Gebruikersproject is een Go microservice op ~/code/gateway met 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 skill of ten minste 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 gemakkelijk opnieuw kunnen worden ontdekt
• Raw data dumps
• Sessie-specifieke ephemera
• Informatie al in contextbestanden (SOUL.md, AGENTS.md)

Leestiggers: Wanneer Herinnert de Agent Zich?

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

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

session_search (op vraag). Wanneer de agent iets nodig heeft uit vorige gesprekken dat niet in het core geheugen staat, gebruikt het de session_search tool. Dit queryt SQLite (~/.hermes/state.db) met FTS5 full-text search en Gemini Flash samenvatting. Gebruik dit wanneer de vraag klinkt als “hebben we dit eerder besproken” in plaats van “onthoud dit feit voor altijd.”

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

Externe provider tools (wanneer geconfigureerd). Wanneer een externe geheugenprovider actief is, voert het framework ook een automatische prefetch stap uit voordat elk antwoord (zie Deel 2). Aanvullende tools zoals honcho_search, hindsight_recall of mem0_search zijn voor gerichte lookups wanneer de agent expliciete retrieval kiest — afhankelijk van recall_mode, automatische injectie, tools of beide kunnen actief zijn.

Het Beslisboom

Hier is hoe de agent weegt “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 gemakkelijk opnieuw te ontdekken?
        JA → Sla over
        NEE → Is dit sessie-specifiek?
          JA → Sla over
          NEE → Sla op in geheugen

De agent overdenkt dit niet. Het slaat proactief op, consolideert wanneer vol, en vertrouwt de karakterlimieten om dingen strak te houden.

Deel 4: Intern Geheugen vs. Externe Kennisbases

Hier ontstaat vaak verwarring. 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 lijkt op het onderscheid tussen retrieval-augmented generation pijplijnen en agent werkgeheugen — externe retrieval is goed voor diepe kennislookups, 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 — uitgebreide referentiebronnen die op vraag worden geraadpleegd.

Het Onderscheid

Intern Geheugen (het brein):

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

Externe Kennisbases (de bibliotheek):

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

Hoe Ze Relateren

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

LLM Wiki (llm-wiki): Karpathy’s interlinked Markdown kennisbase voor het bouwen en queryen van domeinkennis. De agent gebruikt de llm-wiki skill om te lezen, te zoeken en te queryen. Het is een referentiebron, geen geheugen.

Obsidian: Persoonlijke notitie vaults met bidirectionele links. De agent gebruikt de obsidian skill om te lezen, te zoeken en notities te maken. Obsidian is onderdeel van het bredere persoonlijke kennismanagement ecosysteem dat Hermes kan benutten als bibliotheekbron.

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

ArXiv: Academische paper repositories. De agent zoekt en extrahert 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 geheugenscalering voor AI-agents. Het slaat niet het hele paper op in geheugen. Het slaat de kernboodschap op: Geheugenscalering: agentprestaties verbeteren met opgebouwde ervaring door gebruikersinteractie en bedrijfscontext opgeslagen in geheugen.

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

Wanneer Welke Gebruiken

Intern geheugen voor:

• “Wie help ik?”
• “Wat geven ze de voorkeur?”
• “Wat hebben we net 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 codestructuur?”

De agent begrijpt het verschil en gebruikt elk op zijn plaats — het mengt het opzoeken van een document niet met het onthouden van iets wat het over jou en je omgeving heeft geleerd.

Deel 5: Hoe Het Echt Werkt

Laten we de mechanica bekijken.

De memory Tool

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

Er is geen read actie — geheugencontent wordt automatisch geïnjecteerd in de system prompt. De agent hoeft het niet te lezen omdat het altijd daar 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 hebben. Dit maakt chirurgische edits mogelijk zonder de exacte content te kennen.

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

Target Stores: 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, workflowgewoontes.

Capaciteitsbeheer

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

Goede geheugenitems zijn compact en informatie-rijk:

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 verbose:

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 het gebruikt Go met gRPC en PostgreSQL voor de databaselayer.

De eerste is dicht en nuttig. De tweede is ofwel te vaag of te verbose.

Sessiezoektocht vs Persistent Geheugen

session_search en persistent geheugen dienen verschillende doeleinden.

Vuistregel: gebruik geheugen voor cruciale feiten die altijd in context moeten zijn. Gebruik sessiezoektocht voor historische lookups.

Deel 6: 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 ertoe doet. 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 traag. Geheugen moet direct zijn, geen query.

Ruis verlaagt prestaties. Meer geheugen is niet beter geheugen. Het is ruisiger geheugen. Het model moet signaal onderscheiden van ruis, en dat kost aandacht — aandacht die besteed zou moeten worden aan de daadwerkelijke taak.

Vergeten is een feature. Menselijk geheugen vergeten. 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 onleren. Niet alleen vergeten, maar actief verouderde informatie verwijderen.

Hier is hoe Hermes Agent het aanpakt:

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

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

Geheugenscalering

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

Hun onderzoek suggereert van wel, maar met kanttekeningen. Geheugenscalering 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 verlaagt prestaties.
3. Generalisatie: Herinneringen moeten patronen zijn, geen specifics. “Gebruiker geeft de voorkeur aan Python” schaalt. “Gebruiker voerde commando X uit op tijdstip Y” niet.

Hermes Agent’s begrensd geheugen ondersteunt geheugenscalering natuurlijk. Door curatie te forceren, zorgt het ervoor dat herinneringen generaliseerbaar, compact en nuttig zijn.

Wat Dit Betekent voor de Toekomst

Geheugen wordt de competitieve greppel in agentic AI — niet het model zelf, maar wat het model meeneemt tussen sessies. Twee agents met identieke onderliggende modellen kunnen zeer verschillend presteren: één onthoudt je voorkeuren, je omgeving en je vorige fouten; de andere begint 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.

Hermes Agent’s antwoord 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, harde 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 zoals een brein werkt in plaats van hoe een database doet — klein, gecureerd en altijd actief. De agent haalt geheugen niet op wanneer het het nodig heeft; het geheugen is simpelweg altijd daar, geweven in de system prompt vanaf het eerste token van elke sessie.

Externe geheugenproviders breiden dit systeem uit voor gebruikers die meer nodig hebben: knowledge graphs, multi-agent ondersteuning, self-hosted opslag, enterprise features. Maar de core 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, onthoudt 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 uitgebracht door Nous Research in februari 2026 en bereikte meer dan 64.000 GitHub stars 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 workflowgidsen, zie de Hermes Agent overzicht.