hermes - 💡(How to fix) Fix RFC: Evaluate Memvid as a Pluggable Single-File Memory Backend for Hermes

Summary

This issue proposes evaluating Memvid — a single-file AI memory system — as an optional pluggable memory backend for Hermes Agent. After a deep technical survey, Memvid's architecture appears to address several long-standing Hermes memory pain points while remaining compatible with resource-constrained deployments.

Hermes Memory Pain Points (Observed in Issues)

Root theme: Hermes' current memory system (text files + session_search) lacks structured indexing, semantic retrieval, and crash-safe persistence.

What is Memvid?

Memvid is a single-file AI memory layer (.mv2 format) written in Rust. It stores documents, indices, and a WAL in one append-only file — no sidecar files, no server process.

Key stats:

• ⭐ 15.4k stars, Apache-2.0 license
• 98.5% Rust, active development (last commit: 2026-05-06)
• Setup: 145ms (vs Pinecone 7.4s, ChromaDB 2min)
• Search latency: 24ms (vs Pinecone 267ms, LanceDB 506ms)
• Storage: 4.9 MB for 1,000 docs

Why Memvid Fits Hermes

1. Single-File Portability

hermes.mv2  ←  data + BM25 index + vector index + time index + WAL

• Copy, sync, git-commit friendly
• No .wal, .shm, .lock sidecars
• Crash recovery < 250ms via embedded WAL

2. Multi-Modal Search (Not Just Vectors)

3. Optional Embeddings = Zero-Cost Baseline

• Pure lexical search (--mode lex) requires no embedding model — works on 3.8G RAM servers
• Built-in BGE-small (384-dim, 75MB) for semantic search if desired
• Ollama local models supported for fully offline operation
• Product Quantization compresses vectors 16×

4. Unique Features Hermes Lacks

Time-Travel Queries:

memvid find knowledge.mv2 --query "config" --as-of-frame 100
memvid timeline knowledge.mv2 --since 2024-01-01

Entity State (O(1) Lookup):

memvid state memory.mv2 "Alice"
# → {employer: "Anthropic", role: "Senior Engineer"}

Memory Cards (Structured Knowledge):

{"entity": "John", "slot": "job_title", "value": "Senior Engineer", "kind": "fact"}

Adaptive Retrieval — auto-detects score cliffs instead of fixed top-k.

5. Resource-Friendly for Self-Hosted Setups

Proposed Integration Points

Option A: Memory Tool Backend (Minimal)

Replace memory tool's text-file backend with .mv2:

# Instead of appending to MEMORY.md
memvid put hermes.mv2 --text "User prefers concise responses"
# Retrieval
memvid find hermes.mv2 --query "user preference" --k 5

Option B: Session History Archive

Periodically archive session_search data into Memvid for:

• Semantic search across all past sessions
• Time-travel to specific conversation points
• Entity extraction ("What projects has this user worked on?")

Option C: Full RAG Layer (Ambitious)

Use Memvid as the retrieval backend for Hermes' context assembly:

• Hybrid BM25 + vector retrieval
• Entity-aware context injection
• Deduplication across sessions

Open Questions

1. Rust dependency: Memvid core is Rust. Hermes is Python/Node. Python SDK exists — is the FFI overhead acceptable?
2. Concurrency: Memvid uses file-level locking. How does this scale with Hermes' multi-turn async model?
3. Migration path: Can existing MEMORY.md / USER.md be imported into .mv2?
4. Cloud sync: Memvid Cloud (optional) vs Hermes' existing sync mechanisms.

Benchmark Data (Wikipedia 39K Docs)

Memvid achieves >90% accuracy with sub-20ms latency — a unique position in the accuracy-latency frontier.

References

• Memvid GitHub: https://github.com/memvid/memvid
• Documentation: https://docs.memvid.com/
• Architecture: https://docs.memvid.com/architecture/overview
• Benchmarks: https://docs.memvid.com/introduction/benchmarks
• Memory Cards: https://docs.memvid.com/concepts/memory-cards

Next Steps

Seeking maintainer/community feedback on:

1. Is a pluggable memory backend aligned with Hermes' roadmap?
2. Which integration option (A/B/C) is most viable?
3. Should we proceed with a proof-of-concept PR?

/cc @teknium1 and memory-system contributors — would love your take on whether this complements or conflicts with existing memory work.