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.

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

Skills

Your procedures travel — every agent knows how you work, not just what you know.

motion-skills

Control plane

Fleet orchestration, routing, and real-time observability.

MOTION Control

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.
Scoped namespaces · outcome-aware recall.

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. Primary transport: Streamable HTTP at /mcp (SSE kept for legacy clients).

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 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. 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. No re-explaining the durable context.

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 — the same skills on every agent and machine.

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 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 HTTP

Preferred: 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 HTTP

Remote 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 HTTP

Configure 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 URL

Settings → 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

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

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.

Want to build
your own?

Start with a Diagnostic