Multi-graph support: named, segregated memory graphs #1

New Issue

cal · 2026-02-28T04:50:34Z

cal commented

2026-02-28 04:50:34 +00:00

Summary

Support multiple isolated memory graphs from a single MCP server instance, each with its own directory and namespace.

Motivation

Currently cognitive memory is hardcoded to a single graph directory (~/.claude/memory/). This creates problems when different use cases need isolated memory:

Scheduled tasks (planned systemd timer + Claude CLI automation) need their own memory that won't pollute or be polluted by interactive session memories
Per-project memory (e.g., major-domo vs homelab docs vs paper-dynasty) would benefit from isolation
Orchestrator swarms could use a shared team memory graph scoped to a single task
Decay scoring doesn't make sense across contexts — a scheduled task's state shouldn't decay just because it wasn't referenced in an interactive session

Proposed Design

Named graphs via config

The MCP server accepts a graph configuration mapping names to directories:

{
  "default_graph": "~/.claude/memory/",
  "graphs": {
    "scheduled-tasks": "~/.claude/scheduled-tasks/memory/",
    "major-domo": "/mnt/NV2/Development/major-domo-v2/.memory/"
  }
}

Per-call graph selection

MCP operations (memory_store, memory_recall, memory_search, etc.) accept an optional graph parameter:

{
  "tool": "memory_store",
  "args": {
    "content": "Server health check passed",
    "tags": ["server-health"],
    "graph": "scheduled-tasks"
  }
}

When graph is omitted, the default_graph is used (backwards compatible).

Directory structure

Each named graph gets a full, independent memory directory:

CORE.md
REFLECTION.md
graph/ (solutions, decisions, fixes, configurations, episodes)
embeddings/

Considerations

Cross-graph search: Should memory_search optionally search across all graphs? Could be useful for cross-pollination but adds complexity. Maybe a graph: "*" or graph: "all" option.
MEMORY.md symlinks: Currently CORE.md auto-loads via MEMORY.md. Per-project graphs would need their own loading mechanism (likely via project CLAUDE.md pointing to the graph's CORE.md).
Decay isolation: Each graph should have independent decay scoring.
Graph discovery: A memory_graphs tool to list configured graphs and their stats.

Origin

This came out of planning a scheduled tasks system (systemd timers + claude -p) as an alternative to Claude cowork's scheduled tasks on unsupported platforms. Memory persistence across scheduled runs is essential, but it needs to be isolated from the interactive session graph.

## Summary Support multiple isolated memory graphs from a single MCP server instance, each with its own directory and namespace. ## Motivation Currently cognitive memory is hardcoded to a single graph directory (`~/.claude/memory/`). This creates problems when different use cases need isolated memory: - **Scheduled tasks** (planned systemd timer + Claude CLI automation) need their own memory that won't pollute or be polluted by interactive session memories - **Per-project memory** (e.g., major-domo vs homelab docs vs paper-dynasty) would benefit from isolation - **Orchestrator swarms** could use a shared team memory graph scoped to a single task - **Decay scoring** doesn't make sense across contexts — a scheduled task's state shouldn't decay just because it wasn't referenced in an interactive session ## Proposed Design ### Named graphs via config The MCP server accepts a graph configuration mapping names to directories: ```json { "default_graph": "~/.claude/memory/", "graphs": { "scheduled-tasks": "~/.claude/scheduled-tasks/memory/", "major-domo": "/mnt/NV2/Development/major-domo-v2/.memory/" } } ``` ### Per-call graph selection MCP operations (`memory_store`, `memory_recall`, `memory_search`, etc.) accept an optional `graph` parameter: ```json { "tool": "memory_store", "args": { "content": "Server health check passed", "tags": ["server-health"], "graph": "scheduled-tasks" } } ``` When `graph` is omitted, the `default_graph` is used (backwards compatible). ### Directory structure Each named graph gets a full, independent memory directory: - `CORE.md` - `REFLECTION.md` - `graph/` (solutions, decisions, fixes, configurations, episodes) - `embeddings/` ### Considerations - **Cross-graph search**: Should `memory_search` optionally search across all graphs? Could be useful for cross-pollination but adds complexity. Maybe a `graph: "*"` or `graph: "all"` option. - **MEMORY.md symlinks**: Currently CORE.md auto-loads via MEMORY.md. Per-project graphs would need their own loading mechanism (likely via project CLAUDE.md pointing to the graph's CORE.md). - **Decay isolation**: Each graph should have independent decay scoring. - **Graph discovery**: A `memory_graphs` tool to list configured graphs and their stats. ## Origin This came out of planning a scheduled tasks system (systemd timers + `claude -p`) as an alternative to Claude cowork's scheduled tasks on unsupported platforms. Memory persistence across scheduled runs is essential, but it needs to be isolated from the interactive session graph.

cal referenced this issue

2026-02-28 04:52:23 +00:00

Scheduled tasks system: systemd timers + Claude CLI as cowork alternative #2

Sign in to join this conversation.