RFC: MemPalace ↔ MNEMOS interop — a memory-portability schema for desktop → team graduation

[perlowja]

Hi Mila and team,

I'm Jason Perlow (@perlowja), author of MNEMOS — a memory operating system for agentic AI, just open-sourced after being in daily production use since December 2025.

What this isn't: not a feature request, not a bug report, not a criticism. MNEMOS's README positions MemPalace and MNEMOS as "different problems, not competitors" — MemPalace is a desktop library for individual developers; MNEMOS is a network service for teams operating shared infrastructure. Full framing here.

What this is: a proposal for an optional portability seam between the two projects, so a MemPalace user who eventually needs team / production scale doesn't have to rebuild their memory from scratch.

Proposal, in one paragraph

A published JSON schema that both projects can read and write. MemPalace exports its drawers + palaces into this schema; MNEMOS imports it via POST /v1/memories/bulk (plus an optional POST /kg/triples pass for relationships, using our temporal triple store). Either a neutral memory-portability-schema repo or contributed to whichever project prefers to host it. No runtime dependency between the two codebases — we'd maintain a schema, not each other's code.

What I'll build

To make this concrete rather than speculative: I'll build and maintain the MemPalace → MNEMOS import utilities myself. Specifically:

• A command-line tool (Python, MIT-licensed or whatever works) that reads a MemPalace store in situ — drawers, palaces, metadata, the spatial structure where it's representable — and emits the shared portability JSON.
• A companion importer that feeds that JSON into a MNEMOS install via POST /v1/memories/bulk with relationships landed via POST /kg/triples.
• Tests against real MemPalace exports, with whatever sample data you're willing to share or what's in the public test fixtures.
• Long-term maintenance on the MNEMOS side of the seam — if MemPalace changes its internal shape, I track and adapt the importer.

The importer would ship as a MNEMOS subproject (so the MemPalace codebase doesn't need to carry MNEMOS-specific code), with a neutral repo for the shared schema if you'd prefer that to living in either project.

Why this is worth doing

1. User graduation path. A MemPalace install that grows into a multi-developer team today faces an awkward reset. A shared export shape fixes that without either project changing its core design.
2. Honest positioning. Both projects' "why not just use X?" answers become easier: "use both, here's the seam" — concrete rather than defensive.
3. Interop without entanglement. Low maintenance cost for you, high community value.

What I'm asking

1. Are you open to this direction in principle? A yes / no is enough to proceed or not.
2. If yes, would you prefer the schema to live as an RFC in your repo, a neutral third-party repo, or something else?
3. Any constraints I should know about — licensing, branding, already-planned interop work, MemPalace-internal structures you'd want me to avoid depending on — before I start the import tool?

MemPalace → MNEMOS is the natural direction of travel; I'd propose a schema that adapts toward MemPalace's existing drawer / palace structures rather than asking you to conform to ours. If the schema ends up imperfect because MemPalace's data model keeps evolving, that's my problem to manage on the importer side, not yours.

Either way: thanks for the LongMemEval work, the AAAK research, and the spatial-memory metaphor. MNEMOS borrows from all three conceptually, with attribution, and the README references this publicly.

— Jason / @perlowja