Engram: de lokale hippocampus voor AI coding agents — geen brein, wél onmisbaar

AI coding agents verliezen context tussen sessies. Dat is niet nieuw, het is het fundamentele probleem van elke agent die in een terminal draait. Engram pakt dit aan met een opvallend minimalistische aanpak: één Go binary, SQLite + FTS5, ontsloten als CLI, HTTP API, MCP-server en TUI. Geen vector database, geen cloud-afhankelijkheid, geen Python of Node.js. De repo heeft zo'n 4.4K sterren, 513 forks, en positioneert zich expliciet agent-agnostisch met ondersteuning voor Claude Code, OpenCode, Gemini CLI, Codex, VS Code Copilot, Cursor, Windsurf en andere MCP-clients.

Voor organisaties die AI coding agents gebruiken is dit geen "nog een memory tool". Het is een interessante edge memory node: lichtgewicht, lokaal, project-georiënteerd, MCP-native, en daardoor bruikbaar naast een centrale memory stack.

Wat Engram feitelijk doet

Engram slaat gestructureerde observaties op, typisch na een bugfix, architectuurbesluit, patroon, discovery of learning. De agent gebruikt mem_save, met metadata zoals type, scope, topic_key en content in vaste blokken: What, Why, Where en Learned. Duplicaten worden gededupliceerd, en topic_key maakt upserts mogelijk voor evoluerende onderwerpen.

De opslag is bewust simpel gehouden:

Laag	Keuze
Runtime	Single Go binary
Storage	SQLite
Search	SQLite FTS5
Integratie	MCP, HTTP API, CLI, TUI
Scope	Project, personal, global
Sync	Git sync en optioneel cloud sync
Agent support	Claude Code, OpenCode, Gemini CLI, Codex, VS Code, Cursor, Windsurf, en elke MCP-client

De database bevat onder meer sessions, observations, observations_fts, user_prompts, prompts_fts, sync_chunks, memory_relations en sync_apply_deferred. Dat betekent dat Engram niet alleen losse herinneringen opslaat, maar ook sessies, prompts, full-text indexering, relaties en deferred sync-mutaties ondersteunt. Het is meer dan een key-value store met een search-laag erop.

Architectuurwaarde: drie sterke ontwerpkeuzes

De eerste sterke keuze: geen vector database als eerste dependency. De maintainers stellen dat SQLite + FTS5 voor zo'n 95 procent van de use-cases volstaat, en dat voorkomt ChromaDB/Pinecone-achtige complexiteit. Voor lokale agent workflows is dat pragmatisch correct: veel memory-retrieval is keyword, projectnaam, sessie, topic_key en recency-gedreven, niet altijd semantische embedding-search. Dit is hetzelfde inzicht dat ten grondslag ligt aan de RushDB-analyse: een memory-systeem hoeft niet alles te kunnen om nuttig te zijn.

De tweede sterke keuze: curated memory in plaats van raw auto-capture. Engram ingest niet automatisch alle tool calls of shell history, maar laat de agent expliciet samenvattingen opslaan. Dat verlaagt noise, privacyrisico en opslagvervuiling. Voor enterprise agent governance is dit belangrijk: je wilt geen ongecontroleerde transcript-dump als geheugenlaag. Dit sluit direct aan op de MemoryTrap-analyse: memory is een attack surface, en auto-capture zonder curation maakt die surface onbeheersbaar.

De derde sterke keuze: MCP-native interface. Engram draait als lokale MCP-server, waardoor agents het geheugen via gestandaardiseerde tools benaderen. De repo beschrijft 20 MCP-tools, waaronder mem_save, mem_search, mem_context, mem_session_summary, mem_timeline, mem_current_project, mem_doctor en mem_merge_projects. Dit is hetzelfde patroon als Hivemind maar zonder de cross-agent contamination risico's, Engram is per definitie lokaal, niet gedeeld.

Functioneel interessante onderdelen

A. Session lifecycle

Engram ondersteunt expliciet sessies: start, end, context, samenvatting en timeline. mem_session_summary gebruikt een gestructureerd format met Goal, Instructions, Discoveries, Accomplished, Next Steps en Relevant Files. Dat is precies het type end-of-run artefact dat je nodig hebt om agentic work reproduceerbaar te maken.

Voor enterprise agentic engineering is dit bruikbaar als agent-run handoff protocol. Elke Claude Code, Codex of OpenCode-run kan afsluiten met een Engram-style session summary, waarna die later naar centrale memory kan worden geprojecteerd. Dit is de operationele basis voor de Machine Contributor Policy die we eerder beschreven: zonder session summary is een agent-run een niet-herleidbaar artefact.

B. Project detectie en normalisatie

Engram detecteert projectnamen vanaf git remote, normaliseert naar lowercase en waarschuwt bij vergelijkbare projectnamen. Buiten git gebruikt het de directorynaam. Dit voorkomt "memory drift", waarbij hetzelfde project onder varianten als myproject, MyProject en my-project terechtkomt.

Voor organisaties met meerdere repositories en agents is dit relevant. Engram's project-normalisatie kan dienen als lokale guardrail, maar moet niet de bron van waarheid worden. Die rol hoort bij een centrale project registry. De les uit Supermemory was dat zonder project-scoping memory een ongedifferentieerde massa wordt; Engram's normalisatie is een eerste stap, maar geen vervanging voor centraal project-beleid.

C. Team sharing via Git

Engram kan memories exporteren naar .engram/ en via Git delen. Andere machines kunnen engram sync --import uitvoeren. De documentatie positioneert dit als onboardingmechanisme: nieuwe contributors krijgen projectcontext mee bij clone of import.

Voor teamgebruik is dit handig voor repo-lokale kennis, maar gevaarlijk zonder beleid. .engram/ in Git betekent dat geheugenartefacten versieerbaar worden, maar ook dat je per ongeluk interne beslissingen, promptcontext of gevoelige observaties kunt committen. Lokaal prima, team/shared alleen met review policy. Dit is hetzelfde governance-patroon als GDPRuler: de storage-laag is technisch capable, maar de policy-laag moet je zelf bouwen.

D. Conflict detection en memory relations

Engram heeft relationele memory-functionaliteit, waaronder conflicts_with, supersedes, compatible, related, scoped en not_conflict. Het ondersteunt conflict scans, eventueel met LLM-judging via Claude of OpenCode, en houdt deferred relation sync bij.

Dit is opvallend volwassen. Veel memorytools beperken zich tot opslaan en zoeken. Engram erkent dat geheugen veroudert, conflicteert en vervangen wordt. Voor agentic engineering is dit cruciaal: zonder conflictmodel verandert memory in een "semantic landfill". De Hivemind-analyse signaleerde dit risico al: cross-agent memory zonder conflictresolutie produceert tegenstrijdige architectuurbeslissingen die niemand meer kan ontwarren.

Maturity en risico's

De repo is populair, met 4.4K sterren, 513 forks, 56 open issues en 7 pull requests. Dat wijst op tractie, maar ook op actieve churn. Er zijn concrete open issues die voor productiegebruik relevant zijn: sync-problemen, relation mutations die niet overal correct worden verwerkt, setup-onduidelijkheid, stale WAL-index risico's, versie-inconsistentie in /health, en MCP/IDE-compatibiliteit.

Mijn inschatting: Engram is geschikt als lokale developer/agent productivity layer, nog niet als enterprise-grade canonical memory backend.

Belangrijkste risico's:

Risico	Impact	Mitigatie
Sync-bugs rond relations/chunks	Medium tot hoog	Eerst local-only draaien, cloud sync uitzetten
Prompt/context leakage	Hoog	Scope discipline, geen automatische Git commits van .engram/
Project name drift	Medium	Centrale project mapping afdwingen
SQLite file lifecycle/WAL issues	Medium	Backups, doctor checks, geen file replacement onder draaiende processen
Geen semantische vectorlaag	Laag tot medium	Prima voor local memory; centrale semantic layer blijft nodig voor cross-project recall
Agent discipline vereist	Hoog	Memory Protocol in agent instructions opnemen

De gelaagde memory-architectuur

Voor organisaties met een bestaande centrale memory stack is Engram geen vervanging. Wel is het een sterke lokale memory sidecar per workstation of per repo. De architectuur die ontstaat is drielagig:

Agent runtime (Claude Code / Codex / OpenCode / ...)
        |
        | MCP
        v
Local Engram sidecar
SQLite + FTS5 + session summaries + project observations
        |
        | projector / sync job
        v
Canonical memory platform
Vector store + Graph store + Skill factory + Audit ledger

Daarmee krijg je drie niveaus:

1. Ephemeral context, in de actieve agentsessie. Wat de agent nu aan het doen is.
2. Local durable context, via Engram per repo of workstation. Snel, pragmatisch, dicht bij de agent.
3. Canonical collective memory, via de centrale memory stack. Governance, traceability, relations, skill evolution en organisatie-brede recall.

Dit is precies de juiste scheiding. Engram mag snel, pragmatisch en lokaal zijn. De centrale memory-laag blijft governance, traceability, relations, skill evolution en swarm-wide recall leveren. De Machine Contributor Policy definieert wát er bewaard moet worden; Engram levert het lokale opslagmechanisme.

Concrete toepassing: vier use-cases

Eén: repo-lokale agent memory. Per project kan Engram beslissingen, fixes, commands, discovered patterns en next steps opslaan. Dit is de basislaag: de agent heeft een geheugen dat sessies overleeft zonder afhankelijk te zijn van een centraal systeem.

Twee: session handoff. Laat elke serieuze agent-run afsluiten met mem_session_summary. Die summary wordt vervolgens geprojecteerd naar de centrale memory stack. Dit maakt agent-runs auditeerbaar: wat was het goal, wat is ontdekt, wat is geaccomplished, wat zijn de next steps.

Drie: compaction recovery. Claude Code, Codex en Gemini CLI verliezen vaak state tijdens contextcompressie. Engram beschrijft expliciet recovery-instructies na compaction, inclusief mem_context en sessiesamenvattingen. De agent kan na een compaction de vorige sessie reconstrueren uit Engram in plaats van opnieuw te beginnen.

Vier: local-first fallback. Als de centrale memory stack degraded is, kan Engram nog steeds projectcontext leveren. Dit is een resilience-patroon: de agent is niet volledig afhankelijk van centrale infrastructuur voor basale geheugenfuncties.

Adoptiepad: van spike naar productie

Fase 0, Spike. Bewijzen dat Engram lokaal werkt met één project en één agent.

brew install gentleman-programming/tap/engram
engram version
engram doctor
engram setup codex    # of claude-code, opencode, gemini-cli
engram serve
engram tui

Voor Linux of source build: git clone, go install ./cmd/engram. De repo documenteert installatie via Homebrew en source build, plus setup voor Claude Code, OpenCode, Gemini CLI, Codex en VS Code.

Fase 1, Pilot. Kies één repo. Minimale policy:

Engram usage policy:
- Save only durable project knowledge.
- Do not save secrets, tokens, credentials, PII or raw logs.
- Use type decision, architecture, bugfix, pattern, config, discovery or learning.
- Use topic_key for evolving architectural topics.
- End each session with mem_session_summary.
- Keep .engram/ out of Git during pilot unless explicitly reviewed.

Fase 2, Projector bouwen. Een simpele projector van Engram SQLite naar de centrale memory stack:

Engram SQLite
  observations
  sessions
  user_prompts
  memory_relations
        |
        v
memory-ingest service
        |
        +--> Canonical ledger (immutable event log)
        +--> Vector store (semantic projection)
        +--> Graph store (relation graph)
        +--> Skill factory (validated patterns)

Projecteer niet alles automatisch. Gebruik filters:

Engram type	Projecteren?	Doel
decision	Ja	Architecture Decision Record
architecture	Ja	Knowledge graph
bugfix	Ja, selectief	Operational learnings
pattern	Ja	Skill candidate
config	Ja, met secret scan	Runbook/config memory
discovery	Ja, selectief	Research memory
learning	Ja, na dedup	Skill evolution
personal	Nee	Lokaal houden
global	Alleen reviewed	Cross-project policy

Fase 3, Agent protocol. Voeg aan agent instructions een kort protocol toe:

At session start:
1. Detect current project.
2. Retrieve recent project memory.
3. Continue from previous session summary when relevant.

During work:
1. Save durable decisions, architecture findings, bugfixes,
   reusable patterns and configuration learnings.
2. Do not save secrets, credentials, PII, raw logs or
   temporary speculation.
3. Use stable topic_key values for evolving topics.

At session end:
1. Save a structured session summary.
2. Include goal, discoveries, accomplished work,
   next steps and relevant files.

Security en governance

Vanuit NIST AI RMF, ISO 27001 en Zero Trust perspectief is Engram aanvaardbaar voor lokale experimentation, mits de scope hard begrensd is.

Minimum controls:

Control	Maatregel
Data minimization	Alleen curated memory, geen raw firehose
Secret hygiene	Secret scanning vóór Git sync
Local access	Bestandsrechten op ~/.engram/engram.db
Auditability	Session summary verplicht
Integrity	Centrale projector schrijft immutable event naar audit ledger
Sync governance	Cloud sync uit tot pilot stabiel is
Retention	Review cycles gebruiken voor verouderde observaties
Classification	scope=personal/project/global afdwingen

De keuze voor "no raw tool-call auto-capture" is positief vanuit privacy en governance. Maar Git sync en cloud sync moeten pas na review aan. De MemoryTrap-analyse liet zien hoe memory poisoning persistent kan zijn over sessies heen; Engram's curated-model beperkt die exposure, maar elimineert hem niet.

Eindoordeel

Score: 8/10 als local sidecar, 5/10 als centrale memory-laag.

Sterk:

• MCP-native en agent-agnostisch, werkt met elke agent die MCP spreekt
• Single binary, lage operationele complexiteit, geen Python, Node.js of Docker
• SQLite + FTS5 is goed genoeg voor lokale recall, geen vector database overhead
• Session summaries en compaction recovery zijn direct waardevol voor agentic workflows
• Conflict/relations-model is verrassend volwassen, geen "semantic landfill"
• Past goed bij een workstation-first agentic engineering model

Zwak:

• Open issues rond sync, cloud, setup en WAL maken productiegebruik als shared backend riskant
• Geen native vector- of graph-first architectuur, niet geschikt als vervanger van een centrale semantic layer
• Memorykwaliteit hangt volledig af van agentdiscipline, geen automatische governance
• Git sync kan governanceproblemen veroorzaken als .engram/ ongecontroleerd wordt gedeeld

Concrete aanbeveling: installeer Engram als MCP memory sidecar voor coding agents. Zet cloud sync uit. Gebruik het één week op twee à drie repo's. Bouw daarna een read-only projector van Engram naar de centrale memory stack.

De strategische waarde zit niet in Engram als "brein", maar als lokale hippocampus: snel, dichtbij de agent, goed in sessieherinnering, maar ondergeschikt aan de centrale, governable memory cortex. De Machine Contributor Policy definieert de regels voor wat agents mogen bijdragen; Engram levert het lokale geheugen dat die bijdragen context geeft.

Gebaseerd op: Gentleman-Programming/engram. "Persistent memory system for AI coding agents." github.com/Gentleman-Programming/engram. MIT License, © 2026 Alan Buscaglia. 4.4K stars, 342 commits, versie 1.x.