Technical Reference · MOTION Core
The system behind the studio.
This is the technical architecture Tolowa uses to preserve context, coordinate specialized agents, secure client access, route work to the right models, and verify what gets built across projects and machines.
Buyers do not need to understand this page before working with Tolowa. It is published for operators, technical partners, and anyone evaluating the discipline behind the public promise: see your business and run it better. For the deep memory walkthrough — two tiers, Railway Stash, feedback loop, and private operator kit — see Memory Architecture.
MOTION Control Status
Status unknown
Could not fetch status — check back soon
Seven layers
Fix the amnesia with seven layers.
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.
GCPSkills
Your procedures travel — every agent knows how you work, not just what you know.
motion-skillsControl plane
Fleet orchestration, routing, and real-time observability.
MOTION ControlArchitecture
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.
Scoped namespaces · outcome-aware recall.
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. Primary transport: Streamable HTTP at /mcp (SSE kept for legacy clients).
Credential vault
GCP Secret Manager
Credentials on demand. Never in chat or code.
Components
Each piece, explained.
The memory subsystem
Motion Memory Core
- Two tiers: repo-local reviewable memory plus one Railway-hosted Stash shared across every MCP client.
- Engine: tolowa-studio/stash (Apache-2.0 fork of alash3al/stash). Private operator kit: memory-kit.
- Core verbs: recall + remember. Outcome-aware feedback adjusts retrieval utility only — not facts.
- Bounded, checkpointed consolidation. Postgres + pgvector. Distilled conclusions — not transcripts.
- Public walkthrough: tolowastudio.com/memory.
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 and clients read/write the same memory.
- Primary MCP transport: Streamable HTTP at /mcp. Legacy SSE remains for older clients.
- 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 capability layer
motion-skills
- The same operating skills — MOTION OS playbooks — on every agent and every machine.
- One canonical ~/.agents/skills store, read natively by Cursor.
- Adapters fan out to Claude Code and Codex; CMux, Conductor, and Nimbalyst inherit.
- Works with any agent harness. Synced across machines by chezmoi, exactly like memory and config.
The model router
Motion Router
- Classifies every task and routes it to the right model — automatically.
- Dispatches routine work through ClinePass: GLM for general work, Kimi for code, and DeepSeek or Qwen for reasoning.
- Sensitive or frontier work stays local — never auto-sent to the cloud.
- Every routed job logs tokens and provider-reported cost back to MOTION Control.
- Same routing on every agent and machine, regardless of harness.
The control plane
MOTION Control
- Fleet orchestration and observability — sees every layer, every project, every agent.
- Beacon: heart of the system. Emits one canonical health signal and publishes live status.
- Shows the savings — what Motion Router saved by routing to the right model.
- Dashboard: real-time layer health, job execution, performance metrics.
- Self-heals: requeues, restarts, and falls back automatically. Degrades gracefully under load.
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. No re-explaining the durable context.
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 — the same skills on every agent and machine.
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 Railway-hosted backend and it inherits the same memory. Streamable HTTP at /mcp is primary; legacy SSE remains available. Details and the private operator kit live on the Memory Architecture page.
Pattern A · Streamable HTTP (primary)
Cursor, Claude, Codex, and other modern MCP clients connect to the hosted /mcp endpoint with a scoped bearer token. No local memory engine required on the laptop.
Pattern B · Legacy SSE / local bridge
Older connectors can still use the Railway /sse endpoint, or a small local stdio bridge when a client cannot take a remote URL. Compatibility path — not the default.
Cursor · IDE
Streamable HTTPPreferred: point ~/.cursor/mcp.json (or a project .cursor/mcp.json) at the hosted /mcp endpoint with a bearer token. Reconnect after tool-schema updates.
"mcpServers": {
"stash": {
"url": "https://<your-host>/mcp",
"headers": {
"Authorization": "Bearer <scoped-token>"
}
}
}Claude · Desktop + Code
Streamable HTTPRemote MCP connector to the same /mcp URL when the client supports it. Older desktop setups may still use a local stdio bridge to the hosted service.
"mcpServers": {
"stash": {
"url": "https://<your-host>/mcp",
"headers": {
"Authorization": "Bearer <scoped-token>"
}
}
}Codex · OpenAI CLI
Streamable HTTPConfigure the MCP server against the hosted /mcp endpoint (or a local stdio bridge when the CLI cannot take a remote URL).
[mcp_servers.stash] url = "https://<your-host>/mcp" # Authorization header via your client's secret/env pattern
Perplexity · Pro / Max / Enterprise
remote URLSettings → Connectors → custom MCP. Prefer /mcp (Streamable HTTP). Legacy /sse remains available for older connectors.
Connector type: Custom MCP (remote) Server URL: https://<your-host>/mcp Auth header: Authorization: Bearer <scoped-token>
Hostnames and tokens stay private — use placeholders in docs and managed secrets in Railway/GCP. After a Stash tool-schema change, reconnect clients so they rediscover feedback and consolidation tools.
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 Streamable HTTP (/mcp), SSE (/sse), or stdio - 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). Prefer Streamable HTTP at /mcp; keep SSE only for legacy clients. - Back it with Postgres plus vector search when possible. - Define the primary behaviors: recall for semantic retrieval, remember for durable conclusions, and optional helpful/harmful/neutral feedback that adjusts retrieval utility only. - 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. - Prefer Streamable HTTP /mcp URL examples with bearer auth. - Include SSE /sse examples only where a client still requires them. - Include a local stdio bridge only when a client cannot take a remote URL. 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 setup scripts needed for local bridges or client reconnects 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 foundational component here is off-the-shelf. Notion, Railway, chezmoi, GCP Secret Manager — none of those are mine to claim. Stash started as an open-source MCP memory server by alash3al. Tolowa maintains a public engine fork at tolowa-studio/stash and a private operator kit at tolowa-studio/memory-kit. Upstream credit stays with alash3al; the composition and ops packaging are ours.
What’s mine is the composition: the index-vs-database split, the cheapest-first lookup discipline, the cross-machine sync wiring, the namespace taxonomy, the credential hygiene that keeps keys out of prompts, and the private operator distribution model. The architecture is the value, not the parts.
The off-the-shelf stack
Shipped · memory distribution
The blueprint is public. The ops kit is private.
As of 2026-07-18 this is no longer a roadmap tease. The public engine is tolowa-studio/stash (upstream credit still goes to alash3al). The human walkthrough is live at /memory. Client on-ramps, Railway runbooks, verification gates, and env-variable names live in the private memory-kit — intentionally secret-free.
Notion remains the visible library. Stash remains the index. Railway remains the shared Postgres + pgvector backend. Do not confuse this with the retired Motion Memory Graph experiment.
What is actually published
- Public engine repo: tolowa-studio/stash (pinned in memory-kit)
- Public page: tolowastudio.com/memory — two tiers, feedback loop, consolidation
- Private kit: client on-ramp, Railway ops, verification contract, env names only
- Transport contract: Streamable HTTP /mcp primary · SSE compatibility
- Providers: OpenRouter embeddings · Cloudflare Workers AI reasoning (operator pattern)
- Still private: hostnames, tokens, DSNs, namespaces, raw recall payloads
Canonical record
For the dated operator-facing writeup, see the Notion page Motion Memory Architecture — Canonical (2026-07-18). This /system page is the public technical tour; /memory is the deep memory walkthrough. If they disagree, trust the newer canonical record and fix the stale page.
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.