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.
StashLibrary
Holds the full documents the memory points to.
NotionCloner
Every laptop set up identically — same skills, same config.
chezmoiBrain stem
All machines remember the same things at once.
RailwayKey cabinet
API keys available on demand — never lying around.
GCPArchitecture
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
Memory index
Stash
The index. Distilled conclusions.
38 namespaces · 1,200+ memories.
Source of truth
Notion
Full documents. Project hubs, playbooks, specs.
AI Router → page IDs
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.
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.Stash — Semantic recall — distilled facts
- 2.Notion AI Router — Page / database IDs only
- 3.Notion pages — Surgical fetch of the one page needed
- 4.Heavy doc storage — Last 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.
Sit down at any Mac
chezmoi already made them identical — same skills, MCP connections, agent config. No setup required.
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.
Need a document? One hop.
Stash hands over the exact Notion page ID. The agent fetches that one page surgically — no searching, no crawling.
Run the playbook
MOTION OS decides which layer the problem lives in. Trained, sequenced skills run the right procedure in order.
Credentials on demand
The Credential Probe Protocol pulls from GCP Secret Manager. Never pasted into chat.
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
stdiomcpServers 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
stdioIdentical 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
stdioTOML 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 URLSettings → 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
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.