The agent swarm narrative sounds compelling: decompose complex tasks into specialized sub-agents, coordinate them through a message bus, and watch emergent intelligence arise. Every AI startup's pitch deck now features a diagram with dozens of colored circles connected by arrows.
But after eighteen months of building production agent systems, I've reached a different conclusion: most problems don't need agent swarms. They need one capable agent with the right tools.
The Coordination Tax
Multi-agent systems pay a steep price for their modularity. Every boundary between agents introduces:
- Context loss: Information doesn't flow cleanly across agent boundaries
- Protocol overhead: Agents spend cycles negotiating who does what
- Cascade failures: One agent's failure blocks downstream work
- Debug hell: Tracing problems across agent boundaries is brutal
A specialized "research agent" can't leverage what the "writing agent" discovered without explicit message passing. The swarm's IQ is capped by its communication bandwidth.
Meanwhile, a single capable agent with access to research tools and writing tools? It maintains full context. No handoffs. No protocol negotiations. Just continuous reasoning over the complete problem space.
The Specialization Trap
The argument for swarms usually goes: "We need specialized agents because different tasks need different capabilities." But this confuses tool specialization with agent specialization.
Yes, different tasks need different capabilities. But you don't need different _agents_ — you need different _tools_ available to one agent.
Consider:
- A "code review agent" → Really just an agent with code analysis tools
- A "deployment agent" → An agent with CI/CD tools
- A "monitoring agent" → An agent with observability tools
Each specialized agent is just a general-purpose reasoning engine with a subset of tools. Why not give one agent access to all the tools and let it reason about which to use when?
When Swarms Actually Work
I'm not saying multi-agent systems never make sense. They shine in two scenarios:
1. Genuine Concurrency
When you have truly independent tasks that can run in parallel with minimal coordination, swarms help. Think:
- Batch processing thousands of documents
- Running parallel experiments with different parameters
- Monitoring multiple independent systems
The key word is _independent_. If your sub-tasks need to share context or coordinate decisions, you're back to paying the coordination tax.
2. Isolation Requirements
Sometimes you want hard boundaries for security, resource limits, or reliability:
- Untrusted code execution in sandboxed agents
- Rate-limiting expensive operations
- Preventing one failure mode from cascading
But these are operational constraints, not architectural preferences. You're choosing swarms because you _have to_, not because they're inherently better.
The Underrated Power of One
A single capable agent has properties that swarms struggle to replicate:
Coherent strategy: One agent develops and maintains a complete mental model of the problem. Swarms fragment understanding across boundaries.
Adaptive prioritization: Context shifts constantly during execution. One agent re-prioritizes seamlessly. Swarms need explicit coordination protocols.
Unified memory: Everything the agent learns stays in working memory. Swarms need shared state systems that are inevitably stale or incomplete.
Simpler debugging: One agent, one reasoning trace. Swarms generate distributed traces that require correlation infrastructure.
The Real Architectural Question
The swarm vs solo question is actually asking: where do you want your complexity?
Agent swarms push complexity into coordination:
- Message protocols
- State synchronization
- Failure handling
- Context sharing
Solo agents push complexity into tool design:
- Composable primitives
- Clear error semantics
- Rich return values
- Stateless operations
I'll take tool complexity over coordination complexity every time. Tools are deterministic and testable. Coordination is emergent and surprising.
Building for Solo Agents
If you're betting on solo agents, what does that mean for your architecture?
Rich Tool Ecosystems
Invest in tools that:
- Compose naturally (output of one feeds another)
- Return structured data the agent can reason about
- Have clear success/failure semantics
- Support both exploratory and transactional operations
Context Management
Since the agent maintains full context, make it accessible:
- Persistent memory systems (not just chat history)
- Queryable knowledge bases
- Rich session state
Cognitive Budgets
One agent doing everything needs to manage cognitive load:
- Break big tasks into checkpointed sub-tasks
- Use external memory when context grows large
- Recognize when to spawn isolated workers for genuinely independent work
Progressive Tool Access
Start narrow, expand as needed:
- Begin with core tools for common paths
- Add specialized tools on demand
- Let agents discover and request new capabilities
The Swarm Hype Cycle
We're in the classic hype phase where "more agents" sounds inherently more powerful. It's the microservices narrative all over again.
Microservices taught us: distribution has costs, and those costs are often higher than the benefits. Start with a monolith. Extract services only when you have clear evidence that the distribution cost is worth it.
The same applies to agents. Start with one capable agent. Only decompose when you have clear evidence that the coordination cost is worth the specialization benefit.
For most problems, you won't find that evidence.
Practical Proof
I run Zora, my personal agent, as a single Claude instance with ~40 skills (tool bundles). She handles:
- Codebase modifications
- System administration
- Calendar and email
- Research and writing
- Smart home control
- Creative projects
Each skill could be a "specialized agent" in a swarm architecture. Instead, they're tools available to one agent that reasons about when and how to use them.
The result? Coherent strategy across domains. Natural prioritization. No coordination overhead. Just continuous reasoning over my complete context.
Could I build this as an agent swarm? Sure. Would it be better? I'm skeptical.
The Bottom Line
Most companies building "agent swarms" are solving the wrong problem. They're adding architectural complexity to avoid the harder work of:
- Building composable tools
- Managing context well
- Tuning prompts and system instructions
- Developing rich memory systems
One capable agent with great tools beats a dozen specialists with mediocre ones.
Start solo. Scale reluctantly. Your future debugging self will thank you.
_Chris Korhonen builds agent systems and occasionally writes about what actually works. Currently running a solo agent that helps me run my life, my businesses, and this site._
export const social = {
title: 'The Solo Agent Thesis',
description:
'Why one capable agent beats a swarm of specialists. Most companies building agent swarms are solving the wrong problem.',
hashtags: ['AI', 'Agents', 'Architecture'],
hook: 'The agent swarm hype is real. But after 18 months building production systems, I think most companies are making a mistake.',
};