The system behind the systems

How I Build

Everything on this site was built by a software company with one human employee — me — and I can't code.

The short version

I spent twenty years managing developers: writing specs, reviewing plans, making calls, holding people accountable for shipping. It turns out that's exactly the skill set for running AI agents. I didn't learn to program — I built an organization.

Fair warning: this system is very much a work in progress. But it's also, ultimately, the most durable thing I'm building — probably the thing I'll be proudest of — because it's the foundation everything else on this site gets built on, and everything I'll build in the coming years.

How the orchestration actually works

The core is a small fleet of AI agents with defined roles, the way a real team has defined roles: a strategist I think out loud with, an architect who reviews every plan and design before anything gets built, a coordinator who owns the project tracker and keeps the timeline honest, and an implementer who writes the actual code. Beneath those sit about two dozen specialist personas — accessibility auditor, API tester, backend architect — that get pulled in when a task calls for them.

Work moves through the system the way it moves through a company. Everything starts as a written spec in a standard format; the architect reviews it; the implementer builds against it; the tracker records what's in flight, what's decided, and what's blocked. The agents even brief their successors: when a session ends or runs out of memory, the system writes a handoff note so the next session starts knowing where things stand — because an agent with amnesia is just as dangerous as an employee who never reads their email.

And because a foundation is only as good as its failure plan, the whole thing backs itself up four different ways, every day, without me thinking about it.

None of this was invented in a vacuum. Open-source projects like NTM — a multi-agent orchestration tool that does much of what this system aspires to — served as a reference throughout; I borrowed patterns from it here and there rather than adopting it wholesale, because the point of this build is that the system fits how I work.

What makes it actually work

What's missing

Dedicated QA. Right now verification lives inside the build process, and that's not good enough — the implementer checking its own work has the same blind spots a human developer does. A standalone QA role, adversarial by design, is actively being added to the workflow. I'd rather tell you that than pretend the system is finished.

The pain points, honestly

Managing agents feels uncannily like managing people, with the same failure modes at higher speed. Work stalls silently if nobody owns follow-up — I once lost nearly two days of progress to a task that everyone assumed someone else was watching. Two builders will happily duplicate each other's work down to the byte if the tracker doesn't stop them. Instructions written in plain language get ignored under pressure, which is why every rule that actually matters is now enforced in code the system cannot skip, rather than in a prompt it might not honor. And the costs will surprise you: I've had to diagnose runaway token consumption the way an ops team diagnoses a memory leak — finding the hooks and scheduled jobs quietly burning budget in the background.

The difference from managing people: with agents, every management lesson can be turned into a system the moment you learn it. That's why this thing compounds.