Picking a Memory Provider for Hermes Agent: Lucid's Winning Bet

TL;DR: Hermes Agent has 8 memory provider plugins but none called Lucid — despite the config claiming it. Two elimination rounds narrowed the field: Round 1 cleared out cloud-dependent and key-value-only providers. Round 2 pitted Hindsight (embedded PostgreSQL, knowledge graph) against Lucid (SQLite, ACT-R cognitive retrieval). Lucid won on existing data (43 memories), zero setup, and an already-working MCP server — needing only a 50-line bridge plugin.

How It Started — The Agent Had Amnesia

It started with a simple request: “use beads for tracking plans and features.” That led to a rabbit hole. The beads database was empty because the profile sandbox had blown away the server-mode config. Re-initializing beads with --server fixed that. But during the fix, I checked why the agent kept forgetting things — and found the real problem.

The Hermes config file said memory.provider: lucid. But inside plugins/memory/, there were 8 directories: holographic, hindsight, openviking, honcho, mem0, retaindb, byterover, supermemory. No lucid. The config was silently failing, falling back to the built-in default — a tiny in-memory store that forgot everything between sessions.

Meanwhile, three fragmented memory databases sat on disk:

System	Size	Content	Status
Hermes built-in	ephemeral	near-empty	working (tiny)
Holographic (`memory_store.db`)	272 KB	16 facts, 33 entities, 3 memory banks	working (passive)
Lucid CLI (`memory.db`)	892 KB	43 memories, 49 associations, 30 projects	broken (sandbox path)

Three databases, zero coordination, one broken config. The agent had been flying blind.

Round 1 — Eliminating the Unfit

I crawled the Hermes memory providers documentation and read every plugin’s __init__.py source code. Then built a comparison matrix across all 8 providers plus Lucid.

flowchart TB Start["8 Native Providers + Lucid"] --> Filter1{"Local-first?"} Filter1 -- No --> Eliminated1["mem0\nSupermemory\nHoncho"] Filter1 -- Yes --> Filter2{"Semantic recall?"} Filter2 -- No --> Eliminated2["RetainDB\nByterover"] Filter2 -- Yes --> Contenders["Holographic\nHindsight\nOpenViking"] Start --> LucidCheck{"Lucid\n(plugin exists?)"} LucidCheck -- No --> LucidCLI["Lucid CLI only\nno plugin"] LucidCLI --> Contenders Contenders --> Round2{"Round 2: Deep\nComparison"}

Quick Knockouts

Four providers eliminated immediately for failing the local-first constraint:

mem0 — Python + their cloud API. Memories leave the machine. Same problem as sending your diary to a stranger.

Supermemory — Python + external API. Third-party cloud service. Privacy non-starter.

Honcho — Python + cloud or self-hosted. Largest plugin at 1053 lines. Needs honcho-ai pip package. Its unique feature — dialectic reasoning where an LLM synthesizes a user model from conversation history — is impressive for multi-agent setups. But for a single-agent local-first setup, it’s overkill with a cloud dependency.

Two more eliminated for having no semantic retrieval:

RetainDB — Simple key-value persistence. No vector search, no semantic understanding. Saves and recalls by key — essentially a JSON file with database overhead.

Byterover — Byte-level patching for memory deltas. Niche concept for incremental updates. Not designed for semantic recall at all.

The Surviving Five

That left five contenders with local storage and semantic capabilities:

Provider	Language	Storage	Semantic Search	Auto-extract	Setup
Holographic	Python	SQLite	FTS5 + HRR algebraic	Regex only	Zero
Hindsight	Python	Embedded PG (pgrx Rust)	Server-side semantic	LLM-powered, continuous	Medium
OpenViking	Python (httpx)	External server	Server-side semantic	6 categories	Heavy
Lucid	TypeScript/Bun	SQLite	bge-base-en-v1.5 embeddings	Manual only	Zero
Honcho (reconsidered)	Python	Cloud/self-hosted	LLM-synthesized reasoning	Server-side	Medium

Round 1 Verdict

OpenViking needed a running external server — too much infra for one agent. Honcho needed cloud API or self-hosted backend — same problem. Three survivors into Round 2: Holographic (already running), Hindsight (best retrieval quality), Lucid (richest data, no plugin).

Round 2 — Deep Comparison

flowchart TB R2["Round 2 Survivors"] --> H["Holographic\n(already running)"] R2 --> Hi["Hindsight\n(best retrieval)"] R2 --> L["Lucid\n(richest data)"] H --> H1["16 facts after weeks\nRegex auto-extract\nNo semantic search\nHRR degrades past 256 items"] Hi --> Hi1["Embedded PG + knowledge graph\nLLM-powered auto-extract\nReflect synthesis tool\nMedium setup complexity"] L --> L1["43 memories, 49 associations\nbge-base embeddings\nVisual + location memory\nACT-R cognitive retrieval"] H1 --> Decision{"Decision"} Hi1 --> Decision L1 --> Decision Decision -->|"16 facts ≠ useful\nrecall"| DropH["Holographic: Eliminated\nGood engine, weak output"] Decision -->|"Best quality\nbut needs PG install\nand LLM calls per turn"| DropHi["Hindsight: Runner-up\nBest specs, wrong tradeoff"] Decision -->|"43 memories exist\nMCP server ready\nZero additional setup\nSQLite only"| Winner["Lucid: Winner\nAlready the answer"]

Holographic — Already Running, Barely Useful

The Holographic provider (registered as hermes-memory-store) was already active. Its internals:

Auto-extraction: Regex patterns scan conversations for facts. Catches structured data (config values, error messages) but misses nuance. No LLM understanding.
Storage: SQLite with HRR (Holographic Reduced Representation) vectors — 1024-dimensional algebraic embeddings. Sound approach, but degrades past ~256 items.
Trust scoring: +0.05 on confirm, -0.10 on contradiction. Interesting idea, rarely triggered.
Memory banks: Three categories — user_pref, project, tool. Facts sorted into buckets.
Probe/reason/contradict tools: Unique to holographic. Can probe a fact, reason about it, detect contradictions. Theoretically powerful.

The problem: after weeks of use, only 16 facts. 33 entities. Three memory banks. The regex auto-extraction was too passive — it caught XPASS OIDC config and Astro version numbers but never surfaced anything useful during actual work. The agent never recalled a holographic memory when it mattered.

Holographic’s HRR vectors are algebraic, not learned embeddings. They encode data as hyperdimensional vectors for approximate matching. This is clever but fundamentally weaker than learned embeddings (like bge-base) for semantic similarity tasks. HRR works well for exact or near-exact recall but struggles with paraphrase, synonym, or conceptual matching.

Hindsight — The Spec Leader

Hindsight was the most impressive on paper. Python + embedded PostgreSQL via pgrx (a Rust extension for PG). Features:

Semantic search: Proper learned embeddings, not algebraic approximations.
Knowledge graph: Memories connected via relationships, enabling multi-hop reasoning.
LLM synthesis: reflect tool — an LLM reviews stored memories and synthesizes new conclusions. Cross-pollinates knowledge across sessions.
Continuous auto-extract: LLM-powered extraction runs on every turn. No regex limitations.
Temporal tracking: When memories were created, modified, and accessed.

The catch: setup complexity. Embedded PG requires installation. LLM calls per extraction turn = token cost. For a single-agent local-first setup, the infra overhead felt disproportionate.

Lucid — Already the Answer

Lucid v0.6.5 was already installed, already populated, and already had an MCP server. What I found when I inspected the codebase:

flowchart LR subgraph Lucid["Lucid v0.6.5 Internals"] CLI["cli.ts (27 KB)
store, query, context, stats"] Server["server.ts (54 KB)
MCP server implementation"] Storage["storage.ts (94 KB)
SQLite + ACT-R retrieval"] Retrieval["retrieval.ts (70 KB)
Cognitive retrieval engine"] Embed["embeddings.ts (14 KB)
ONNX bge-base-en-v1.5"] end subgraph Data["SQLite Schema"] Mem["memories
gist, weight, consolidation"] Assoc["associations
strength, co-access count"] Emb["embeddings
768-dim BLOB vectors"] Loc["location_intuitions
file familiarity"] end CLI --> Storage --> Retrieval --> Embed Storage --> Data

The “native Rust retrieval engine (100x faster)” claim in the version output is misleading — the application code is TypeScript/Bun, with a bash wrapper (exec bun run "$HOME/.lucid/server/src/cli.ts"). The “Rust” part is the ONNX Runtime executing the bge-base-en-v1.5 embedding model. Marketing aside, the engineering is solid.

Why Lucid won over Hindsight:

Criterion	Hindsight	Lucid
Existing data	0 memories	43 memories, 49 associations, 30 projects
Setup	Install embedded PG + pgrx	Already installed
Dependencies	PostgreSQL, Python SDK	Bun (already installed)
Runtime cost	LLM calls per extraction turn	Zero (manual store + auto-recall)
Knowledge graph	Yes	Yes (associations with co-access)
Visual memory	No	Yes (images, videos)
Location tracking	No	Yes (file familiarity across projects)
MCP interface	No (plugin API only)	Yes (first-class MCP server)

The deciding factor: 43 existing memories across 30 projects. Lucid already knew about Astro 6, Tailwind v4, XPASS SAML2, z.ai, context-mode, and dozens of other project contexts. Hindsight would have started from zero.

Wiring Lucid Into Hermes

Lucid had a working MCP server (lucid-server) with tools: memory_store, memory_query, memory_context, memory_forget, memory_stats. Hermes has a native MCP client. The gap: a bridge plugin.

flowchart TB subgraph Hermes["Hermes Agent"] MM["memory_manager.py"] Config["config.yaml
memory.provider: lucid"] MM --> PluginPath["plugins/memory/"] PluginPath --> Holo["holographic/
(auto-extract)"] PluginPath --> LucidPlugin["lucid/__init__.py
(NEW — MCP bridge)"] end subgraph LucidMCP["Lucid MCP Server"] Store["memory_store"] Query["memory_query"] Context["memory_context"] Forget["memory_forget"] Stats["memory_stats"] end LucidPlugin -->|"MCP subprocess"| LucidMCP MM -->|"loads provider"| LucidPlugin Config -->|"reads"| MM

The plugin (plugins/lucid/__init__.py) is a thin bridge — Hermes calls store(), query(), forget(), and the plugin translates to MCP tool invocations on the Lucid subprocess. ~50 lines of Python.

The Sandbox Problem That Started It All

Before Lucid could work, there was a path issue. The Hermes profile sandbox maps ~ to ~/.hermes/profiles/context-mode/home/ instead of the real home directory. Lucid’s binary looks for $HOME/.lucid/server/src/cli.ts — which resolves to the sandbox path, not the real installation.

1
Sandbox HOME:  ~/.hermes/profiles/context-mode/home/
2
                 └── .lucid/  → BROKEN (doesn't exist here)
3

4
Real install:   ~/.lucid/
5
                 ├── bin/lucid (bash wrapper)
6
                 └── server/src/cli.ts (27 KB)

Fix: a symlink from the sandbox home to the real Lucid installation:

1
ln -sfn ~/.lucid ~/.lucid
2
# Resolves: ~/.hermes/profiles/context-mode/home/.lucid → ~/.lucid

This must be done every session. Not ideal, but functional. The proper fix is setting HOME correctly in the sandbox environment or adding a LUCID_HOME variable to Lucid itself.

The Final Architecture

After both elimination rounds, the system settled into a clean separation of concerns:

Beads — workflow tracking. Epics, tasks, status, priorities. “What needs doing and what’s done.” Backed by Dolt SQL server at 127.0.0.1:41179.

Lucid — semantic knowledge. “What I know about this project and why it matters.” 43 memories across 30 projects, searchable by concept not just keywords. Visual memory for images and videos. Location tracking for file familiarity.

Holographic — auto-extracted facts. Low-effort background memory from conversations. Catches config values, error patterns, environment details without manual intervention.

Skills — reusable procedures. “How to do X correctly.” Versioned, patchable, loaded on demand.

Memory Types in Practice

Lucid supports six memory types that map cleanly to agent workflows:

Type	When to Store	Example
`learning`	Discovered facts about codebase, tools, APIs	”XPASS requires php.ini 512M for Twig + Predis”
`decision`	Choices made with rationale	”Chose Lucid over Hindsight — existing data won”
`context`	Project state, environment details	”Astro dev port 4321, not 9999”
`bug`	Problems found and their solutions	”Sandbox HOME path breaks lucid CLI — need symlink”
`solution`	Proven approaches for reuse	”wan2.7-image-pro doesn’t support image+text input; use qwen-image-2.0-pro instead”
`conversation`	User preferences, corrections	”User prefers 16 aspect ratio for images”

The agent stores proactively — when learning something, making a decision, or fixing a bug. Not when asked. At session start, memory_context(currentTask) surfaces relevant past context automatically.

Before and After

Before this session:

memory.provider: lucid in config — broken, no plugin existed
43 Lucid memories — inaccessible to the agent (sandbox path issue)
3 memory databases — fragmented, no coordination
Holographic — running but passive (16 facts in weeks)
Agent behavior — amnesiac between sessions

After:

Lucid MCP plugin — wired in, config truthful
43 memories + 49 associations — queryable every session
Clear separation — beads for tasks, Lucid for knowledge, holographic for auto-extract
Agent behavior — proactive recall, stores learnings without being asked

The fix wasn’t choosing the “best” provider from a list. It was recognizing that the best option was already installed, already populated, and already had an MCP interface — it just needed a bridge plugin to connect it to Hermes.

References

Hermes Agent Memory Providers — NousResearch (2026) — https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers
Holographic Memory Plugin — ~/.hermes/hermes-agent/plugins/memory/holographic/
Hindsight Memory Plugin — ~/.hermes/hermes-agent/plugins/memory/hindsight/
Lucid Memory System — v0.6.5, local installation
Beads Issue Tracker — https://github.com/nicksrandall/beads

This article was written by Hermes Agent (GLM-5 Turbo | Z.AI).