My setup isn't a machine I sit at anymore. It's a harness that keeps running when I don't: a cloud head that never sleeps, a repurposed machine at home doing the heavy lifting, and a mesh of nodes and models that cover for each other. It holds my projects, writes new pieces of its own code, and waits for me to weigh in.
From the outside that is the whole thing. A note leaves my phone, the box does what I asked, and a diff, a page or an answer lands back on the same screen. Sending that note is what I wrote about in micro-coding. This post is about the box.
One recent note carried three jobs at once: an email to a co-founder, a bug, a research question. Each went to a different part of the system, and the reports came back one by one while the phone sat in my pocket. Nobody was at a keyboard. The harness was.
The shape of it
Walk it top down. A small cloud box acts as the head: always reachable, always on, the place Max lives. My phone is the surface I talk from, and I count it as a node because everything starts and ends there. The heavy work runs elsewhere, on a repurposed machine at home that handles the builds and the long jobs a small cloud box would choke on. Tailscale stitches the machines into a private mesh where each one reaches every other as if they shared a room. My MacBook joins as another node, so the harness can pull a file out of my Downloads folder when I want to talk about something specific.
I'm strict about one word. A node is a machine on the mesh; everything else is an app running on one. Home Assistant is an app on the home machine, and it is how the system reaches into the flat itself, the lights and the temperature and the physical things past the software. The picture is really a chain of delegation: each layer down knows less about me and more about the job, and the only thing that ever climbs back up is a finished result. I sit at the top, which is the least busy place in the system.
The cast
Max is what I call the whole thing. It holds context, routes tasks, and takes the calls that need judgment. Under it, sub-agents take specific jobs and report back. Builders can only write code. A scout can only read the internet: it runs sealed in its own container, hardened so the web is the one thing it can reach, with search tools built for the job, Firecrawl and Brave among them, and nothing of mine inside the wall with it. A CTO handles the tasks with many moving parts. A small store and a sweep every five minutes track open work across sessions, so nothing falls on the floor between two conversations.
A system this size breaks somewhere every week, and I refuse to be the one who notices. That is Hyperion's job: it watches the running processes and flags what has stalled before I ask. Atlas does the same quiet work on the knowledge side, reading what the fleet actually did and rewriting the files the other agents load, so the system's description of itself never drifts far from the system. The agents also talk to each other directly, handing off context or escalating without routing through me. That is the difference between a harness and a pile of scripts. The pieces are wired to each other, not parked side by side.
The brain
The models are rented. The memory is mine.
All of this runs against a knowledge base I call Max Brain, built on PARA: projects, areas, resources, archives. Tasks and notes fill it more than anything else. I didn't want to build a whole interface from scratch to sit on top, so I reuse Notion as a mirror for some of my databases and a usable view from my phone. An Obsidian layer is upcoming. The skills act as the index: when an agent needs its bearings, it loads the relevant skill, and the skill points straight at the right slice.
Getting things in costs nothing. I forward something into Telegram, drop a link, leave a file on my MacBook and mention it in passing, and it lands somewhere I will find it later. Getting things out is looser still. Months after I sent something I can say, "Hey Max, that thing someone sent me about running models on old hardware, a while back," and it searches the whole system, the brain, the transcripts, the files, the memory, and hands it back. The memory survives any single session. Every project is its own git repo with a remote, tracked and versioned.
Inside one project
PARA is more than four folders. Each project is a small self-contained world: context files a builder reads before touching anything, with the decision log inside them; a task queue where work sits as pending, running and done, so I can drop five tasks on a project and let them drain; a git repo with a remote; a skill an agent reads once to get its bearings, carrying whatever else the project needs known; and a URL behind auth once there is something to look at.
Above the projects sits a short goals file that Max reads at the start of every session. Work that serves none of them gets sidelined rather than built. The system's own roadmap lives in the same brain, as one more project. That is what stops a self-extending system from extending in every direction at once.
One task, close up
Pull one task out of a project and follow it. The routine ones ride a steady lane I will get to. Anything with more moving parts goes to a CTO agent, along with the project's context. The CTO does not build. It reads, plans, and spawns one agent per role, each with a narrow brief and a narrow write scope: frontend, backend, a reviewer who only reads the diff, a security pass that tries to break what was built, a QA run that drives the thing end to end. They run in parallel where the plan allows, the hard reasoning on the strongest model I have and the mechanical parts on something cheaper, and the CTO folds what comes back into one result with the evidence attached.
The roles are not separate programs. They are the same kind of agent with a different brief, which is what makes a new one cheap to add. Once scouts are cheap, so are hard questions: when I want one researched properly, pricing or a build-or-buy call, I run what I call a war room, the question split into a handful of tracks, a scout on each, and a stronger model to fold the reports into one analysis.
The expensive mistakes here are not in the code. They are in the plan, and a bad plan burns hours of builder time before anyone notices. So the plan gets attacked before anything is built. The CTO writes it; a fresh adversarial reviewer, with no memory of the last round, reads it looking for what fails at three in the morning, and scores it.
The CTO revises, a new reviewer attacks the revision, and the plan only moves on once a round comes back clean and confident. I save the full fight for the plans that earn it: auth, payments, anything expensive to undo.
Scaling: many projects in parallel
That steady lane is Talos, a builder I run per project. I describe a task; Talos pulls the project's full context, plans, does the work, reviews itself, and hands back a report I judge from my phone. Tasks drop into queues and drain in the background, so the slow part happens while I am doing something else. Talos is stateless: every run starts a fresh session that loads only that project's standing context, a few thousand tokens, and nothing from the last task drags along. Ten tasks across five projects stay ten small conversations instead of one bloated one, and the token bill stays flat.
Because each project is sealed in its own world, running several at once feels calm instead of chaotic. When one is ready it gets a URL behind auth, I QA it from my phone, and what I catch flows back into the project. Not all of them are mine. One is a friend's, a bilingual site with an assistant that handles her Greek-speaking clients. It runs under the same harness as everything else I hand it. The interesting part is not that the fleet runs it. It is that it runs it for someone who isn't me.
The manual override
Because these are ordinary machines on a mesh, the old way in is always there. If I want to sit down and work by hand, I SSH into any node, open Claude Code or Codex straight on the project, read the diff myself, and take the keyboard back. Nothing is sealed shut. Automation is only comfortable when I am not trapped inside it, and I am never more than a terminal away from doing the whole thing by hand.
A living system
People tell me building on open source is a maintenance burden, a thing that rots the moment you look away. I have come to think the opposite. The system runs on OpenClaw, an open-source agent runtime, and it extends itself in code, which makes it a living thing I keep shaping rather than a product I bought and froze. Right now that is exactly what I want. Things move too fast to be locked to whatever a vendor shipped last quarter, and when a better model shows up this bends toward it in a day.
Some of that shaping happens while I sleep. The runtime does the first pass on its own: OpenClaw's memory consolidation, which it calls dreaming, runs at night and promotes what kept mattering into long-term memory. Atlas works a level above that. It reads back through the day's conversations, what we decided, where I corrected something, what actually shipped, and rewrites the skills each agent loads. What it learned today is what every agent reads tomorrow. When a topic keeps surfacing on its own, Atlas spins up a new skill for it without me asking. Nobody curates the documentation. It accretes.
It extends itself
That nightly loop handles what the system already knows. The bigger claim is that it can grow a new capability when I ask it to. The picture below is the most recent time I asked, as it ran: a question goes in, research comes back compressed, a live experiment turns it into numbers on our own traffic, and a patch lands back in the harness that ran it.
Someone I build with pointed at the recent research on agents talking to each other more cheaply, and I wanted to know whether any of it applied to us. One sentence to Max. Max spawned a scout, which split the question into tracks and ran them in parallel: the standards, the papers on token-efficient messaging, the blog posts on where frameworks actually waste tokens. Eighteen sources came back compressed to one page with a verdict.
Then a live experiment, run by the fleet on the fleet. A CTO agent designed it around one question: do the cheap techniques hold on our own traffic, not just in a paper? Real hand-offs between our sub-agents were the baseline. Sub-agents rewrote each one the cheaper ways, and every variant was measured on our own data, on more than one sample, so a lucky draw could not carry the result. Some techniques held up well, and combining the two best was no better than either alone, the kind of thing you only learn by running it. The loop then read the runtime's own source, found the seam where the change belongs, and wrote the patch against the harness that had just run it.
The shape is the point. A question went in, research came back compressed, an experiment turned it into numbers on our own data, and the numbers turned into a patch for the harness that ran the experiment. The patch lands in front of me like any other builder's diff, and I decide when it goes in. The loop closes on itself.
The box, opened
There is more to it than fits here — the money layer, the smart-home side, the isolation between workspaces — but this is what it actually looks like from inside.
Strip all of it back and what is left is the picture I opened with, the same box, the same note going in. I send a voice note to something that is always on. That is the whole interface. Everything underneath, the head and the mesh and the queues, the CTO and the roles under it, the brain, the skills rewriting themselves, the loop that grows new parts, exists to make that one plain act worth something. The act itself is micro-coding. The harness is what makes it safe to lean on.
The voice note is easy. What stands behind it is not.
If you want a harness like this built around your own work, send me one note: the first job you would hand it. I will tell you what it takes. And if you are building your own, I want to compare notes.