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

Je kent het ritueel wel. Je opent een chat met een AI-agent, legt je project uit, deelt je voorkeuren, krijgt wat werk gedaan en sluit het tabblad. Je komt de volgende week terug en het is alsof je met een vreemde praat — alle context is weg, elke voorkeur is vergeten, het project moet vanaf nul opnieuw worden uitgelegd.

Dit is geen bug. Dit is hoe Large Language Models ontworpen zijn. Ze zijn stateless: elke aanvraag is onafhankelijk, elk antwoord wordt gegenereerd op basis van de prompt die je op dit moment stuurt, zonder geheugen, zonder geschiedenis en zonder continuïteit buiten de tokens in het huidige contextvenster.

Voor interacties met een enkele beurt is dat prima. Stel een vraag, krijg een antwoord, ga verder. Maar voor agents — systemen die bedoeld zijn om dingen te doen over verschillende sessies heen, te leren van fouten en met je mee te evolueren — is statelessness een harde architecturale beperking. Het is een van de centrale onopgeloste problemen in self-hosted AI systems.

De industrie heeft geprobeerd dit op te lossen. LangChain voegde geheugenmodules toe. OpenAI introduceerde assistants 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 een agent verbeteren met geaccumuleerde ervaring. Specifieke benchmark-papers, enquêtes over episodisch geheugen en een snel groeiend ecosysteem van tools zijn sinds 2024 allemaal ontstaan om aan te pakken wat steeds vaker wordt herkend als een van de centrale onopgeloste problemen in agentic AI.

De meeste van deze benaderingen delen een gemeenschappelijk probleem: ze behandelen geheugen als een bijzaak — een database die je bevraagt, een contextvenster dat je volstopt, een ophaalsysteem dat latentie en ruis toevoegt in plaats van duidelijkheid.

Hermes Agent hanteert een fundamenteel andere aanpak. Geheugen is niet iets wat de agent ophalt wanneer dat nodig is. Het is iets wat de agent is op elk gegeven moment — 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 het moet vergeten.

Dit artikel legt precies uit hoe dat werkt.

Deel 1: Het AI Agent Geheugenprobleem

Waarom “gewoon context toevoegen” niet schaalt voor agents

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

Een tijdje werkt dat. Je hebt een contextvenster van 128K. Je kunt veel tekst in dat venster kwijt.

Maar context is geen geheugen — er is een echt en belangrijk verschil tussen die twee. Context is alles wat je op dit moment te zien krijgt; geheugen is wat je actief bijhoudt en meeneemt.

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

Geheugen is gecureerd. Het is de distillatie van ervaring tot iets compacts en bruikbaars. Het groeit niet oneindig — het consolideert, werkt bij en vergeet.

Het menselijk geheugen werkt op dezelfde manier. Je herinnert je niet elk gesprek dat je ooit hebt gevoerd. Je herinnert je de onderdelen die ertoe doen: met wie je praat, waar diegene om geeft, wat jullie hebben afgesproken, wat je hebt geleerd. De rest wordt ofwel vergeten, ofwel is doorzoekbaar wanneer je het nodig hebt.

Het onderzoekslandschap

De ruimte rondom AI agent geheugen is sinds 2024 geëxplodeerd, met specifieke benchmark-suites, een groeiende hoeveelheid onderzoek en een meetbaar prestatieverschil tussen verschillende architecturale benaderingen. Dit is de huidige stand van zaken.

Letta (voorheen MemGPT) was een van de eerste frameworks die persistent geheugen behandelde als een primaire aangelegenheid, met 21,7K GitHub-stars. Het gebruikt een door een OS geïnspireerd drie-lagenmodel: core memory (klein, altijd in de context), recall memory (doorzoekbare gesprekshistorie) en archival memory (langetermijn cold storage). Het inzicht dat niet alle geheugen gelijk is, was correct. De implementatie vereist echter dat agents volledig binnen de Letta-runtime draaien — het adopteren ervan betekent het adopteren van het hele platform, niet alleen een geheugenlaag.

Zep / Graphiti richt zich op conversationeel geheugen met temporele entiteitsregistratie — feiten hebben geldigheidsintervallen zodat de graaf weet wanneer iets waar was. Het is sterk voor chatbots die relatiegrafen nodig hebben, maar minder geschikt voor autonome agents die omgevingsfeiten en projectconventies bijhouden.

Cognee is gebouwd voor kennisextractie uit documenten en gestructureerde data, met meer dan 30 ingestie-connectoren en een kennisgraaf-backend. Het blinkt uit in institutionele kennis en RAG pipelines, maar is minder gericht op persoonlijk agentgeheugen. Zie self-hosting Cognee with local LLMs voor een praktische installatiegids.

Hindsight doet kennisgraaf-gebaseerde recall met entiteitsrelaties en een unieke reflect-synthesetool die synthese over verschillende geheugens uitvoert — het combineren van meerdere herinneringen tot nieuwe inzichten. Het behoort tot de top performers op benchmarks voor agentgeheugen en is beschikbaar als geheugenprovider voor Hermes Agent.

Mem0 handelt geheugenextractie af aan de serverzijde via LLM-analyse, waarbij minimale configuratie nodig is. Het Mem0-onderzoeksrapport, gepubliceerd op ECAI 2025 (arXiv:2504.19413), benchmarkte tien verschillende benaderingen van AI-geheugen en valideerde de selectieve extractiemethode — het opslaan van discrete feiten, het verwijderen van duplicaten en het alleen ophalen van wat relevant is. Mem0 is gegroeid naar ongeveer 48K GitHub-stars en ondersteunt 21 framework-integraties. Het nadeel is de afhankelijkheid van de cloud en de kosten.

Het geheugenschaalbaarheidsonderzoek van Databricks introduceerde het concept dat de prestaties van een agent verbeteren met geaccumuleerde ervaring. Hun architectuur bevat system prompts, bedrijfsactiva en episodische/semantische geheugens die zijn afgestemd op organisatie- en gebruikersniveau, wat het idee bevestigt dat geheugenkwaliteit net zo belangrijk is als modelcapaciteit.

De rode draad bij de meeste frameworks is dat ze geheugen behandelen als een ophaalprobleem: sla het ergens op, vraag het op wanneer nodig, injecteer het in de context. Hermes doet het tegenovergestelde — geheugen wordt niet op aanvraag opgehaald, het wordt aan het begin van de sessie geïnjecteerd en is altijd aanwezig. Altijd actief, altijd beschikbaar, voldoende gecureerd om nuttig te blijven.

Deel 2: Architectuur

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

Twee lagen

Hermes stapelt geheugen in twee lagen:

1. Ingebouwd — MEMORY.md en USER.md, bestand-ondersteund, altijd actief. Harde limieten van 2.200 tekens (agent-notities) en 1.375 tekens (gebruikersprofiel).
2. Eén externe provider (optioneel) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, en gelijken die je via de configuratie inschakelt. Slechts één externe backend draait tegelijkertijd. Deze voegt ophaal- en retentiefunctionaliteit toe naast de bestanden; het vervangt ze niet.

Het mentale model is additief — bevroren kernbestanden plus maximaal één plugin. Prefetch- en sync-hooks orkestreren de externe laag; de twee bestanden worden 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 bericht van de assistent. In de memory manager van Hermes Agent vertaalt dit zich naar prefetch bij de ingang en sync bij de uitgang. De onderstaande namen komen overeen met de implementatie (MemoryManager, per-provider prefetch / sync_turn / queue_prefetch).

User message
    |
    v
MemoryManager.prefetch_all(query)        <-- recall fase
    |
    +-- provider.prefetch(query)        <-- elke externe provider doorzoekt zijn opslag
    |
    v
Context geïnjecteerd in LLM turn
    |
    v
LLM reageert (assistant message)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- store fase
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- achtergrondzoekopdracht voor de volgende turn

Ingebouwde MEMORY.md en USER.md worden niet opgehaald via prefetch_all — ze maken al deel uit van de bevroren system prompt. Externe backends pluggen in op prefetch_all / sync_all; queue_prefetch laat een provider de ophaalfunctie alvast voorbereiden 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 aangeven dat iets moet blijven bestaan — 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. Bij elke turn roept het framework het sync-pad van de provider aan, zodat gesprekken in brokken kunnen worden verdeeld, samengevat of geëxtraheerd kunnen worden zonder dat het model elk feit expliciet moet benoemen. Het gedrag verschilt per backend — bijvoorbeeld batcht Hindsight turns en voert gestructureerde retentie uit met entiteiten en relaties; Honcho stuurt dialoog door zijn dialectische pipeline; stacks in de stijl van Mem0 en Supermemory extraheren feiten passief uit turns.

3. Providerspecifieke tools. Wanneer de plugin ze blootstelt, kunnen expliciete schrijfacties zoals honcho_conclude, hindsight_retain, of honcho_profile op aanvraag duurzame fragmenten opslaan.

Automatische recall versus provider-tools

Kerngeheugen heeft geen lees-tool nodig — het zit al in de prompt. Externe backends voegen ofwel automatische injectie toe via prefetch (geen aparte recall-tool call voor dat deel van de context), ofwel expliciete ophaaltools (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect, en gelijken) wanneer het model een nauwkeuriger verzoek nodig heeft dan alleen prefetch.

Recall-modi (externe providers)

Plugins ondersteunen een configureerbare recall-modus (meestal recall_mode naast memory.provider in de configuratie) die tokens uitruilt voor controle.

Wanneer er geen externe provider is ingesteld (memory.provider leeg of niet ingesteld), zijn alleen de ingebouwde bestanden en sessie-zoekopdrachten van toepassing — geen prefetch/sync vanuit een plugin.

Paden op schijf en budgetten

Het ingebouwde geheugen van Hermes Agent leeft in twee bestanden.

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

Dat is het volledige persistente geheugenoppervlak: twee bestanden, in totaal minder dan 3.600 tekens, minder dan 1.300 tokens. Het ziet er bewust klein uit, want dat is het — en dat is precies de bedoeling van het ontwerp.

MEMORY.md: De notities van de agent

Dit is waar de agent alles opslaat wat hij leert over zijn omgeving, het project, tools, conventies en geleerde lessen. Zo ziet het eruit:

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

Dit zijn geen logs. Het zijn feiten. Compact, declaratief, vol informatie. Geen tijdstempels, geen onzin, geen “op 5 januari vroeg de gebruiker mij om…”.

USER.md: Het gebruikersprofiel

Dit is waar de agent alles opslaat wat hij over jou weet.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

Identiteit, rol, voorkeuren, technische vaardigheden, communicatiestijl, irritatiepunten. De zaken die ervoor zorgen dat de agent anders op jou reageert dan op iemand anders.

Het Frozen Snapshot Patroon

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

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

Het formaat gebruikt koppen, gebruikspersentages, tekenaantallen en § (sectieteken) als scheidingstekens. Inkomsten kunnen meerdere regels beslaan. Het is ontworpen om parseerbaar te zijn voor het model en tegelijkertijd leesbaar voor mensen.

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

Wijzigingen die tijdens een sessie worden aangebracht, worden direct naar de schijf geschreven, maar ze verschijnen pas bij de start van de volgende sessie in de system prompt. Tool-antwoorden tonen altijd de live-status, maar de “geest” van het model verandert niet midden in een sessie. Dit voorkomt dat het model zijn eigen staart achter zich aanjaagt — het geheugen bijwerken en vervolgens reageren op zijn eigen update in hetzelfde gesprek.

Tekenlimieten als feature

2.200 tekens. 1.375 tekens. Dit zijn geen willekeurige limieten. Het zijn ontwerpbeperkingen die curatie afdwingen.

Onbeperkt geheugen is een risico. 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 weer nodig? Wat kan worden gecomprimeerd zonder de betekenis te verliezen?

Wanneer het geheugen vol is, faalt de agent niet zomaar stilzwijgend. Hij krijgt een foutmelding met de huidige items en het verbruik, en volgt vervolgens een workflow:

1. Lees de huidige items uit de foutmelding
2. Identificeer items die verwijderd of geconsolideerd kunnen worden
3. Gebruik replace om gerelateerde items samen te voegen tot kortere versies
4. Voeg het nieuwe item toe

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

Beveiliging: Prompt Injection Scanning

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

Geheugen wordt ook gedubliceerd. Exacte duplicaten worden automatisch geweigerd. Dit voorkomt dat kwaadwillenden proberen kwaadaardige inhoud te injecteren via herhaalde inzendingen.

Externe geheugenproviders (activering en links)

Naast de ingebouwde MEMORY.md en USER.md kan Hermes Agent tegelijkertijd één externe geheugenplugin koppelen — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover of Supermemory — voor persistent, cross-sessie kennis. Slechts één externe provider is tegelijk actief; de twee kernbestanden blijven daarnaast geladen (additief, geen vervanging).

Activeer en inspecteer providers met hermes memory setup, hermes memory status, en hermes memory off, of stel memory.provider en recall_mode in via ~/.hermes/config.yaml. Patronen voor inloggegevens variëren (bijvoorbeeld HINDSIGHT_API_KEY, Honcho-sleutels onder $HERMES_HOME/honcho.json); gebruik hermes memory setup voor interactieve koppeling.

Minimale YAML-vorm voor alleen ingebouwde functies:

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

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

memory:
  provider: "hindsight"

Voor de volledige vergelijkingstabel, opmerkingen over LLM- en embedding-afhankelijkheden, uitsplitsingen per provider en hoe deze backends zich verhouden tot OpenClaw en andere stacks, zie Agent memory providers compared.

Voor profielspecifieke koppeling en productie-workflows, zie Hermes Agent production setup. De AI Systems Memory hub bevat deze gids plus gerelateerde artikelen over Cognee en de kennislagen.

Deel 3: Wanneer Geheugen Afgaat — Triggers & Beslissingen

De meest gestelde vraag over het geheugen van Hermes Agent is wanneer hij daadwerkelijk iets 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.

Schrijftriggers: Wanneer besluit de agent op te slaan?

De agent slaat geheugen proactief op. Hij wacht niet tot jij erom vraagt. Dit zijn de triggers.

Gebruikerscorrecties. Wanneer je de agent corrigeert, is dat een signaal om te onthouden. “Doe dat niet nog eens.” “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. Hij stelt pip voor. Je zegt: “Ik gebruik poetry voor alles.” De agent slaat op: User prefers using the 'poetry' package manager for all Python projects.

Ontdekte voorkeuren. De agent observeert patronen en concludeert voorkeuren. Als je consequent een bepaald hulpmiddel, framework of workflow gebruikt, wordt dit opgeslagen.

Voorbeeld: nadat de agent heeft gezien dat je poetry meerdere keren gebruikt in verschillende projecten, slaat hij dit op als een 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 geïnstalleerd is en slaat op: This machine runs Ubuntu 22.04, has Docker and kubectl installed.

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

Voorbeeld: User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.

Voltooide complexe workflows. Na het voltooien van een taak die meer dan 5 tool-aanroepen vereiste, overweegt de agent om de aanpak op te slaan als een vaardigheid, of noteert in ieder geval wat werkte.

Bijzonderheden van tools en workarounds. Wanneer de agent iets niet-voor de hand liggend ontdekt over een tool, API of systeem — een beperking, een workaround, een conventie — slaat hij dit op.

Wat wordt overgeslagen:

• Triviale of voor de hand liggende informatie
• Dingen die gemakkelijk opnieuw ontdekt kunnen worden
• Ruwe datadumps
• Sessie-specifieke vluchtige zaken
• Informatie die al in contextbestanden staat (SOUL.md, AGENTS.md)

Leestriggers: Wanneer doet de agent een recall?

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

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

session_search (op aanvraag). Wanneer de agent iets moet vinden uit eerdere gesprekken dat niet in het kerngeheugen staat, gebruikt hij de session_search tool. Deze bevraagt SQLite (~/.hermes/state.db) met FTS5 full-text search en Gemini Flash-samenvatting. Gebruik dit wanneer de vraag klinkt als “we hebben dit eerder besproken” in plaats van “onthoud dit feit voor altijd.”

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

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

De beslissingsboom

Dit is hoe de agent afweegt: “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 → Overslaan
        NEE → Is dit sessie-specifiek?
          JA → Overslaan
          NEE → Ssla op in geheugen

De agent denkt hier niet te lang over na. Hij slaat proactief op, consolideert wanneer het vol is, en vertrouwt erop dat de tekenlimieten de boel compact houden.

Deel 4: Intern Geheugen vs. Externe Kennisbanken

Hier gaat het vaak mis. Hermes Agent heeft intern geheugen (MEMORY.md, USER.md, externe providers) en externe kennisbanken (LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem), en zij dienen totaal verschillende rollen. Dit is vergelijkbaar met het onderscheid tussen retrieval-augmented generation pipelines en het werkgeheugen van een agent — externe extractie is goed voor diepe kenniszoekingen, niet voor het dragen van identiteit en voorkeuren. Intern geheugen is het brein van de agent — altijd actief, gecureerd, meegenomen in elke sessie. Externe kennisbanken zijn de bibliotheek — uitgebreide referentiebronnen die op aanvraag worden geraadpleegd.

Het onderscheid

Intern Geheugen (het brein):

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

Externe Kennisbanken (de bibliotheek):

• Uitgebreid, alleen voor referentie, op aanvraag geraadpleegd
• Bevat: documenten, papers, code, notities, databases
• Toegang via tools wanneer nodig
• Wordt niet “onthouden” — maar opgezocht
• Voorbeelden: LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem, GitHub

Hoe ze zich tot elkaar verhouden

De agent geeft toegang tot externe bronnen via tools wanneer dat nodig is. Hij “onthoudt” ze niet — hij zoekt ze op.

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

Obsidian: Persoonlijke notitie-vaults met bidirectionele links. De agent gebruikt de obsidian vaardigheid om notities te lezen, te doorzoeken en te maken. Obsidian is onderdeel van het bredere personal knowledge management ecosysteem waar Hermes als bibliotheekbron gebruik van kan maken.

Notion/Airtable: Gestructureerde databases en wiki’s die via API worden geraadpleegd. De agent bevraagt deze wanneer dat nodig is.

ArXiv: Repositories voor academische papers. De agent zoekt naar en extraheert papers wanneer hij een onderwerp onderzoekt.

Bestandssysteem: Projectcode, documentatie, configuraties. De agent leest bestanden tijdens het werken aan een project.

Het Distillatiepatroon

Dit is het cruciale inzicht: kritieke inzichten uit externe bronnen kunnen worden gedistilleerd in het interne geheugen.

Voorbeeld: de agent leest een paper van ArXiv over memory scaling voor AI-agents. Hij slaat niet de volledige paper op in het geheugen. Hij slaat de belangrijkste les op: Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

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

Wanneer welke gebruiken

Intern geheugen voor:

• “Wie help ik?”
• “Wat verkiest deze persoon?”
• “Wat hebben we zojuist geleerd?”
• “Hoe is de projectopzet?”
• “Welke tools zijn beschikbaar?”

Externe kennisbanken voor:

• “Wat is het laatste onderzoek naar X?”
• “Wat staat er in de documentatie van mijn project?”
• “Waar hebben we het vorige maand over gehad?”
• “Wat is de API voor deze service?”
• “Wat is de codestructuur?”

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

Deel 5: Hoe het werkelijk werkt

Laten we naar de mechanica kijken.

De memory tool

De agent beheert het geheugen via een enkele tool met drie acties: add, replace, remove.

Er is geen read actie — de inhoud van het geheugen wordt automatisch geïnjecteerd in de system prompt. De agent hoeft het niet te lezen, want het is er altijd.

add — Voegt een nieuw item toe.

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

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

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

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

memory(action="remove", target="memory",
       old_text="temporary project fact")

Substring Matching

replace en remove gebruiken korte, unieke substrings via old_text. Je hebt niet de volledige tekst van het item nodig. Dit maakt chirurgische bewerkingen mogelijk zonder de exacte inhoud te kennen.

Als een substring met meerdere items overeenkomt, wordt er een foutmelding teruggegeven met het verzoek om een specifischere match. De agent verfijnt dan zijn zoekopdracht.

Target Stores: memory vs user

De parameter target bepaalt welk bestand wordt bijgewerkt.

• memory — Persoonlijke notities van de agent. Omgevingsfeiten, projectconventies, tool-bijzonderheden, geleerde lessen.
• user — Gebruikersprofiel. Identiteit, rol, tijdzone, communicatievoorkeuren, irritatiepunten, workflowgewoonten.

Capaciteitsbeheer

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

Goede geheugenitems zijn compact en informatie-intensief:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

Slechte geheugenitems zijn vaag of te verhalend:

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

De eerste is compact en nuttig. De tweede is ofwel te vaag, ofwel te uitgebreid.

Session Search vs Persistent Memory

session_search en persistent geheugen dienen verschillende doelen.

Vuistregel: gebruik geheugen voor cruciale feiten die altijd in de context moeten staan. Gebruik session search voor historische zoekopdrachten.

Deel 6: De Filosofie

Waarom begrensd geheugen beter is dan onbeperkt geheugen

Het instinct is om het geheugen zo groot mogelijk te maken. Alles opslaan. Ophalen wat je nodig hebt.

Begrensd geheugen werkt beter. Dit is waarom.

Curatie dwingt kwaliteit af. 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 is van belang. 1.300 tokens in de system prompt is snel. 100.000 tokens opgehaald uit een database is traag. Geheugen moet direct zijn, geen zoekopdracht.

Ruis vermindert prestaties. Meer geheugen is geen beter geheugen. Het is een ruisiger geheugen. Het model moet het signaal van de ruis onderscheiden, en dat kost aandacht — aandacht die besteed zou moeten worden aan de eigenlijke taak.

Vergeten is een feature. Het menselijk geheugen vergeet. Dat is geen bug — dat is hoe we prioriteiten stellen. Agents zouden ook moeten vergeten. Niet alles verdient om onthouden te worden.

Het “Vergeetprobleem”

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

Dit is hoe Hermes Agent dat aanpakt:

• 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 hij oude items.
• Beveiligingsscans: Blokkeert kwaadaardige of beschadigde items.

Vergeten is geen falen — het is onderhoud. Een agent die niet kan afleren, zal uiteindelijk evenveel ruis als signaal met zich meedragen.

Memory Scaling

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

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

1. Kwalitatieve extractie: Niet alle interacties zijn het waard om te onthouden. De agent moet inzichten extraheren, geen logs.
2. Effectieve ophaalmethode: Ophaalde herinneringen moeten relevant zijn. Ruis vermindert de prestaties.
3. Generalisatie: Herinneringen moeten patronen zijn, geen specifieke details. “Gebruiker verkiest Python” schaalt. “Gebruiker voerde commando X uit op tijdstip Y” schaalt niet.

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

Wat dit betekent voor de toekomst

Geheugen wordt de competitieve voorsprong in agentic AI — niet het model zelf, maar wat het model meeneemt tussen sessies door. Twee agents met identieke onderliggende modellen kunnen heel verschillend presteren: de een onthoudt je voorkeuren, je omgeving en je eerdere fouten; de ander begint elke keer weer bij nul.

De vraag is niet langer of agents over persistent geheugen moeten beschikken. Dat staat vast: ze moeten dat hebben. De open vraag is hoe je dat geheugen goed ontwerpt — wat je bewaart, wat je weggooit, hoe je het direct maakt en hoe je voorkomt dat het ruis wordt.

Het antwoord van Hermes Agent is om het geheugen klein, gecureerd en altijd actief te houden — niet een database die je bevraagt, maar een werkend model van de gebruiker dat de agent meeneemt in elk gesprek.

Conclusie

Het geheugensysteem van Hermes Agent is bewust simpel: twee bestanden, strikte tekenlimieten, geen ophaal-pipeline, geen vector database en geen latentie per zoekopdracht. Wat klinkt als een beperking, is juist het hele punt.

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

Externe geheugenproviders breiden dit systeem uit voor gebruikers die meer nodig hebben: kennisgrafen, ondersteuning voor meerdere agents, zelf-gehoste opslag, enterprise-functies. Maar de kern blijft hetzelfde: begrensd, gecureerd, altijd beschikbaar.

En externe kennisbanken — LLM Wiki, Obsidian, Notion, ArXiv — vervullen een andere rol. Zij zijn de bibliotheek, niet het brein. De agent zoekt ze op, onthoudt ze niet. Cruciale inzichten worden gedistilleerd in het interne geheugen; de rest blijft in de bibliotheek.

Dit is hoe een AI-agent je onthoudt. 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 in april 2026 meer dan 64.000 GitHub-stars (v0.9.0), met meer dan 242 bijdragers. Het is open-source en beschikbaar op github.com/NousResearch/hermes-agent. Voor installatie-, configuratie- en workflow-gidsen, zie de Hermes Agent overview.