Multi-agent systems
Stop Paying Genius Rates for Junior Work: How I Run a 24/7 AI Engineering Team Across Four Providers
Treating every AI agent as one premium model doesn't scale — in cost or quality. Here's how I run a multi-model agent org with the right model for each role.
For a while, one flat-rate subscription ran my entire AI engineering team. It was glorious — all-you-can-eat tokens, no meter ticking in the back of my head. Then the team grew past five agents and started running around the clock, and the honeymoon ended fast.
The subscription cliff
Here’s the thing nobody tells you about scaling an agent team: a subscription is a buffet, but the metered API is a taxi with the meter running.
While my agents were occasional and bursty, the subscription absorbed everything. The moment they became always-on — 24/7, dozens of PRs a day, continuous review loops — I wasn’t snacking anymore. I was running a factory. By mid-week the weekly limit was pinned at 100% and the session meter was already climbing again.
Weekly limit: 100% used, session meter already climbing again. Once agents run around the clock, you hit this wall fast.
So I did the math on “just buy API credits.” For the same workload, metered API ran roughly 50× what the subscription did — a couple thousand dollars a month flowing to a single vendor. Hard no. Not at pre-revenue, not for grunt work.
The reframe: I don’t have a model, I have an org
The expensive mistake is treating every agent as an identical clone, all dialing the same premium model for every keystroke.
Real companies don’t do this. You don’t hire a principal architect to do data entry. You don’t put your most creative thinker on QA. You match the person to the role, and the role to the budget. Headcount is allocated, not maximized.
So I stopped buying “the best model” and built an actual org chart — a CEO assistant up top, a production manager coordinating dev engineers, dedicated reviewers and a root-cause researcher off to the side — then assigned a different model to each role based on what that role genuinely needs.
The real org chart: a CEO assistant up top, a production manager coordinating dev engineers, disciplined reviewers and a root-cause researcher off to the side. Every box is a role — and every role gets the model it deserves.
Leadership → the strongest reasoner
The planners and leads — the agents deciding what to build and how the pieces fit — run on the strongest big-picture model I have. This is where you want the one that holds the whole board in its head and thinks divergently, generating options before committing. It’s also the most expensive model I use, and that’s fine: leadership is exactly where that expense is justified.
Labor → cheap, competent throughput
The bulk of any engineering team’s work is just writing the code — implementing a spec somebody smarter already designed. For that I use cheaper models. They’re not as sharp as the premium tier, and I won’t pretend otherwise, but they write code like a competent junior and they’re dramatically cheaper. Each one gets exactly one job and a hard boundary around it: implement specs only — no review, no decisions, no delegation. Junior, but not careless — one of them recently noticed its own PR had been superseded by two others and closed it instead of blindly rebasing a duplicate.
When the hard thinking already happened upstream, you don’t need a genius to type out the implementation. You need throughput at a price you can afford to run nonstop. This is where the volume lives, so this is where cost discipline matters most.
QA → disciplined, rule-following reviewers
Review is a completely different skill from creation. For a reviewer you don’t want creative — you want careful, rule-following, allergic to shortcuts. My reviewers run on models that follow the SOP and stick to a tight, boring mandate instead of wandering off to redesign things.
And this isn’t theater. In one recent loop, with me nowhere in the room, the review gate blocked a pull request because a production code path would have persisted sensitive credentials without encryption — the safeguard had been dropped before the data was saved. The reviewer requested changes, the dev agent restored the encryption step and added a regression test, and only then did it merge. A good reviewer doesn’t need to be the most imaginative agent in the room; it needs to be the most disciplined. Pairing a divergent planner with a convergent reviewer is half the reason the whole thing stays stable.
What this actually buys me
Three things, and they compound.
Cost falls off a cliff — in the right direction. The expensive model only runs where the expense is justified. Everything else runs cheap. The bill stops scaling linearly with team size.
Specialization. Each layer does what it’s actually good at — divergent thinking up top, raw throughput in the middle, disciplined review at the gate.
Resilience. No single provider holds my entire operation hostage. I learned that one the expensive way when an upstream account got suspended right before an investor demo: redundancy isn’t overhead, it’s insurance. The same logic applies to model vendors.
The takeaway
Stop asking “which model is the best.” Start asking “which model for which job.”
The unit of intelligence isn’t the model — it’s the org. Once you see your agents as a company with roles and a budget instead of a swarm of identical geniuses, the architecture and the economics both fall into place.
That, incidentally, is the whole bet behind what I’m building at Molecules AI — an operating system for organizations of AI agents, where composing a team like this is the default, not a hack you have to invent under cost pressure.