hermes - 💡(How to fix) Fix RFC: Multi-profile shared memory store with on-demand capsule recall

Summary

I'd like to gauge interest in upstreaming a multi-profile shared memory store that sits alongside (not replacing) Hermes's existing memory + FTS5 session search + Honcho integration.

The core idea: in multi-profile Hermes deployments, certain facts (user preferences, project conventions, hard rules) should be shared across all profiles, but each profile may also need its own private facts. Existing memory paths are session/profile-centric; this proposal adds a small SQLite-backed shared store + on-demand capsule retrieval so the stable prompt prefix doesn't grow monotonically.

I've been running this in production for ~10 days. It's an additive layer — existing memory code paths are unchanged.

Why

In a Hermes deployment with multiple profiles (e.g., advisor / executor / reviewer), I found three needs that the existing memory layer doesn't directly cover:

1. Shared facts across profiles — user preferences ("don't use emoji in commits") should apply to all profiles, but storing N copies in N profile memories is wasteful and drift-prone
2. On-demand recall (not prefix-loaded) — loading full memory into the stable prefix grows the prompt monotonically; sometimes I only need a 1–2 KB capsule for the current turn, and I want the rest to stay in storage
3. Cross-profile observability — when profile A learns something new, profile B should be able to retrieve it on its next turn without manual sync

Design sketch

.hermes/memory/
├── shared.db         ← cross-profile facts (SQLite + FTS5 + optional embedding)
├── profile_a.db      ← profile-private
├── profile_b.db
└── profile_c.db

An MCP tool is registered so profiles can:

• memory_search(query, scope='shared|self|all') — returns ranked facts as a ≤N KB capsule (tool-result, never prefix-loaded)
• memory_remember(fact, scope='shared|self', confidence=0.0-1.0)
• memory_forget(id)

Existing memory .md files remain the single source of truth — the SQLite is just an index / recall surface. Edits to .md re-sync the index on next read.

Optional layers (configurable, off by default):

• Embedding-based recall (any provider, e.g., a small sentence transformer)
• Cross-encoder reranking
• Entity-relation graph for explicit fact relationships

What this is NOT

• Not a replacement for Honcho-style dialectic user modeling — different layer (Honcho models who the user is; this stores what facts they've told you)
• Not a replacement for FTS5 session search — different granularity (this is fact-level, not conversation-level)
• Not a general RAG framework — just a flat fact store with optional embedding

Questions before I open anything

1. Roadmap conflict? Is there an existing plan for multi-profile shared memory that I should align with, or that already covers this use case?
2. Honcho boundary — is this layer redundant with Honcho's roadmap, or complementary?
3. Scope preference — if there's interest, would you prefer:
   • (a) a minimal demo PR (just the SQLite store + MCP tool registration, no embedding/reranking)
   • (b) the full version with optional embedding via a configurable provider
   • (c) keep it as a third-party extension and just document the integration point

Not opening a PR yet — purely gauging interest to avoid contributing the wrong shape. Related: I've also just opened #31385 (bridge) and #31387 (drift hook); happy to sequence these however you prefer.

Thanks!