Multi-Agent vs Single-Agent: How to Choose the Right Architecture
The most common architectural mistake teams make when building AI agents isn't choosing the wrong model or writing bad prompts. It's choosing the wrong number of agents.
Multi-agent systems have an almost gravitational pull for engineers. They feel a...
omnithium.hashnode.dev14 min read
Good frame — blast radius is the right axis to think about this. I'd add one thing: it's not just architecture (single vs multi) that determines blast radius, it's whether you have a policy gate between the agent and the destructive tools.
The billing-agent-erroneously-generates-invoices example you mention is a perfect case. The agent could be single, multi, or no agent at all — what matters is whether a separate process inspects the action before execution. Same applies to "tidy up the staging database" → DROP TABLE.
Wrote this up after the Replit/Cursor prod-DB incidents: an agent specifically built to refuse destructive ops when instructed, with the refusal logic outside the model so the agent literally can't talk itself out of it. DropGuard architecture.
Single-agent has lower coordination cost, multi-agent has lower per-task blast radius — the gate makes either survivable.