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.