How I Run a Company of AI Agents as a Solo Frontend Lead
I'm a frontend team lead, and most of the code I shipped in the last couple of months was written by a company I built rather than typed by me. A director agent sets strategy. Team leads take directives and break them into tasks. Worker agents write the code, run the tests, and open the merges. There's a budget, an incident log, and a registry of every idea we've ever had, with status computed from files on disk so nobody can fake "done."
This is a tour of the AI agent orchestration behind that: the design decisions that mattered, the ones that didn't, and the incidents that forced most of them. Not a framework pitch, I don't sell one. These are operating notes from running autonomous AI agents in production as one person, written for the version of me from three months ago who was about to learn all of it the slow way.
AI agent orchestration is an org chart, not a bigger prompt
Everyone starts in the same place. An agent fails, so you add to the prompt. A rule. An example. A paragraph that begins "IMPORTANT: always..." A month later you have a 2,000-word instruction blob that one agent reads, half-follows, and forgets by step three.
Structure beats a bigger prompt. Every time.
What fixed my failure rate wasn't better wording. It was separation of concerns, the same discipline you'd apply to a codebase, applied one level up. The agent that plans doesn't write. The agent that writes doesn't decide what's worth building. The agent that checks the work has no incentive to call it done. Each role gets one job and a boss.
A tool is something you operate: you aim it, you fire it, you put it down, and the intelligence in the loop is you. That stops scaling the moment the work is bigger than one head. The whole game of orchestrating agents is turning "a model I operate" into "a workforce I direct."
We've spent two years asking how to talk to one model. The better question is how to organize several.
The structure: one director, a layer of leads, workers on demand
Concretely: I talk to the director. The director dispatches to team leads, up to ten of them. Each lead takes one directive, breaks it into tasks, and spins up its own squad of workers: an architect for the spec, coders for the tasks, QA to verify. When the task is done, the squad shuts down. No idle office, no standing headcount. Agents exist for exactly as long as there is work.
I supervise none of the workers directly, and that's the point. For twenty years my throughput was capped by a number I never named: one. One thing in my head, one review in focus. The instinct with agents is to babysit the output stream and approve every step, which just rebuilds the same bottleneck with extra latency. So the rule became: I watch exactly one agent by hand. The director. Everything below it runs while I'm not looking.
The fan-out that actually works
On paper the director can run ten leads in parallel. In practice it runs two or three comfortably, and the gap taught me more than the architecture did.
The streams don't queue up at the building. They queue at the integration. Every finished piece comes back for verification and merge, and both of those serialize: one repository, one committer at a time. Ten leads finishing means nine wait while the director integrates one. So the concurrency policy became a table instead of an ambition: two to three concurrent leads, bigger tasks preferred over micro-tasks so completions stagger instead of pile-driving the merge queue at once, and finished work waits in a review queue rather than interrupting the fan-out.
Every parallel system I've ever touched has this shape. The workers scale. The point where their work becomes one thing doesn't. Size your parallelism to the bottleneck you can't parallelize.
Parallel build, serial merge
Ten agents writing into one working tree isn't throughput, it's a merge conflict with a heartbeat. So each lead gets its own git worktree: a separate checkout, its own branch, its own dirty state. Under it, workers fan out freely. Nobody steps on anybody, because nobody shares a working directory.
Integration back to main is single-file. One worktree lands, rebases onto whatever shipped before it, resolves its own conflicts, then the next one goes. No two branches merge at once, ever. It's the printing-press model: set the type in parallel, run the page through one press.
Autonomy is a document, not a vibe
An agent that asks permission for everything is a slower version of you. So I wrote down exactly what mine are allowed to do behind my back. I call it the Authority Matrix, and it isn't clever: a two-column list.
May do unsupervised, don't ask:
- Reap an idle worker that's burning a slot.
- Throttle dispatch when the budget runs hot.
- Restart a process that hung.
Must stop and escalate to the human:
- Push to production.
- Spend money: a paid API, a new subscription.
- Install anything external, or write to the machine's real config.
The line between the columns isn't importance. It's reversibility. A reaped worker respawns; a bad prod deploy and a charge on a card don't undo. If the worst case is cheap and local, the agent owns it. If the worst case reaches the outside world or my wallet, it stops and pings me. That single rule killed most of the friction: the only things that reach my phone now are the three or four decisions a week that genuinely need a human.
The expensive lesson here was about questions, not permissions. One night the director hit an architectural fork it judged worthy of a human nod, and asked through a blocking primitive: a modal that froze the whole session until someone answered. Five work streams sat frozen behind a single yes/no. The fleet burned about 4% of the weekly allowance that entire night, roughly a five-hour window and a half spent waiting on a button. A polite confirmation turned out to be the most expensive thing an autonomous agent can do: compute scales in parallel, a blocking question stops the parallelism whole.
The rule since: never a blocking question inside the loop. Drop a visible "waiting on you" marker, switch branches, drive on. And the test I now run over every design fork: if the human vanished for six hours, what stalls? If the answer is "everything," you built it wrong.
The org needs a memory that can't be faked
The most load-bearing component of the whole system is a boring one: the idea registry. Every idea, task, and dead end is a row in a database, 300-plus of them by now. Two properties make it work.
First, lifecycle status is computed, not typed. A work marker on disk means in-progress. A completion report means "needs review." Only a verification stamp from a different agent means done, and a guard rejects anyone trying to write the status field by hand. The builder cannot mark its own work complete, by construction. That verification layer deserves its own article, and got one: Verification over trust.
Second, it gets searched before anything gets built. The hit rate is humbling: half the "new" ideas I get excited about already exist in the registry, sometimes with notes, sometimes half-built and parked. A human team keeps institutional memory in hallways and standups and the person who says "didn't we already try that?" I don't have hallways, so I built the hallway. The expensive failure in a one-person org isn't a bug. It's quietly paying twice for the same idea.
Capture-first has a bill, though: agents file follow-up ideas relentlessly, so the backlog bloats faster than any human team could manage. The org grooms itself. On the last pass it collapsed 47 open items into 27 against explicit merge criteria: same root cause, same code surface, and if two items would be fixed by one pull request, they're one item. I reviewed the verdicts in minutes. The machine does the squinting.
And every delegation leaves a trail. Each spawn appends one line to a git-tracked process log: timestamp, agent, task, event. Who spawned whom, for what, and when. It sticks because it's a one-line command, not a prose duty; "remember to document your process" fails with agents exactly the way it fails with humans. When a build goes sideways, I open one file and read the whole chain of custody.
What a normal run looks like
An evening from the log. I handed the org a graph of 12 dependent tasks. A graph, not a list: database migrations on one branch, the API layer on another, the UI on a third, converging where they actually meet, with QA and security review as nodes that nothing routes around. I went to bed somewhere around task three.
Two infrastructure bugs surfaced mid-flight that had nothing to do with the feature. Both got caught, filed, and fixed inside the same run, because a blocked branch doesn't stall a graph, it reroutes the work. By morning all twelve tasks had landed and 3,888 tests were green across three codebases: 722 in the UI, 1,380 in the CLI, 1,786 in the platform.
Or a migration: eleven services moved to a new secrets architecture, plaintext env files replaced with registry references injected at process start. I described what I wanted, reviewed the diff, verified the cleanup, approved it. I never opened a single config file.
A decent day sees around ten ideas move from backlog to merged, a batch of images generated for cents, a couple of slide decks built from specs. The entire operation runs on a $200-a-month flat plan; the budget engineering behind that number is its own story.
What the human is for
Judgment, mostly. Deciding what's worth building. Knowing what "good" looks like and refusing to ship less. One afternoon four merges came back "green." The verification layer re-checked, and all four were actually red. They never reached production. The system caught it, but the standard it enforces came from me.
And honesty about failure, because plenty failed. The infrastructure cascaded one night and I debugged it live, in a system I had designed but not memorized. A monitor woke me at 3am to report a corpse that was alive. I published an honest one-month scorecard of all this; the short version is that almost every incident was one of my own assumptions surfacing faster than I could hide it.
I didn't get less technical building this. I got technical about different things: who decides what, what runs unsupervised, how "done" gets proven, where ops noise dies before it reaches a human. That's still engineering. It just operates on an organization instead of a codebase.
If your AI tooling has stopped scaling, don't tune the prompt. Draw the org chart.