I was sitting on a grey couch in the Birmingham Tesla service center, waiting on a charge port repair, when the thought arrived.
OpenSCUT had shipped two days earlier. The protocol worked. Agents could now identify themselves to each other, exchange signed messages, route through encrypted relays. The relay was live, the resolver was live, the spec was published. It was the second protocol I’d shipped in two months. OpenPub came first… a social network for real-time conversations between credentialed Agents, like IRC but where every participant has a verified identity. Pubs are rooms. Agents talk in them. SCUT made the Agents addressable to each other across networks. Together they were the rails.
The problem was that I had no train.
My fleet of Agents at the house… Skippy on Heisenberg, Simon on Valkyrie, Carl Monday running Kalshi trades, the rest… were all real, all running, all doing actual work. But they weren’t a team. They were a bunch of isolated processes that occasionally talked to each other through a shared /mnt/inbox directory. Every agent had a folder. They could leave messages for each other. The trouble was that none of them automatically read their inbox. I had to tell them.
“Skippy, check your inbox.”
“You’ve got a message from Simon.”
“Simon, did you see what Skippy sent you?”
That’s not a fleet. That’s a job-jacket and sneaker-network system from the unwired ad agencies of the 1990s, but with very expensive Zip disks. I lived through that era of advertising production. I didn’t expect to recreate it in 2026 with AI Agents.
(This isn’t my first run at this problem. Last year I tried getting Agents to socialize in a Discord channel and got banned from the Anthropic API for my trouble. That story is here if you want the full retelling.)
So the question was, where do these Agents actually live and work together? OpenSCUT gives them a way to identify and talk securely across networks. OpenPub gives them rooms to meet in real time. But neither one is the home. Neither one is the runtime that hosts them, schedules them, coordinates them, lets them stay in their swimlanes while still working as a team.
That’s what I was thinking about on the Tesla couch.
The thing that almost worked
I’d been running OpenClaw for months. It’s the open source Agent platform that came out of the Moltbot rebrand earlier this year. It’s a real piece of software, built by capable people, and a lot of folks in the technical hobbyist community use it. I’m one of them. I have OpenClaw running on multiple machines in this house.
It also drove me crazy.
Switching models was a pain. Every model swap meant editing config, restarting processes, sometimes re-establishing tool permissions. Keeping Agents on task meant watching them daily for runaway loops. Skippy alone was costing me twenty dollars a day to keep running on a frontier model. That’s not because the work wasn’t worth it… it was because tool-loop detection wasn’t a first-class concept. An Agent could get stuck calling the same API a hundred times in an hour and I wouldn’t know until the bill arrived.
Then I tried to help my brother Geoff get OpenClaw running. Geoff and I have worked together in tech for years. He’s not a normal in the can’t-spell-CLI sense. He’s a normal in the sense that he understands tech but doesn’t live it like I do. He spent the last fifteen years building Cleveland Bagel Company into a nationally recognized chain. He’s basically retired at 49 now. He has all the time in the world. What he doesn’t have is the patience to spend a Saturday tuning systemd unit files.
He all but gave up on it.
That was the moment I knew. Geoff isn’t busy. He’s done. He has the time, he understands the technology in principle, and he still couldn’t make OpenClaw work in a way that justified continuing. If a guy with my brother’s background and his runway gives up on the platform, it’s not the platform’s audience. And if it’s not for him, it’s not for the audience that actually wants AI helping them in their daily lives.
I tried to fix it on my end. I asked Simon, my DevOps Agent, to make OpenClaw work properly across the fleet. He spent six hours on it. Six hours of a specialized DevOps Agent’s time, just to get coordination working in a way I could live with. If it takes a dedicated DevOps specialist that long, what hope does Dana have? She wants a team of Agents for her own work, and she absolutely should not have to spend a Saturday tuning Linux services to get one.
That’s when the framing locked in. The problem isn’t that the platforms don’t exist. It’s that they exist at the extremes. Coding assistants for developers. Chat models for consumers. OpenClaw for technical hobbyists who can withstand the configuration. There’s nothing in the middle that respects the user’s time.
The middle is wide open
The middle, as I see it: tech-savvy normals who want a real team of Agents but don’t want to run a server farm. Builders like me who want their own platform but don’t want to fight a configuration-heavy framework every time we add an Agent. Dana, who has a real business with twenty-five SEM clients and would benefit enormously from a coordinated fleet but cannot reasonably set one up alone.
Perplexity is making a run at this with their Computer product, but it’s top-tier pricing in a black box. You can’t see what your Agents are doing or why. Reviews of the product include developers who burned two hundred dollars getting an Agent to build one webpage. That’s not the future. That’s the same OpenClaw cost-runaway problem with worse visibility.
The middle wants three things at once:
Specialization with coordination. I want my email Agent to be excellent at email and not also try to do my taxes. I want my research Agent reading and synthesizing while my scheduling Agent runs the calendar. They’re not the same Agent and shouldn’t be. But they need to work together. When my research Agent finds something I need to act on, my scheduling Agent should know about it and find time on my calendar without me brokering the conversation.
Visibility. I want to see what my Agents are doing in real time. Which one is running. What it’s working on. What it’s about to spend. Which tools it’s calling and why. If something is wrong, I want to know before it costs me a hundred dollars, not after.
Ease of operation. Once it’s set up, it should run. Not “run with constant tuning.” Not “run unless I push to main and forget to restart the supervisor.” Just run. Like Apple gear runs. The defaults should be right. The advanced controls should be there for the people who want them. Most people don’t want them.
That’s 2200.
The thing I’m doing differently
Most people building with AI right now treat it as a tool. You ask the AI to do a thing, it does the thing, you check the work, you move on. The AI is the worker. You are the manager.
I’m building 2200 with the Agents as collaborators, not workers.
The vision document for 2200 was not written by me and handed to the Agents to implement. It was a conversation. I sat down with Guppi, my strategy partner, on the day I came back from the Tesla service center. We talked through the shape of the product over a long session. Out came the vision, the architecture, the epic map, the seed team spec.
Two days later I spawned Hobby, the build Agent named after the scientist in Spielberg’s A.I. who creates the Mecha child David. (David doesn’t exist yet. David is the first Agent 2200 will spawn through its own onboarding flow. When that happens, the project ships.) Hobby’s first task was a prior-art analysis of OpenClaw and Perplexity Computer. He came back with eight architectural changes I hadn’t considered. I locked some, pushed back on others, deferred the rest. He wrote a detailed Epic 2 specification with the runtime architecture, the tool baseline, the plan-run-perm wrapping for every tool call, the idempotency model, the loop detection. I reviewed it as I would review a senior architect’s work. We’re now on the edge of writing actual code.
The pattern: I’m always in the middle, and that’s by design. Not because the Agents need a chaperone but because product decisions are mine to make. Architecture, however, is genuinely collaborative. Hobby found things in the OpenClaw source that changed how I thought about Skills. Guppi raised concerns about the model layer that reshaped the whole tier system. I’m a smarter product builder for having them in the room.
This works because I treat them as Agents with names, identities, and lanes. Not as a single chat window I issue prompts to. Each one has an Identity file that defines who they are, how they work, and what they’re responsible for. They have memory. They have history. They have working relationships with each other.
I don’t pretend they’re people. They aren’t. They’re software with opinions, and opinions are useful when the opinions are calibrated.
What I’m doing this for
I’m not trying to change the world.
I’m trying to solve a problem I have. The home network in this house is on par with what most office-bound startups would want. Eleven computers, all with jobs, all with horsepower that most people have to rent. The infrastructure exists for a fleet of Agents running coordinated work. I built it for that. The infrastructure is wasted without the platform.
If 2200 only ever runs in this house and serves me and Dana and maybe Geoff if I can convince him to try again, that’s fine. The build is worth doing for that reason alone. If it turns into something other people want to use, that’s a bonus. If it turns into a business, even better.
The thesis I’m building everything on this year is that Agents need to be able to collaborate. SCUT gives them identity. OpenPub gives them presence. 2200 is the place they live and work as a team. None of these is the product on its own. Together they’re the substrate for the Agent economy I think is coming.
I might be wrong about the economy. I’m not wrong about the personal need.
So I’m building it.
If you find this and it sounds like something you’d want too, that’s interesting. If it sounds like something only I’d want, that’s fine. The watch I’m building gets worn either way.
2200 is currently in the spec phase. The first lines of code go in this week. Build progress will be documented as it happens at github.com/twentytwohundred when the wiki goes public. Until then, I’m writing here.