Skip to content

RFC: Multi-Scope Memory — personal/global/shared scopes with scope-aware retrieval #20

@kenyonxu

Description

@kenyonxu

Motivation

Currently, SLM stores all memories in a flat namespace. When a user runs multiple AI agent profiles (e.g., a team of specialized agents), every agent sees every memory — no distinction between private memories and shared knowledge.

Our use case: a single human user managing multiple agent profiles. Each agent needs:

  • Personal memories (shaping agent personality & behavior)
  • Global memories (team-wide shared knowledge)
  • Point-to-point sharing (visibility between specific agents)

Approach

We implemented a three-tier scope system, tested in production on a fork:

Data Layer

  • scope column (personal / global) added to 8 core tables: memories, atomic_facts, canonical_entities, kg_nodes, graph_edges, memory_edges, temporal_events, audit_trail
  • shared_with JSON column for point-to-point visibility
  • Migration M014 handles existing data (defaults to personal)

Retrieval Layer

  • All 7 retrieval channels accept scope parameter with scope-aware SQL WHERE clauses
  • Multi-scope RRF fusion: personal=1.0, global=0.5, shared_with=0.7 (configurable in later commits)
  • Cross-agent global recall correctly filtered across all channels

External Interface

  • CLI: slm remember --scope global, slm remember --shared-with agent2
  • MCP tools: all store/recall tools accept scope and shared_with parameters
  • Daemon & WorkerPool IPC propagate scope

Current State

  • Fully implemented and tested on our fork (~11,000 LOC delta, ~2,000 new test LOC)
  • Cleanly merged with upstream v3.4.39, zero conflicts
  • Running in production for daily Hermes agent team usage
  • Backward compatible: all memories default to personal scope

Questions Before I Polish for PR

I'd like to check interest before spending time rebasing and splitting commits:

  1. Is this direction interesting to upstream? Is multi-scope memory anywhere on your roadmap?
  2. If a PR is welcome, what granularity do you prefer? E.g.:
    • A) One comprehensive PR (schema + engine + retrieval + CLI + MCP)
    • B) Split into 3 incremental PRs (schema layer → retrieval layer → external interface)
  3. Regarding Phase 2 & 3 directions (skill-domain tags, global entity resolution), is there overlap or different design preferences?

Totally understand if the timing isn't right or you have your own plans. Happy to keep maintaining on the fork.

Thanks for building SLM — it's a fantastic project!


Note: We followed existing architecture patterns (no breaking changes), full backward compatibility (defaults to personal), and matched the project's test style.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions