Feature request: optional external memory provider (MCP) behind the persistent/daily/discussion layers

Quick disclosure up front so this is not astroturf: I maintain Vestige, an open-source local-first memory server. I am not opening a PR. CONTRIBUTING asks to discuss first, and I can see 2.0 is still a Developer Preview with the new docs not ready, so this is just an interop idea to react to or park until the architecture settles.

Feature Use Case

I was reading ARCHITECTURE.md and core/context/LEON.md and the layered memory design really stood out: persistent for durable facts and preferences, daily for per-day summaries, discussion for recent working context, all mirrored into QMD collections, plus OWNER.md and the bounded self-model. That layering maps almost one to one onto how a dedicated memory engine models retention, which is why this jumped out at me.

Right now the memory subsystem is internal, so an owner who already runs their own local memory store cannot point Leon at it, and the self-model and daily summaries only ever live inside Leon. The use case I keep hitting: let an owner who runs their own local memory engine reuse it as the backing store for the persistent and daily layers, so recall and the self-model can draw on history Leon did not generate itself, while discussion context stays in-process.

Feature Proposal

An optional memory-provider seam behind the existing persistent and daily stores, defaulting to the current internal QMD path so nothing changes for anyone who does not opt in. A provider would implement write on durable and daily writes, and a recall call returning ranked snippets for the existing rerank and follow-up passes, leaving discussion context untouched.

One concrete reference could target Vestige over MCP, since Leon's agent mode already plans and executes tools. Vestige is a local-first cognitive memory MCP server: FSRS-6 retention, prediction-error gating, active forgetting, spreading activation, single Rust binary. Its persistent/short-term split lines up with your persistent and daily stores, and the forgetting curve could keep the daily layer from growing without bound, which I noticed is something the QMD mirroring has to manage manually.

Illustrative, opt-in, behind a flag:

// leon.config.json (illustrative)
{
  "memory": {
    "provider": "mcp",
    "mcp": {
      "server": "vestige-mcp-server",
      "layers": { "persistent": true, "daily": true, "discussion": false }
    }
  }
}

npm install -g vestige-mcp-server

If the seam is interesting I am happy to hash out the provider interface here first per CONTRIBUTING, and any implementation would target develop, pass pnpm run lint and npm test, and ship with tests. If the layered-memory internals are still moving for 2.0, I am just as happy to wait until you say it is stable. No rush, and not trying to replace your internal memory, just offering an optional adapter behind it.