The economics of agent swarms aren't obvious. More agents doesn't automatically mean better outcomes or lower spend. It depends on how tightly you've defined the problem.
I've seen teams spin up swarms for tasks that a single well-scoped agent handles faster and cheaper. Here's what actually matters:
Problem decomposition has to be real. If your subtasks genuinely run in parallel and don't require constant synchronization, swarms win. If they're just sequential steps disguised as agents, you're paying for coordination overhead instead of saving it.
State handoff is expensive. Every time one agent passes work to another, you're serializing context, adding latency, and risking information loss. The fewer handoffs, the better. A swarm makes sense when each agent can operate independently on a clearly isolated piece of the problem.
Failure modes compound. One agent failing is one failure. Five agents with interdependencies means debugging cascades. If you need audit trails and trustworthiness (compliance, client review, recovery), swarms add complexity that has to be accounted for in your delivery timeline.
Measurement is the hard part. Before you architect for swarms, measure what's actually slow in your current process. Is it computation, or is it context switching and decision-making? Agent count doesn't fix decision-making problems.
Start small and scoped. A single well-defined agent on a tight problem will teach you more than a swarm that's trying to solve everything. Once you know exactly where parallelism saves time, build for it.
The temptation with new tools is to maximize their use. Resist it. The best agent architecture is usually the one that does one job so clearly that adding more agents actually makes things worse.