Portable agent memory

TWO AXESAny MCP client, any LLM

Portability shows up on two independent axes. They compose: each pick on the top row works with each pick on the bottom row, because the model never speaks to IOBOXX directly — the MCP client mediates every call.

A Claude-driven agent in Claude Code and a Gemini-driven agent in a custom Python SDK can share the same per-twin memory. Their writes interleave on the deterministic commitlog with per-principal attribution — the Phase 5.6 principal model treats every agent as a first-class user, so reads scope per-principal and audit trails stay honest across multi-model workflows.

CONTRASTWhy the protocol boundary matters

The choice of which boundary memory binds to is the whole architectural question. Three common answers, three very different lock-in profiles:

Hosted memory services live above the protocol — in their own SDK. Vector-DB retrieval lives below the agent loop — tangled into the framework. IOBOXX lives at the MCP protocol itself, so the abstraction is the contract every participant already agrees on.

SURFACEWhat the MCP surface exposes

The IOBOXX MCP server exposes 24 tools across reads, writes, semantic queries, structural queries, and agent-curated handoff. A representative slice — chosen to show breadth, not as an exhaustive list:

• ping

  Liveness + auth-path probe.

• get_summary

  Hot-state digest for cold-start context.

• semantic_search

  Vector search across the per-twin embedding index.

• load_relevant_context

  Per-principal relevance-ordered rehydration.

• curate_memory

  Agent-curated keep/drop/add at session end.

• create_object

  Write a typed object into working memory.

• set_attributes

  EAV attribute writes against an existing object.

• traverse_references

  Walk the graph along typed reference edges.

The shape of the surface grew with what the agent actually needs: reads to read, writes to write, semantic queries when the right object isn’t known by name, structural queries when the graph topology matters, and a session-end curate_memory call so the agent can hand off only what was useful. Nothing in that list assumes a specific LLM.

REALWhat makes it real

Calling memory “portable” is cheap. The architectural commitments that make the claim load-bearing:

• Standard MCP transport

  Streamable HTTP and WebSocket — the same transport Anthropic specified. No vendor-specific extensions, no proprietary handshake, no out-of-band metadata. Any compliant MCP client connects without a custom shim.

• JWT auth, one trust boundary

  Keycloak is the IdP. The same ES256 token validates against SpacetimeDB SQL and against the MCP tower middleware. A token that works for one surface works for the other; there is no MCP-specific auth path to drift.

• No vendor-specific tool surface

  The 24 tools name graph operations, not model features. Nothing in the surface assumes a particular LLM, a particular embedding model, or a particular agent framework. The contract is the protocol.

• Sovereign per-twin instance

  Each tenant runs its own SpacetimeDB and its own object-store crate. Memory lives on the tenant’s infrastructure, not inside a model vendor’s cloud. Replace the model — the database does not move.

• AGPL-licensed core

  The engine is AGPL-3.0. Anyone can self-host. Anyone running it as a service for others must open-source their modifications. The protocol stays open; the implementation stays inspectable.

CLOSINGThe boundary is the abstraction

Every memory product picks a boundary. SDK-bound products own the developer experience but bet on a particular vendor surviving. Framework-bound products own the agent loop but inherit every churn cycle of that framework. The protocol boundary is the only one the whole agent ecosystem has already agreed on, and it’s the only one where “switch the model, keep the memory” is a property of the design rather than a marketing line. That’s why we picked MCP.