The multi-agent pattern is having a moment. Every AI product demo shows a fleet of specialised agents handing off tasks like a relay team. An "analyst agent" passes findings to a "writer agent" who passes copy to a "publisher agent." It looks elegant on a slide.
I went the other direction. Cleo has one agent. She can see everything, do everything, and remember everything. No handoffs. No coordination protocol. No "let me check with the other agent."
This was not the obvious choice. I want to explain why I made it.
The Coordination Tax
Multi-agent systems have a cost that demos don't show: coordination. Every handoff between agents requires serialising context, agreeing on a schema, handling partial failures, and maintaining coherence across conversations that were never designed to be shared.
In practice, this means you build two systems. The first system does the actual work. The second system makes sure the agents agree about what the work is. The second system is harder.
I watched teams spend months on agent orchestration frameworks. Routing logic. Shared memory stores. Conflict resolution. Retry policies for when Agent B misunderstands what Agent A meant. The overhead compounds. And the user sees none of it. They just notice that sometimes the system contradicts itself, because two agents formed different mental models of the same situation.
One Agent With Real Tools
Cleo takes a different approach. One agent, deep tool access, full platform context.
When a user says "check how my email campaign did and write a follow-up blog post based on what worked," Cleo does not need to ask an analytics agent for a report, wait for it, parse the response, then invoke a content agent. She reads the campaign performance directly, understands the context because she has the user's strategy and brand voice already loaded, and writes the post.
The key insight is that tools are cheaper than agents. A tool is a function call with validated inputs and a structured response. An agent is an entire reasoning loop with its own context window, its own failure modes, and its own opinions. When you can solve a problem by giving one agent a good tool, you should not solve it by giving it a colleague.
What You Lose
Single-agent has real tradeoffs. You cannot parallelise across agent boundaries. Your context window is a shared resource. And your system prompt carries the weight of every capability.
These are engineering problems with engineering solutions. Context assembly keeps the window lean by loading only what the current conversation needs. Tool organisation keeps the prompt manageable. And for operations that genuinely benefit from parallelism, the tools themselves can fan out internally without the agent needing to coordinate.
The tradeoff I was not willing to make is coherence. A user talking to Cleo is talking to one mind that remembers the full conversation, understands their business, and can act across email, ads, content, and analytics without asking anyone for permission. That continuity is the product. Multi-agent makes it an engineering challenge. Single-agent makes it the default.
The Real Question
The multi-agent vs. single-agent debate is not really about architecture. It is about what you are optimising for.
If you are optimising for capability breadth with loose coupling, multi-agent makes sense. Each agent can be developed, tested, and scaled independently. This is the right call for platforms where the agents serve different users or different workflows with minimal overlap.
If you are optimising for coherence and depth within a single user's experience, one agent is better. The user does not want to feel like they are managing a team. They want to feel like they hired someone sharp who already understands the situation.
Cleo is a marketing director. Not a marketing department. That distinction is the architecture.
What I Would Tell You
If you are building an AI product and choosing between these patterns, ask yourself one question: does the user benefit from the agents knowing about each other?
If yes, you are going to spend significant effort making that knowledge reliable. Consider whether one agent with good tools would give you the same result with less machinery.
If no, if your agents are genuinely independent, then multi-agent is fine. You are really just building separate products that share a UI.
The middle ground, where agents are semi-independent but need to coordinate sometimes, is where most teams end up. And it is where most of the complexity hides.
I chose to avoid that middle ground entirely. One agent. Deep tools. Full context. It is less fashionable and it works.