Architecture · MOTION Core

The Portable AI Brain.

A raw AI agent is like a brilliant assistant with amnesia every morning. Powerful — but you re-explain everything daily. This is the system that fixes the amnesia. Context, memory, and sync — so every agent already knows who I am, what I’m working on, and how I work before I type a word.

Most people paste context into the chat every time. Here the context lives in a system and the agent goes and gets it. This substrate is called MOTION Core internally. I’m teaching it as part of SoCLAI.

Five pieces

Fix the amnesia with five components.

Each one solves a distinct failure mode. Together they make the agent environment portable, durable, and consistent across machines and sessions.

Memory

Remembers the conclusions — not the whole conversation.

Stash

Library

Holds the full documents the memory points to.

Notion

Cloner

Every laptop set up identically — same skills, same config.

chezmoi

Brain stem

All machines remember the same things at once.

Railway

Key cabinet

API keys available on demand — never lying around.

GCP

Architecture

How the pieces connect.

The agent recalls from the index. The index points to the database. The database lives in the cloud so every machine shares it. The environment is identical everywhere. Credentials come from the vault.

Entry point

Claude
Codex · Cursor
Perplexity
recall

Memory index

Stash

The index. Distilled conclusions.
38 namespaces · 1,200+ memories.

recall()remember()
page ID

Source of truth

Notion

Full documents. Project hubs, playbooks, specs.

AI Router → page IDs

shared backend

Environment sync

chezmoi

Keeps every Mac’s config identical. Skills, MCP, shell.

Cross-machine sync

Railway · Postgres + pgvector

Shared backend for Stash. Write on one Mac, recall on another. stdio→SSE proxy bridges each desktop.

Credential vault

GCP Secret Manager

Credentials on demand. Never in chat or code.

Memory index
Cross-machine sync
Environment sync
Credential vault
Source of truth

Components

Each piece, explained.

The memory index

Stash

  • Open-source MCP memory server by alash3al.
  • Two verbs: recall (semantic retrieval) + remember (store durable facts).
  • Backed by Postgres 16 + pgvector.
  • ~38 namespaces · 1,200+ memories.
  • Stores distilled conclusions — not transcripts.

The source of truth

Notion

  • Holds full documents: project hubs, playbooks, specs.
  • An "AI Router" page stores canonical database IDs.
  • Stash facts embed Notion page IDs inline.
  • "I remember this" → "here's the full doc" is one hop.

Portable memory backend

Railway

  • Hosts the Postgres + pgvector instance Stash uses.
  • Shared backend — multiple machines read/write the same memory.
  • Each Mac connects via a small local stdio→SSE proxy.
  • Verified: write on one Mac, recall on another.

Identical machines

chezmoi

  • Manages dotfiles + config via a private Git repo.
  • Every Mac bootstraps to the same agent environment.
  • MCP server configs, skills, shell setup, CLAUDE.md — all synced.
  • Railway keeps memory identical. chezmoi keeps the environment identical.

The vault

GCP Secret Manager

  • Central credential store, namespaced per project.
  • Credential Probe Protocol: local env → GCP → tool stores → Keychain.
  • Secrets available to agents on demand.
  • Never pasted into prompts, memory, or code.

The key insight

An index is not a database.

Most people dump everything into one vector DB and hope semantic search finds it. It gets noisy fast. Memory becomes a junk drawer.

The split here is intentional: Stash is the index — distilled conclusions, small, clean, fast, semantic. Notion is the database — full documents, source of truth. Stash facts embed Notion page IDs inline, so the index points to content instead of holding it.

This is the same pattern a search engine uses over a content store. It’s what makes the system scale to dozens of projects without rotting.

Cheapest-first lookup order — stop at the first answer

  1. 1.StashSemantic recall — distilled facts
  2. 2.Notion AI RouterPage / database IDs only
  3. 3.Notion pagesSurgical fetch of the one page needed
  4. 4.Heavy doc storageLast resort — OneDrive, exports

A single session

From cold start to shipped, step by step.

Here is exactly what happens between sitting down and closing the laptop.

01

Sit down at any Mac

chezmoi already made them identical — same skills, MCP connections, agent config. No setup required.

02

Your agent recalls instantly

First thing it does — in Claude, Codex, Cursor, or Perplexity — is recall from Stash. Instantly knows identity, voice, active projects, and clients. Saves 4–8k tokens every session.

03

Need a document? One hop.

Stash hands over the exact Notion page ID. The agent fetches that one page surgically — no searching, no crawling.

04

Run the playbook

MOTION OS decides which layer the problem lives in. Trained, sequenced skills run the right procedure in order.

05

Credentials on demand

The Credential Probe Protocol pulls from GCP Secret Manager. Never pasted into chat.

06

Write back at the end

New decisions go back with remember → stored in Stash → synced through Railway to every machine. Tomorrow every agent already knows.

Any MCP client

Not just Claude. Any agent that speaks MCP.

Stash is an MCP server, so the brain isn’t tied to one app. Point any MCP-aware client at the same backend and it inherits the same memory. There are two wiring patterns — and hosting Stash on Railway is what unlocks the second.

Pattern A · local stdio

Desktop and CLI clients — Claude, Cursor, Codex — run the local stdio→SSE proxy, which bridges them to the Railway backend. Register the proxy as an MCP server; only the config format differs per client.

Pattern B · remote URL

Clients that accept a remote MCP connector — Perplexity (Pro/Max/Enterprise) — hit the Railway SSE endpoint directly. No proxy on the machine at all. This is the payoff for hosting the backend instead of running it locally.

Claude · Desktop + Code

stdio

mcpServers block in claude_desktop_config.json — or `claude mcp add` for Claude Code. The proxy script holds the SSE URL, so the client just points at the binary.

"mcpServers": {
  "stash": {
    "command": "/Users/you/.local/bin/stash-mcp-proxy",
    "args": []
  }
}

Cursor · IDE

stdio

Identical mcpServers shape in ~/.cursor/mcp.json — or .cursor/mcp.json scoped per project. Same proxy, same one line.

"mcpServers": {
  "stash": {
    "command": "/Users/you/.local/bin/stash-mcp-proxy",
    "args": []
  }
}

Codex · OpenAI CLI

stdio

TOML table in ~/.codex/config.toml — or `codex mcp add stash -- /Users/you/.local/bin/stash-mcp-proxy`.

[mcp_servers.stash]
command = "/Users/you/.local/bin/stash-mcp-proxy"

Perplexity · Pro / Max / Enterprise

remote URL

Settings → Connectors → add a custom MCP server. Point it straight at your hosted SSE endpoint — no local proxy on the machine at all.

Connector type:  Custom MCP (remote)
Server URL:      https://<your-gateway>.up.railway.app/sse
Auth header:     Authorization: Bearer <your-stash-token>

The stdio config is exact — the proxy (a tiny Python-stdlib script) holds the SSE URL, so the client just points at the binary. Only the remote-connector URL is a placeholder; swap in your own hosted endpoint.

One rule before you expose it

That endpoint is your whole memory — anyone who can reach it can read and write it. Keep the URL private and put authentication in front of the backend before you hand it to a remote client. A shared brain is only an asset while it’s yours alone.

Build your own

The architecture is useful. The kickoff is the gift.

This is the prompt I would hand to a serious AI agent to start rebuilding the pattern for someone else. It does not clone my exact system. It helps them design their own portable memory, source-of-truth, sync, and credential layer using the same operating principles.

What it should produce

  • A repo structure for the reference architecture
  • AGENTS.md and CLAUDE.md bootstrap protocols
  • MCP config templates for the agents they actually use
  • A memory namespace taxonomy
  • An AI Router template for canonical page and database IDs
  • A credential probe runbook that keeps secrets out of chat
  • A cross-machine setup checklist
  • A security checklist for hosted memory endpoints

Copy-paste starter prompt

Use with GPT-5.5, Claude Opus or Sonnet, Codex, Cursor, or any agent that can build.

You are my implementation architect for a portable AI memory and context system.

I want to build my own version of the MOTION Core pattern: a durable memory index, a canonical source-of-truth library, repeatable agent bootstrap instructions, cross-machine configuration sync, and a secure credential retrieval protocol.

Your job is to design and implement this for my environment, not merely explain it.

First, interview my current setup:
- Operating systems and machines I use
- AI clients I use: Claude, Codex, Cursor, ChatGPT, Perplexity, or others
- Whether each client supports MCP over stdio, SSE, or remote URL
- My source-of-truth tools: Notion, Obsidian, Google Drive, OneDrive, GitHub, local files, or others
- My preferred deployment platform: Railway, Fly.io, Render, Supabase, Neon, AWS, GCP, Azure, or local-only
- My credential store: GCP Secret Manager, 1Password, Doppler, AWS Secrets Manager, Keychain, env files, or another vault
- My dotfile/config sync tool: chezmoi, stow, Mackup, private Git repo, MDM, or manual setup

Then produce an implementation plan with these layers:

1. Memory index
- Pick or confirm a memory server such as Stash or an equivalent MCP memory service.
- Back it with Postgres plus vector search when possible.
- Define the two primary behaviors: recall for semantic retrieval and remember for durable conclusions.
- Store distilled facts, decisions, preferences, and pointers. Do not store raw chat transcripts.

2. Source-of-truth library
- Choose the canonical document system.
- Create an AI Router document that stores exact page IDs, database IDs, repo paths, and runbook locations.
- Make memory facts point to the full documents instead of duplicating them.
- Define the rule: memory is the index; the document system is the database.

3. Cheapest-first context lookup
- Define a lookup order that starts with the cheapest and fastest layer.
- Use this default order unless my tools require changes:
  1. Memory recall
  2. AI Router or index page
  3. One exact source-of-truth document
  4. Repo-local instructions such as AGENTS.md, CLAUDE.md, README.md, or docs
  5. Heavy storage or broad search only as a last resort
- Include a rule to stop once the answer is found.

4. Namespace taxonomy
- Propose namespaces for durable memory.
- Include at minimum:
  /self
  /self/preferences
  /self/capabilities
  /self/limits
  /tools
  /projects/<project-name>
  /clients/<client-name>
  /people/<person-name>
- Define what belongs in each namespace and what should never be stored.

5. Agent bootstrap protocol
- Write starter AGENTS.md and CLAUDE.md instructions.
- Include rules for session start, recall before advice, source-of-truth lookup, credential probing, and remembering durable decisions.
- Make the protocol portable across Claude, Codex, Cursor, and other coding agents.

6. MCP wiring
- Generate config examples for every AI client I use.
- Include stdio examples for desktop/CLI clients.
- Include SSE or remote URL examples where supported.
- If a local stdio-to-SSE proxy is needed, create the smallest maintainable proxy script and installation instructions.

7. Cross-machine sync
- Define how each machine gets the same agent config, MCP config, shell tools, skills, and bootstrap files.
- Prefer a private dotfiles repo managed by chezmoi if appropriate.
- Separate config sync from memory sync: dotfiles sync the environment; the hosted database syncs memory.

8. Credential hygiene
- Design a credential probe protocol.
- Use this order unless my environment requires changes:
  1. Local environment files and existing CLI auth
  2. Central secret manager
  3. Per-tool credential stores
  4. OS keychain
  5. Ask me only after all probes fail
- Never paste secrets into prompts, memory, docs, or code.
- Include setup for least-privilege service accounts where relevant.

9. Security and exposure
- Treat the memory endpoint as sensitive infrastructure.
- Explain how to protect any hosted memory server with authentication, network controls, or a private tunnel.
- Warn me before exposing a remote MCP endpoint to third-party clients.

10. Deliverables
Create the actual files I need, including:
- A repo structure
- AGENTS.md
- CLAUDE.md
- MCP config templates
- A memory namespace taxonomy
- An AI Router template
- A credential probe runbook
- A cross-machine setup checklist
- A security checklist
- Any proxy scripts or setup scripts needed

Work in phases. First give me the architecture choices and tradeoffs. Then ask for only the missing facts you truly need. After that, generate the implementation files and commands.

Credit where it’s due

I’m mostly assembling other people’s Legos.

Every component here is off-the-shelf. Stash, Notion, Railway, chezmoi, GCP Secret Manager — none of it is mine to claim. Stash is an open-source MCP memory server by alash3al — it’s the heart of this whole memory layer and deserves clear credit. Without it, the index doesn’t exist.

What’s mine is the composition: the index-vs-database split, the cheapest-first lookup discipline, the cross-machine sync wiring, the namespace taxonomy, and the credential hygiene that keeps keys out of prompts. The architecture is the value, not the parts.

The off-the-shelf stack

NotionSource of truth & AI Router
RailwayPostgres + pgvector hosting
chezmoiDotfile management
GCP Secret ManagerCredential vault

What’s next

Could this become its own repo?

You can’t repackage someone else’s product — Stash belongs to alash3al, Notion and Railway and GCP are SaaS. So this isn’t a product to ship. It’s a reference architecture: a documented, copyable pattern plus the glue that’s genuinely original work to share.

A public repo could be called MOTION Core — a reference architecture for portable AI memory. Not a fork, not a product. A blueprint. And it pairs naturally with teaching it as a module or course.

What the shareable glue would contain

  • The stdio→SSE proxy script for connecting desktops to a hosted Stash backend
  • CLAUDE.md conventions and templates
  • chezmoi dotfile templates for the agent environment
  • The namespace taxonomy for Stash
  • The Credential Probe Protocol as a documented runbook
  • The cheapest-first lookup-order spec
  • Setup guides that wire the off-the-shelf parts together

Forward-looking · not yet shipped

This is an intention, not an announcement. The architecture is running and proven. The question is whether to document it as a public blueprint others can rebuild themselves — crediting every upstream tool, sharing only original glue. That work is on the roadmap.

The Tolowa Studio thesis

Most people treat AI like a feature. I treat it like infrastructure — context, memory, and execution that compound over time.

Features get replaced. Infrastructure gets built on. This system is designed to grow, not reset — and to be identical no matter which desk I’m sitting at.

Want to build
your own?

Start with a Diagnostic