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

Je kent de routine. Je opent een chat met een AI-agent, legt je project uit, deelt je voorkeuren, laat werk verrichten en sluit het tabblad. Als je de volgende week terugkomt, voelt het alsof je met een vreemde spreekt: alle context is verdwenen, elke voorkeur is vergeten en het project moet opnieuw van begin af aan worden uitgelegd.

Dit is geen bug. Het is hoe Large Language Models (LLM’s) per ontwerpspecificatie werken. Ze zijn stateless (toestandsloos): elke aanvraag is onafhankelijk, elk antwoord wordt gegenereerd op basis van de prompt die je op dat moment verzendt, 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 agenten — systemen die dingen moeten doen over sessies heen, leren van fouten en met jou evolueren — 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 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 een agent verbeteren met opgebouwde ervaring. Sinds 2024 zijn er dedicated benchmarkpapers, overzichten van episodisch geheugen en een snel groeiend ecosysteem van tools verschenen om aan te sluiten bij wat steeds meer wordt erkend als een van de centrale onopgeloste problemen in agentic AI.

De meeste van deze benaderingen hebben een gemeenschappelijk probleem: ze behandelen geheugen als een afterthought — een database die je queryt, een contextvenster dat je vol propt, een retrievalsysteem dat latentie en ruis toevoegt in plaats van helderheid.

Hermes Agent kiest voor een fundamenteel andere aanpak. Geheugen is iets wat de agent niet ophaalt wanneer nodig. Het is iets wat de agent altijd is — ingebouwd in de systeem-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-agentgeheugenprobleem

Waarom “voeg gewoon context toe” niet schaleerbaar is voor agenten

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

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

Maar context is geen geheugen — er is een echt en belangrijk verschil tussen de twee. 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 irrelevante geschiedenis verwerken om het ene feit te vinden dat het nodig heeft. Dat kost tokens en geld, verhoogt de latentie en botst uiteindelijk tegen het plafond.

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

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 of zoekbaar wanneer je het nodig hebt.

Het onderzoekslandschap

De ruimte voor AI-agentgeheugen is sinds 2024 geëxpandeerd, met dedicated benchmarksuites, een groeiende literatuur 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-class onderwerp behandelden, met 21.7K GitHub-sterren. Het maakt gebruik van een OS-geïnspireerd driedelig model: kerngeheugen (klein, altijd in context), herinneringsgeheugen (zoekbare gespreksgeschiedenis) en archiefgeheugen (langdurige koude opslag). De inzage dat niet alle geheugens gelijk zijn, was correct. De implementatie vereist echter dat agenten volledig binnen de Letta-runtime draaien — adoptie betekent het adopteren van het hele platform, niet slechts van een geheugenlaag.

Zep / Graphiti richt zich op conversationeel geheugen met tijdelijke entiteitstracking — 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 agenten die omgevingsfeiten en projectconventies bijhouden.

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

Hindsight doet knowledge-graph-gebaseerd ophalen met entiteitsrelaties en een uniek reflect-synthesetool dat cross-memory-synthese uitvoert — het combineren van meerdere herinneringen tot nieuwe inzichten. Het behoort tot de topperformers op agentengeheugenbenchmarks en is beschikbaar als geheugenprovider voor Hermes Agent.

Mem0 behandelt geheugenextractie server-side via LLM-analyse, wat minimale configuratie vereist. Het Mem0-onderzoeksartikel, gepubliceerd op ECAI 2025 (arXiv:2504.19413), benchmarkte tien verschillende benaderingen voor AI-geheugen en valideerde de selectieve extractiebenadering — het opslaan van discrete feiten, duplicatie verwijderen en alleen het relevante ophalen. Mem0 is gegroeid naar ongeveer 48K GitHub-sterren en ondersteunt 21 frameworkintegraties. De afweging is cloudafhankelijkheid en kosten.

Databricks’ memory scaling-onderzoek introduceerde het concept dat agentenprestaties verbeteren met opgebouwde ervaring. Hun architectuur houdt systeem-prompts, enterprise-assets en episodisch/semantisch geheugen vast 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 ophaalprobleem: 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 het starten van de sessie geïnjecteerd en is altijd aanwezig. Altijd actief, altijd beschikbaar, gecureerd genoeg om nuttig te blijven.

Deel 2: Architectuur — Twee bestanden, één brein

Het ingebouwde geheugensysteem 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 oppervlak van persistent geheugen: twee bestanden, minder dan 3.600 karakters in totaal, minder dan 1.300 tokens. Het ziet er bewust klein uit, want dat is het ook — 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 die gRPC + PostgreSQL gebruikt
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 praatwerk, 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 zorgt dat de agent anders op jou reageert dan op iedereen else.

Het Frozen Snapshot-patroon

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

══════════════════════════════════════════════
GEHEUGEN (je persoonlijke notities) [7% — 166/2.200 tekens]

Gebruikersproject is een Go-microservice op ~/code/gateway die gRPC + PostgreSQL gebruikt § 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 tekens] ══════════════════════════════════════════════ 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, teltekens en `§` (sectieteken) als scheidingstekens. Items kunnen meerdere regels beslaan. Het is ontworpen om parsebaar te zijn door het model terwijl het mensleesbaar blijft.

Waarom bevroren? [Prefix-caching](https://www.glukhov.org/nl/llm-performance/). De systeem-prompt is hetzelfde voor elke beurt in een sessie. Door het geheugen statisch te houden na het starten 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 aandacht niet opnieuw over dezelfde geheugentokens bij elke beurt.

Wijzigingen die tijdens een sessie worden gemaakt, worden onmiddellijk op de schijf opgeslagen, maar ze verschijnen pas in de systeem-prompt bij het volgende sessiestart. Tool-antwoorden tonen altijd de live-status, maar het "brein" van het model verandert niet midden in de sessie. Dit voorkomt dat het model in een cirkel rent — geheugen bijwerken en vervolgens reageren op zijn eigen update in hetzelfde gesprek.

### Tekenslimieten als een functie

2.200 tekens. 1.375 tekens. 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 zal ik opnieuw nodig hebben? Wat kan worden gecomprimeerd zonder betekenis te verliezen?

Wanneer het 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 de foutreactie
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 belangrijk zijn.

### Beveiliging: Prompt Injection-scanning

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

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

---

## Deel 3: Wanneer geheugen vuurt — Triggers & Beslissingen

De meest gestelde vraag over het geheugen van Hermes Agent is wanneer het iets daadwerkelijk 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 besluit 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 het pakketbeheerprogramma 'poetry' voor alle Python-projecten.`

**Ontdekte voorkeuren.** De agent observeert patronen en leidt voorkeuren af. Als je consistent een bepaalde tool, framework of workflow gebruikt, wordt het opgeslagen.

Voorbeeld: na het zien van `poetry` meerdere keren 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 exploratie en opgeslagen als feiten.

Voorbeeld: de agent controleert 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: `Gebruikersproject is een Go-microservice op ~/code/gateway die gRPC + PostgreSQL gebruikt.`

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

**Tool-kwetsbaarheden en workarounds.** Wanneer de agent iets niet-alles duidelijk 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 ontdekt kunnen worden
- Raw data-dumps
- Sessie-specifieke ephemera
- Informatie die al in contextbestanden staat (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 systeem-prompt. De agent heeft ze vanaf het eerste token. Geen query nodig, geen latentie, geen tool-aanroep. Dit is het kerngeheugen — altijd actief.

**`session_search` (op aanvraag).** Wanneer de agent iets moet vinden uit vorige conversaties dat niet in het kerngeheugen staat, gebruikt het de `session_search`-tool. Dit queryt SQLite (`~/.hermes/state.db`) met FTS5 full-text search en Gemini Flash-samenvatting.

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 aanvullende tools beschikbaar: `honcho_search`, `hindsight_recall`, `mem0_search`, etc. Deze worden gebruikt wanneer de agent bepaalt dat externe context nodig is.

### De beslismatrix

Hier is hoe de agent weegt "is dit het waard om te onthouden?":

Is dit een correctie of expliciete instructie? JA → Opslaan in geheugen NEE → Is dit een voorkeur of patroon? JA → Opslaan in gebruikersprofiel NEE → Is dit een omgevingsfeit of conventie? JA → Opslaan in geheugen NEE → Is dit makkelijk opnieuw te ontdekken? JA → Overslaan NEE → Is dit sessie-specifiek? JA → Overslaan NEE → Opslaan in geheugen

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

---

## Deel 4: Intern geheugen vs. Externe kenniskatabases

Hier ontstaat vaak verwarring. Hermes Agent heeft *intern geheugen* (MEMORY.md, USER.md, externe providers) en *externe kenniskatabases* (LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem), en ze dienen volledig verschillende rollen. Dit lijkt op het onderscheid tussen [retrieval-augmented generation](https://www.glukhov.org/nl/rag/) pipelines en agent-werkgeheugen — extern ophalen is goed voor diepgaande kenniskijkopslagen, niet voor het dragen van identiteit en voorkeuren. Intern geheugen is het brein van de agent — altijd actief, gecureerd, meegenomen in elke sessie. Externe kenniskatabases zijn de bibliotheek — uitgestrekte referentiebronnen die op aanvraag worden geraadpleegd.

### Het onderscheid

**Intern Geheugen (het brein):**

- Klein, persistent, geïnjecteerd in systeem-prompt
- Bevat: gebruikersvoorkeuren, agentconventies, onmiddellijke lessen
- Altijd "in gedachten" tijdens het gesprek
- Gecureerd, begrensd, actief beheerd
- Voorbeelden: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Externe Kenniskatabases (de bibliotheek):**

- Uitgestrekt, alleen referentie, op aanvraag toegankelijk
- Bevat: documenten, papers, code, notities, databases
- Toegankelijk via tools wanneer nodig
- Niet "onthouden" — opgehaald
- Voorbeelden: LLM Wiki, Obsidian, Notion, ArXiv, bestandssysteem, GitHub

### Hoe ze samenhangen

De agent *toegankelijk* externe bases via tools wanneer nodig. Het "onthoudt" ze niet — het haalt ze op.

**LLM Wiki (llm-wiki):** Karpathy's gekruiste Markdown-kennisknowledgebase voor het bouwen en queryen van domeinkennis. De agent gebruikt de `llm-wiki`-vaardigheid om deze te lezen, te doorzoeken en te queryen. Het is een referentiebron, geen geheugen.

**[Obsidian](https://www.glukhov.org/nl/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Persoonlijke notitiekluisjes met bidirectionele links. De agent gebruikt de `obsidian`-vaardigheid om notities te lezen, te doorzoeken en te maken. Obsidian is onderdeel van het bredere [persoonlijke kennismanagement](https://www.glukhov.org/nl/knowledge-management/) ecosysteem waarnaar Hermes kan grijpen als een bibliotheekbron.

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

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

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

### Het distillatiepatroon

Hier is de kerninzage: kritieke inzichten uit externe bases kunnen worden *gedistilleerd* naar intern geheugen.

Voorbeeld: de agent leest een paper van ArXiv over geheugenschaal voor AI-agenten. Het slaat niet het hele paper op in het geheugen. Het slaat de kernboodschap op: `Geheugenschaal: agentenprestaties verbeteren met opgebouwde ervaring door gebruikersinteractie en zakelijke context die in geheugen wordt opgeslagen.`

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

### Wanneer welke te gebruiken

**Intern geheugen voor:**

- "Wie help ik?"
- "Wat geeft hij/zij de voorkeur?"
- "Wat hebben we net geleerd?"
- "Wat is de projectopstelling?"
- "Welke tools zijn beschikbaar?"

**Externe kenniskatabases voor:**

- "Wat is het nieuwste 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 de juiste manier — het verwarren van het opzoeken van een document met het terugroepen van iets dat het heeft geleerd over jou en je omgeving gebeurt niet.

---

## Deel 5: Hoe het daadwerkelijk werkt

Laten we kijken naar de mechanica.

### De `memory`-tool

De agent beheert geheugen via een enkele tool met drie acties: `add` (toevoegen), `replace` (vervangen), `remove` (verwijderen).

Er is geen `read` (lees) actie — geheugeninhoud wordt automatisch geïnjecteerd in de systeem-prompt. De agent hoeft het niet te lezen omdat het altijd daar is.

**`add`** — Voegt een nieuw item toe.

```python
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 hebt de volledige itemtekst niet nodig. Dit maakt chirurgische bewerkingen mogelijk zonder de exacte inhoud te kennen.

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

Doelstores: memory vs user

De target-parameter bepaalt welk bestand wordt bijgewerkt.

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

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 een kijkje te nemen op hun project dat zich bevindt op ~/code/gateway en het gebruikt Go met gRPC en PostgreSQL voor de databaselayer.

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

Sessiezoektocht vs Persistent geheugen

session_search en persistent geheugen dienen verschillende doeleinden.

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

Deel 6: Externe geheugenproviders — Alle 8 optingen vergeleken

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

Slechts één extern provider kan tegelijk 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

Providervergelijking

Gedetailleerde uitsplitsing

Honcho

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

Honcho draait naast bestaand geheugen — USER.md blijft zoals het is, en Honcho voegt een aanvullende contextlaag toe. Het modelt conversaties als peers die berichten uitwisselen — één gebruikerspeer plus één AI-peer per Hermes-profiel, allemaal een workspace delend.

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

Belangrijkste configuratieknoppen:

• contextCadence (standaard 1): Minimale beurten tussen basislaagverversing
• dialecticCadence (standaard 2): Minimale beurten tussen peer.chat() LLM-aanroepen (1-5 aanbevolen)
• dialecticDepth (standaard 1): .chat() passes per aanroep (geklamd 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 + peerkaart) + dialectisch supplement (LLM-redenering). Selecteert automatisch cold-start vs warm prompts.

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

Instellen:

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

Configuratie: $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                   # Backfills AI-peers voor bestaande profielen

OpenViking

Best voor: zelfgehost kennismanagement met gestructureerd browsen.

OpenViking biedt een bestandssysteemhierarchy met gelaadde ophaling. 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.

Instellen:

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

Mem0

Best voor: hands-free geheugenbeheer met automatische extractie.

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

Tools: mem0_profile, mem0_search, mem0_conclude.

Instellen:

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

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

Hindsight

Best voor: knowledge-graph-gebaseerd ophalen met entiteitsrelaties.

Hindsight bouwt een kennisgrafiek van je geheugen, extracteert entiteiten en relaties. Zijn unieke reflect-tool voert cross-memory-synthese uit — het combineren van meerdere herinneringen tot nieuwe inzichten.

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

Instellen:

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.

Configuratie: $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 cloudafhankelijkheid — alles draait lokaal op je eigen hardware.

Tools: 2 tools voor geheugenoperaties via HRR-algebra.

Instellen:

hermes memory setup  # selecteer "holographic"

Geen afhankelijkheden. Alles draait lokaal.

RetainDB

Best voor: hoge frequentie updates met deltacompressie.

RetainDB gebruikt deltacompressie om geheugenupdates efficiënt op te slaan. Het is cloud-based met een kost van $20 per maand, maar de compressie betekent minder datatransfer en snellere updates.

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

Instellen:

hermes memory setup  # selecteer "retaindb"

ByteRover

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

ByteRover comprimeert geheugen voor extractie, waardoor het bandbreedtegebruik wordt verminderd. Beschikbaar in lokale of cloud-modi.

Tools: 3 tools voor geheugenoperaties.

Instellen:

hermes memory setup  # selecteer "byterover"

Supermemory

Best voor: enterprise-workflows met contextafhechting en sessiegrafiek-ingest.

Supermemory biedt contextafhechting (geheugen isoleren per context) en sessiegrafiek-ingest (importeren van volledige gespreksgeschiedenissen). Het is cloud-based en betaald, maar ontworpen voor enterprise-schaal geheugenbeheer.

Tools: 4 tools voor geheugenoperaties.

Instellen:

hermes memory setup  # selecteer "supermemory"

Hoe te kiezen

• Multi-agent ondersteuning nodig? Honcho
• Zelfgehost en gratis willen? OpenViking of Holographic
• Zero-config willen? Mem0
• Kennisgrafieken willen? Hindsight
• Deltacompressie willen? RetainDB
• Bandbreedte-efficiëntie willen? ByteRover
• Enterprise-functies willen? Supermemory
• Privacy (alleen lokaal) willen? Holographic

Voor volledige profiel-per-profiel providerconfiguraties en real-world workflowpatronen, zie Hermes Agent production setup.

Deel 7: De filosofie

Waarom begrensde geheugen onbeperkt geheugen verslaat

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

Begrensde 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 is belangrijk. 1.300 tokens in de systeem-prompt is snel. 100.000 tokens opgehaald uit een database is langzaam. Geheugen moet onmiddellijk zijn, geen query.

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

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

Het “vergeten” probleem

Agenten moeten onleren. Niet alleen vergeten, maar actief verouderde informatie verwijderen.

Hier is hoe Hermes Agent dit 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 kwaadwillige of gecorrumpeerde items.

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

Geheugenschaal

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

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

1. Kwaliteitsextractie: Niet alle interacties zijn het waard om te onthouden. De agent moet inzichten extraheren, geen logs.
2. Effectief ophalen: Opgehaalde herinneringen moeten relevant zijn. Ruis degradeert 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.

Het begrensde geheugen van Hermes Agent ondersteunt geheugenschaal 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 tussen sessies draagt. Twee agenten 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 agenten 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 onmiddellijk 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 eenvoudig: twee bestanden, strenge tekenslimieten, geen retrievalpipeline, 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 zoals een database — 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 systeem-prompt vanaf het 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: begrens, gecureerd, altijd beschikbaar.

En externe kenniskatabases — LLM Wiki, Obsidian, Notion, ArXiv — dienen een andere rol. Ze zijn de bibliotheek, niet het brein. De agent zoekt ze op, onthoudt ze niet. Kritieke 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 belangrijk is.

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 de Hermes Agent overzicht.