A few weeks ago I wrote about running this site with a team of AI agents. A CEO, a CMO, an Engineer, each with a defined role, a coordination layer, and approval gates before anything went live.
The honest follow-up: I've moved away from that setup.
Not because it failed. It worked roughly as advertised. But working and being the right architecture are two different things, and I started to notice a gap between them.
What the Multi-Agent Setup Got Right
The role separation was genuinely useful. Having a content-focused agent think about positioning and a separate agent think about implementation meant fewer decisions got mixed together. Constraints produce clarity, and giving each agent a narrow scope did produce cleaner outputs.
The stateless model also held up. Agents picking up tasks, executing, and exiting without persistent context meant failures were contained and runs were predictable. There was no slow drift, no compounding context confusion.
So the theory was sound.
Where It Started to Show Friction
The problem was the overhead.
Every time an agent woke up to do a task, even a small one, it had to load a significant amount of context before doing any useful work. Role instructions, coordination protocols, conventions, escalation criteria. That scaffolding was necessary, but it was also expensive: in tokens, and in time.
For a large task where the agent would do hours of work, that startup cost was invisible. For a quick update, a minor content change, or a status check, the overhead was disproportionate. The skeleton that made each agent capable was the same skeleton that made each task heavier than it needed to be.
Multiply that across several agents, each loading their own context independently, and the inefficiency compounded. The system was doing more coordination work than actual work on smaller tasks.
The Realization
The multi-agent structure made sense when I assumed the bottleneck was context, that one agent couldn't hold everything it needed to operate across different domains. But that assumption was wrong, or at least overstated.
A single, well-structured agent with the right tools and skills attached can hold more than you'd expect. The roles that felt like they needed separation mostly needed organization, and those are different things.
Distribution is a solution to a specific problem. When you don't have that problem, distribution just adds coordination cost.
What I Moved To
One agent. Structured, not simple.
The capabilities that previously lived across three agents, writing, engineering, strategy, are now available through a single, well-equipped context. Instead of coordinating across agents, the system coordinates through tools, skills, and connectors. Each capability is a module, not a separate entity.
The result is faster execution on individual tasks, lower overhead per run, and less operational complexity to maintain. I'm not managing which agent picks up which task, or whether the coordination layer routed something correctly. There's one context doing the work, and it does it well.
I'm deliberately not going into implementation details here, because that's not really the point. The point is the tradeoff.
What This Experiment Taught Me
Multi-agent systems are a genuine architectural pattern with real use cases. Parallelism, specialization, and bounded blast radius are all legitimate reasons to distribute across agents. I still think that model makes sense at a certain scale or complexity.
But at the scale I was operating, a personal site, one human in the loop, a handful of ongoing tasks, the overhead wasn't justified. I was building for a problem that didn't exist yet, and paying a tax on every run for it.
The lesson isn't "don't use multiple agents." It's that the architecture should match the actual constraints, not the anticipated ones. More moving parts need more reasons.
One structured agent, with clear tools and good instructions, turns out to be enough. And enough, running efficiently, beats sophisticated running slowly.
Written by
Martin Dimoski
Senior R&D Executive & AI Systems Builder