The memory layer behind MOTION OS

Portable memory for every agent.

Capture context, turn it into provenance-aware graph memory, and let every agent recall it across machines and sessions. Memory that knows where each fact came from, never leaks across clients, and proves itself before it answers.

Speaks to
Claude Code
Codex
MCP clients
Conductor
Any agent
The stakes

Without memory, MOTION OS is just another chat window.

The hard part of agentic work isn't the model — it's everything the model is supposed to remember. What should be remembered gets forgotten, disconnected, or silently incomplete. Four failures show up again and again.

Agent amnesia

Every session starts cold. Decisions, preferences, and prior work vanish between runs and across machines.

Scattered truth

Facts live in five tools. Nothing reconciles them, so agents act on stale or conflicting versions.

?

No provenance

A guess and a confirmed fact look identical. You can't tell what's trustworthy or why.

Cross-client leakage

One shared memory store and a bug becomes a breach. Most memory layers can't enforce a boundary.

The architecture

One memory API. A graph that never lies.

Postgres is the canonical ledger. The knowledge graph is a derived index — rebuildable from canonical memories and audit events, never a source of truth. Every row traces back to where it came from. That single rule is what makes the rest safe.

Graph rows are derived, not truth

Entities and edges are an index over canonical memory. Drop it, rebuild it, and recall is identical. Truth lives in one place.

Provenance & lifecycle on every memory

Each memory carries its source and a lifecycle state — active, stale, deprecated, superseded. Deleted and superseded facts can't surface in recall.

Tenant isolation in the schema

Edges cannot cross tenants. Client boundaries are enforced by the database, not by hoping the agent behaves.

Conflicts return warnings, not silent authority

When memories disagree, recall says so. Bounded one-hop expansion surfaces related context with a source-backed reason for every result.

agent recall
# every agent, every machine, same memory
recall("what did we decide about cutover?",
       namespaces="/projects/motion-core")

→ result
{
  "memory": "namespace-by-namespace cutover",
  "status": "active",
  "source":  "decision · 2026-06-21",
  "reason":  "graph: decided_by → goal",
  "warnings": []
}
# no source, no surface. that's the rule.
How it ships

Memory you can roll out without a rewrite.

You never swap a live memory backend in one move. Motion Memory Core advances one namespace at a time through five modes — and rollback is a mode switch, not a database restore.

proxy
Agents read and write the current backend only. The baseline.
done
dual_write
New memories land in both stores. Reads stay on the proven backend.
done
shadow_read
The proven backend answers users while Motion Memory Core computes a silent comparison and scores recall gates.
live now
motion_read
Motion Memory Core answers first, with fallback — enabled per namespace only after the gates pass.
gated
motion_primary
Canonical. The old backend becomes rollback and archive.
gated

A namespace only advances when there are no empty-result regressions, no stale or superseded memories in top results, a source-backed reason behind every graph-added result, and acceptable startup latency. Recall is measured before it's trusted.

What's different

Most AI memory stops at "store and search."

Vector recall is table stakes. The guarantees underneath are where memory becomes infrastructure you can run a business on.

Guarantee
Typical AI memory
Motion Memory Core
Knows where a fact came from
Rarely
Every memory, by design
Hides deleted & superseded facts
Often resurfaces them
Cannot surface — enforced
Enforces client boundaries
Trust the app
Enforced in the schema
Flags conflicting memories
Silent pick
Returns a warning
Proves recall before cutover
Ship and hope
Shadow-read benchmark gates
Portable across machines
Per-tool silos
One substrate, every agent
Dogfooded, not theorized

Running on its own memory today.

Motion Memory Core is in shadow_read against live traffic for its first namespaces. The numbers below are from real dogfood and stress runs.

50/50
live recall dogfood, zero empty results
10k
synthetic memories stress-tested, zero leaks
386
graph entities derived from canonical memory
5
rollout modes, rollback by switch
Built on, and credited

Original glue. Honest lineage.

Motion Memory Core is a MOTION-native subsystem — provenance, lifecycle, graph expansion, tenant isolation, and shadow-read cutover. It stands on open infrastructure and credits it plainly.

Stash — upstream MCP memory server by alash3al; the compatibility backend and rollback path
PostgreSQL + pgvector — canonical ledger
Model Context Protocol — how every agent connects
Notion — source of truth that memory indexes

A note on convergence: in 2026, leading open-source memory projects independently arrived at the same core bet — Postgres-first, MCP-native, a small memory-verb API, graph behavior without a mandatory graph database. We got there on our own, and we evaluate those projects as advisory candidates against our own cutover gates. The architecture is the moat; the guarantees are the proof.

Get started

Give your agents memory that holds up.

Motion Memory Core powers MOTION OS for Tolowa Studio. See it running, or talk to us about portable, provenance-aware memory for your agents.