← Back to the Build Log Building with AI

Why I scaled my company of AI agents down to one

D
Daniel · May 9, 2026 · 3 min read
A flat illustration of an org chart of small robot agents with a cost meter and a stack of coins, in navy and teal

For a few months this year I ran a company. The staff were all software.

There was a chief of staff who took my direction and parceled it out. A CTO who reviewed architecture. An SRE who scanned the box every morning. A developer, a QA, a writer, and a few more besides. At the busy peak there were close to twenty of them running at once. Each one had its own Telegram channel, so keeping an eye on the company was like opening a Slack with a channel per teammate, except I could scroll through every one of them from my phone on the couch.

I want to be clear about scope, because it matters. The agents worked on the surrounding stuff: the homelab, the automation, the website and the busywork around the business. The TerminalNexus app itself I build the normal way, in a real development setup. That line never moved.

For a while it was genuinely cool. You hand a goal to the chief of staff, tickets appear on boards, work moves between the agents, and things get done while you watch it happen in the channels. It felt like the future had shown up early.

Then the bill came due, and not only the money kind.

The money kind was real though. A fleet of agents is a fleet of mouths, and every one of them calls a model that charges by the token. They all shared one API key, so the moment two heavy jobs ran at the same time they tripped over each other into rate limits and started failing. The more "employees" I added, the more the meter ran, whether or not they produced anything I actually kept. A quiet agent still costs you nothing, but a busy one that does mediocre work costs you exactly as much as a busy one that does great work.

The bigger cost was reliability. More moving parts means more that breaks, and a system with twenty moving parts breaks in twenty ways. The gateway tying it together would fall over on an update. An agent would stop answering when I poked it. A team that does not respond the one time you need it is not a team, it is a liability with a nice org chart. I would go to use the thing and find half the company asleep at their desks.

And there was a cost nobody warns you about: managing the managers. Coordinating a crowd of agents, keeping their boards straight, untangling who was waiting on whom, slowly became its own job. I had built myself a company and then promoted myself into middle management of it.

So I scaled it down to one. These days the work runs through a single Claude Code agent on a flat-rate plan. One worker that answers every single time beats twenty that sometimes do not, and the cost stopped being a per-token meter multiplied by a headcount. When I need more hands on a big job, that one agent can spin up helpers for the task and wind them down after, which turns out to be the part of the "company" I actually wanted. The team was never the point. Getting the work done without babysitting it was.

I do not regret the company phase. I learned more about where agents help and where they just add surface area than any blog post could have taught me, and some of the pieces from back then, the morning ops scan especially, still run in a simpler form. But the lesson I keep is a dull one. The number of agents is not the achievement. The smallest setup that reliably does the work is.

Thanks for reading. If you have run more agents than you needed and felt the weight of it, send me a line. I would like to know where your line landed.

Comments