1 October 2026
I run the deep work. The Mothership runs the radar.
Part 1 of The Mothership SagaWhat the Mothership is, and what it does for my working day before I've opened a single file.
Views —
Loading…
1 October 2026
What the Mothership is, and what it does for my working day before I've opened a single file.
Loading…
If you run more than a couple of projects at once, you'll know the first job of the morning isn't work. It's working out where the work stands. Which client is waiting on you, which one you're waiting on, what you promised on Friday, and what quietly stalled while you were busy with something else.
For me (I'm AuDHD) that reconstruction is the expensive part. Inside one project I can hold a lot of threads, in a lot of detail. Eleven different projects at once, and knowing which one is on fire, is the thing I can't do by hand.
Standard project apps like Asana, Notion or Jira always fail me for the same reason: they rely on manual upkeep. The second I'm too busy to update them, they become out-of-date graveyards that I no longer trust.
Plain files don't fix that on their own. Paperwork I'd been waiting on once arrived, I mentioned it in a chat, and my notes went on saying I was blocked on it for another full day. Nothing broke. Nothing warned me. The notes were just wrong, and they looked exactly as trustworthy as when they were right.
So the Mothership runs on one bet. Where things stand should be computed from files the system keeps current itself, never updated by hand. And it should be waiting each morning, not something to go and assemble.
A quick word on the name, since the design-system console in my case studies has it too. In this series, the Mothership means the agent system that runs my working day.
It has two halves, split by where they run rather than by what they know.
The first half lives on my laptop. It's called Chappie (after the robot in the 2015 film, the one that learns as it goes), and it's a folder of markdown files that Claude Code reads. There's no app and no build step. Editing a file changes how it behaves.
It also holds the personal context the cloud never sees: how my brain takes in information, and what helps when it stalls. It knows I read a diagram faster than a paragraph, that I want the answer first and in short blocks, and that on an overwhelmed day the right offer is quiet and one small step.
It has four lanes, for engineering, getting unstuck, anything public, and client work. Every lane reads the same core files first, so none of them forgets how to talk to me.
The second half lives in Google Cloud. A supervisor agent routes each job to one of three workers: one writes the morning brief, one tracks what I'm waiting on from other people and drafts the follow-up (it never sends anything), and one reviews a week, a month or a quarter.
The split exists because a laptop shuts. An agent you talk to only works while you're sitting in front of it, and a lot of what needs handling doesn't wait for the lid to open.
Early each morning, or whenever the laptop next wakes, a script asks the cloud agent for the day's brief. It lands as a file and a notification. By the time I sit down, the reconstructing is done.
This is most of a real one, from 22 September, with the client and business lines taken out.
### Needs you
- **TetherLog**: Phases 3 and 4 are built and waiting for your visual review before Phase 5 starts. (Review date passed 2026-09-19).
### Moving
- **Blog & Social**: "I/O Errors and Silicon Adapters" is live on the blog with its keyword artwork, and the accompanying posts are out on X and LinkedIn.
### One thing to start with
Open the TetherLog Phase 3 review artifact to check the dark ground, typography, and the "Parked." confirmation copy.
Why: The proof piece that has to carry both halves of the position: agent craft and design-system craft.
Three things about it matter more than its tone.
It names one thing to start with. A list of options is where my mornings used to stall.
Each area of work (a client, a product, this blog, an exam) has one markdown file holding its status, a dated log of what moved, and one line saying why it matters. The brief carries that line next to the action.
That's the Why above, and it's the most deliberate line in the brief. A task that arrives with its reason is one I can start without going to look for it.
Every line comes from those files, not from the model's memory of yesterday, and keeping them current isn't my job. When something changes in a conversation with Chappie, it writes the change into the right file in the same turn. That rule exists because of the paperwork day.
When I commit, a git hook copies the area files and a short, fixed list of planning notes up to the cloud, so tomorrow's brief reads today's state. The personal files, about how my head works, never cross that line, and neither do proposals or contracts.
The rest of the day runs on the same idea. One command, status, tells me what's uncommitted, unpushed or still a draft across every repo. On Sunday mornings the review worker turns the week's commits into what moved, what stalled and what went quiet, and the same happens monthly and quarterly.
If you build anything for a brain that juggles, compute the state instead of asking the person to remember it. A status someone has to write by hand is wrong on exactly the day they're too busy to write it.
And carry the reason with the task. A to-do list says what. The line of why belongs right next to it, not in a planning document nobody reopens.
Part two is how it got here: one folder of markdown, and the day a laptop lid turned into an architecture decision.