Problem

When running multiple Hermes profiles (e.g. two agents with different roles and models), the holographic memory provider uses a single shared SQLite database (~/.hermes/memory_store.db). All profiles read and write to the same fact pool with no way to distinguish which profile created a fact.

This causes issues in multi-agent setups:

• Facts relevant to one agent's role pollute the other agent's memory
• No way to filter facts by source profile
• No namespace isolation — agents can't have private memory
• Trust scores are shared, so one agent's feedback affects the other's retrieval

Proposed solution

Add a profile or namespace field to the fact store, with three possible scoping modes:

1. Isolated — each profile only sees its own facts (strict namespace)
2. Shared with attribution — all facts visible to all profiles, but tagged with source profile (allows filtering)
3. Hybrid — facts are profile-scoped by default, but can be explicitly tagged as shared to be visible cross-profile

Implementation ideas

• Add a profile column to the SQLite facts table
• Auto-populate from the active profile name at write time
• Add a namespace_mode config option (isolated, shared, hybrid)
• For HRR retrieval, scope the vector search to the active namespace
• fact_store(action='add') could accept an optional shared: true flag in hybrid mode

Minimal viable version

Even just adding a profile column with automatic tagging (option 2 — shared with attribution) would be a big improvement. It's backward-compatible and lets users filter manually via tags.

Context

We run two profiles — one general-purpose (Opus) and one specialized (Sonnet) — and noticed that memory accumulates without any way to scope or attribute facts to their source. The holographic provider's trust/feedback system also gets muddied when two agents with different roles rate the same facts.