hermes - 💡(How to fix) Fix Feature request: memory-only profile isolation with shared runtime state

Feature description

Please add first-class support for project-scoped / profile-scoped memory isolation while sharing the rest of the Hermes runtime state.

The use case is: I want different projects to have separate long-term memory (MEMORY.md / USER.md, or equivalent memory provider namespace), but I do not want to maintain separate copies of config, API keys, skills, sessions, cron jobs, cache, logs, plugins, auth, etc.

In other words, I want something like:

default profile:
  config.yaml
  .env
  skills/
  sessions/
  cron/
  cache/
  logs/
  memories/        # default/general memory

ff14 profile:
  memories/        # project-specific memory only
  everything else shared with default

This is related to #4726, but slightly different: #4726 focuses on profile-scoped namespaces for a memory provider / fact store. This request is about a user-facing mode where only memory is project/profile-scoped and all other profile state remains shared.

Motivation

Long-running Hermes usage accumulates a lot of memory over time. For project-heavy users, the problem is not that sessions or skills are shared; those are usually acceptable or even desirable:

• Skills are not loaded every turn, so sharing them is fine.
• Sessions are only loaded via resume/search and are human-controllable.
• Cron jobs, cache, logs, auth, and config are often better shared to avoid duplicate maintenance.

The main token/cognitive-cost issue is long-term memory being injected into the prompt. Project-specific memory from one domain can waste context or bias answers in another domain.

Example:

• General coding / daily assistant memory should stay lightweight.
• A specialized FF14 / ACT / overlay tooling project has many durable facts: paths, ACT plugin constraints, game/tool directories, performance preferences, diagnostics rules, etc.
• Those FF14 facts are useful in that project but noisy in unrelated coding or daily-use sessions.

The ideal behavior is:

hermes
# Uses default/general memory

hermes -p ff14
# Uses FF14/project-specific memory
# But still shares config, .env, skills, sessions, cron, cache, logs, auth, etc.

Current workaround

I implemented this locally with symlinks, but this is fragile and may break if a future Hermes version changes profile layout, update/migration logic, or how files are written.

Current local structure:

C:/Users/yangg/AppData/Local/hermes/
├─ config.yaml
├─ .env
├─ skills/
├─ sessions/
├─ cron/
├─ logs/
├─ cache/
├─ state.db
└─ memories/
   ├─ MEMORY.md
   └─ USER.md

C:/Users/yangg/AppData/Local/hermes/profiles/ff14/
├─ memories/                         # only real profile-local directory
│  ├─ MEMORY.md
│  └─ USER.md
├─ config.yaml -> ../../config.yaml
├─ .env        -> ../../.env
├─ skills      -> ../../skills
├─ sessions    -> ../../sessions
├─ cron        -> ../../cron
├─ logs        -> ../../logs
├─ cache       -> ../../cache
├─ state.db    -> ../../state.db
└─ all other top-level entries symlinked to default

Verification from local setup:

non_link_except_memories = []

So profiles/ff14/memories is the only independent profile-local state; all other top-level profile entries point back to default.

This works for my current need, but it is not an official contract. It could be broken by:

• profile creation/update/migration rewriting symlinks as real files/directories
• hermes update or skill sync assuming full profile isolation
• Windows symlink behavior / permissions
• future profile layout changes
• atomic config writes replacing symlink paths unexpectedly

Proposed solution

Add an official profile/memory mode, for example:

profiles:
  ff14:
    inherit_from: default
    isolate:
      - memories

or:

memory:
  namespace: ff14
  namespace_mode: profile
profile:
  share_state_with: default
  isolate_paths:
    - memories

or a CLI command such as:

hermes profile create ff14 --memory-only --inherit default

Expected result:

• hermes -p ff14 uses ff14 memory namespace / memory directory.
• All non-memory paths resolve to default/shared state unless explicitly overridden.
• hermes config set, hermes skills update, hermes cron, etc. operate on shared state by default in this mode.
• Memory tool reads/writes only the active project's memory namespace.
• The behavior is documented and survives updates/migrations.

Acceptance criteria

A native solution would ideally support:

• Creating a profile/project with isolated memory only.
• Sharing config, .env, skills, sessions, cron, cache, logs, auth, plugins, and state DB with default or a selected base profile.
• Keeping MEMORY.md / USER.md or provider-specific memory namespace separate per project/profile.
• A clear CLI/status indicator showing which memory namespace is active and which base state is shared.
• Migration/update logic that preserves this mode.
• Windows support without relying on user-created symlinks.

Why this matters

This avoids long-term memory becoming too large or too domain-specific while keeping the rest of the Hermes experience simple.

For users with multiple projects, the desired mental model is:

Memory is project-specific.
Everything else can stay shared unless I opt out.

That keeps prompt memory focused without forcing users to maintain multiple full Hermes environments.