Masterminding MultiAgent Orchestration

April 2025 was when I started using AI coding heavily, and I wouldn't say it was any more efficient than writing code by hand myself. The only difference was that I could go get lunch while it worked. Most of my time was still spent reviewing the code it wrote (because it was not very good then), and correcting it by hand. For a slow typist like myself, this was kind of a net zero. I don't think I gained or lost by using AI. Even now, given a simple coding task with the scope of what I was doing back then, I don't think an AI coder would do it faster than me doing it by hand.

Brooks's Law

But nine women can't make a baby in a month, the analogy behind Brooks's law. In other words, the efficiency gained over a long period of time is not necessarily measurable in the short term. Even if I can produce faster than one agent, I can't produce faster than two, and I certainly can't produce faster than twenty, a hundred, a thousand. The realization was this: if I'm letting an agent run while I get lunch, then why can't I let an agent run while I'm coding? And then why can't I have many agents running while I'm coding? The thinking just kind of spiraled from there. But the big problem was that these agents didn't really do a great job of coding. So my day became getting as many agents writing code for me as early in the morning as I could, and when the first one finished, correcting it and getting it going again. My day became about 20% creating agents and 80% reviewing code. I was able to have about two to four agents running at any given time.

One agent, one lane

I realized that the agents were only capable of working on one part of a project at a time. If I needed to make a sweeping change that touched the UI, the API, the business logic, and the database, the agent could only work on one of them at a time. On top of that, the other agents I was trying to run alongside it needed to be working on things the first agent wouldn't touch.

Worktrees

Sometimes I don't really see the value of a technology until it solves the exact problem I'm running into. That was git worktrees for me. I had been trying to write some middleman algorithm to synchronize branches of code that would then merge up (I honestly don't even remember how anymore, because it's totally obsolete now). When an agent starts, it makes a worktree, and that immediately solved my competing-agents problem. But keep the thought going (overthinking, overthinking): when a worktree is made, divide the job it was given into worktrees of that branch, each one with its own agent. Even better, have the spawning agent moderate the work done across all of its child worktrees. Worktrees solved both my competing-agents problem and my one-agent-can-only-work-on-one-thing problem at once.

Faster, but still making the same mistakes

At the time, subagents weren't really a thing yet (I think Claude had a beta but I hadn't used it). So I built my own project, called Conductor, to do pretty much everything subagents do today. (Maybe I'll publish it someday. It's super messy, but it worked.) After using this schema I saw my output skyrocket. But this did not solve my review problem: the agents kept running into the same problems and making the same mistakes.

A brain the agents could share

My coworker David had been working on a project (which I'm hoping he releases soon) that was essentially a searchable knowledge graph maintained over MCP connectors. By giving my agents the setup and configuration to read it, they could persist knowledge across and between jobs. Even better, I could feed the knowledge graph tasks for my agents to perform. And better still, as I corrected my agents, they would update and maintain the graph on their own so they wouldn't repeat the same mistakes. Essentially, all the time I had spent reviewing turned into architecting. I could produce at the speed of thought (or at least start producing; still can't make a baby in a month). And the more I reviewed and corrected the code, the better it got.

The wiki as hot memory

Andrej Karpathy's LLM wiki, read this, it's brilliant. Growing from his idea, I connected all of the problems I was trying to solve. Associate it with the MCP knowledge graph, and have it act as hot memory for the agents. Instead of many agents making many web requests, keep the document local and periodically sync it with the MCP brain. This is where I'm working from now. The plugin I published, ClaudeArchitect, will let you do the same work too. To honor David and his work on his MCP project, I've removed it from the plugin. But the idea still stands. On its own it just won't function across a massive software organization.

I don't want to restate Andrej's work. But I think we both followed similar paths to get to the result we're at now. His idea is fantastic, and it's amazing that he shared it. Have the wiki for the agents, maintained by the agents. Don't just capture code: capture thinking, capture design, capture context. It is a working log of the developer brain, projected and transcribed by a team of agents.

My day is ideation now

My day is ideation now. I create a Claude instance and talk about what I'm planning to add to the project. We work out all of the details. I have it point out potential problems and risks to me, and then we reiterate, until the idea is fully locked in. And then I hit run. And it spins up teams of agents, each with their own teams of agents (max depth four, for now), each rolling up changes and suggestions and questions until they surface to me. And while it does all this, I start another one.

Coding agents are not perfect, and I still need to heavily moderate them, but the more I do the better they get. And the best thing about this schema is that it's cheap to run. Because of the agent structuring and the ability to read the wiki, each agent runs with relatively low context. Now that Claude has introduced workflows, it's a very similar idea to what I'm doing here, but at a much higher cost. So I don't use them, though I'm sure they'll get better.

Still a work in progress

I imagine someday dynamically creating agent .md files for specific, typed agents. Better knowledge of effort and model selection will optimize cost and quality even further. This is still a work in progress, so please, make it better and tell me how you did. I'll keep the repo up to date so you can all see how I'm building with it too.