hermes - 💡(How to fix) Fix [Feature Request] Project-scoped memory pools (global + per-project) [1 participants]

Feature Request: Project-Scoped Memory Pools

Problem

Hermes currently has a single global short-term memory pool that is injected into every session regardless of context. Users working on multiple projects end up with a mixed bag of facts -- infrastructure details, deployment rules, project-specific terminology, and personal preferences -- all competing for the same 2,200-character limit.

This leads to:

• Context pollution: A session about Project A gets injected with facts about Project B, C, and D
• Premature pruning: Users must delete still-relevant facts to make room for the current project's context
• No isolation: There is no way to say "these facts only matter when I am in a specific project directory"

Proposed Solution: Two-Pool Memory System

Split short-term memory into two distinct pools:

1. Global Memory Pool (existing behavior)

• Always injected into every session
• Intended for: user preferences, communication style, infrastructure facts, security rules
• Current behavior, just renamed/clarified

2. Project Memory Pool (new)

• Only injected when the session's workdir (or explicit --project flag) matches a registered project path
• Intended for: project-specific deployment rules, file paths, conventions, deadlines
• Stored per-project, e.g.:
  • ~/.hermes/memory/projects/project-a.json
  • ~/.hermes/memory/projects/project-b.json

Configuration

memory:
  global_max_chars: 1500      # global pool limit
  project_max_chars: 2500     # per-project pool limit
  auto_detect_projects: true  # scan workdir for .hermes-project marker

Auto-Detection Mechanism

When auto_detect_projects: true, Hermes checks on session start:

1. Is there a .hermes-project file in workdir or any parent directory?
2. If yes, load the project memory pool associated with that marker
3. If no, only load the global pool

.hermes-project marker file (optional, JSON):

{
  "name": "my-project",
  "memory_file": "my-project.json"
}

If the marker is absent but workdir matches a known project path from memory.projects.*, load that pool anyway.

CLI / Tool Interface

# Global memory (existing)
memory(action="add", target="memory", content="...")
memory(action="remove", target="memory", old_text="...")

# Project memory (new)
memory(action="add", target="project", content="...")
memory(action="remove", target="project", old_text="...")
memory(action="list", target="project")  # shows current project's memory

When inside a project context, target="project" is the default for add/remove.

Session Display

MEMORY (global) [40% -- 882/2,200 chars]
...

PROJECT MEMORY: my-project [35% -- 875/2,500 chars]
...

Benefits

1. Isolation: Project facts never leak into unrelated sessions
2. Scale: Each project gets its own budget instead of fighting for global space
3. Discoverability: New sessions in a project directory automatically get relevant context
4. Backward compatibility: Global memory works exactly as before; project memory is opt-in

Related

• Complements #16831 (configurable memory limit) -- both address the same underlying scarcity problem
• Honcho already handles long-term cross-project memory; this proposal fills the gap for short-term, project-local context