When does splitting work across specialized agent roles actually pay off?

## The question behind the question Interviewers ask this because most failed multi-agent projects fail here. A team reads about agent crews, defines six roles, and ships something slower, costlier and less reliable than the single agent it replaced. The discriminator is not how good the personas are; it is the *shape of the work* the roles were pointed at. ## Two shapes of work **Read-and-verify work** is work where each unit can be investigated independently and the results combine additively. Reviewing three vulnerability candidates. Checking twenty log streams for a symptom. Reading six services' configurations to answer one question. Each role reads, reasons, and returns a self-contained finding. Nothing one role does invalidates what another is doing, and there is no shared object being mutated. This shape parallelises almost perfectly, and it is where role specialization genuinely pays. **Converging-mutation work** is work where several roles must arrive at one coherent artifact — one patch, one document, one configuration. Here the units are not independent: each agent's correct action depends on the current state of the artifact, which other agents are changing underneath it. Splitting this across roles does not reduce the work, it adds a reconciliation problem that did not exist before. ## Why the second shape breaks Three things go wrong at once when agents converge on one artifact. First, each agent is reasoning over a snapshot. Agent B decided its edit was correct against the file as it stood two minutes ago; by the time it writes, that premise is stale. The output is syntactically fine and semantically wrong, which is the worst failure class because nothing errors. Second, agents drift on what the task even is. Given the same brief, two roles will interpret an ambiguous requirement differently and then implement both interpretations into the same artifact. The result is internally inconsistent in ways no individual agent can see, because no individual agent holds the whole picture. Third, someone must reconcile. That reconciliation is itself a hard reasoning task, usually harder than the original edit, and it lands on an orchestrator that has less context than any of the workers. ## The concrete contrast Take an application-security triage crew. Point three specialist roles at three distinct candidate findings: a scanner-fed reviewer per candidate, each with repository read and a sandbox runner, each returning `exploitable / not_exploitable / unknown` plus the file and line that justify it. This works. The candidates are independent, the work is read-only, wall-clock time collapses to roughly the slowest single investigation, and the orchestrator's merge step is trivial — it staples three verdicts together. Now point the same three roles at one remediation patch for one of those findings. They now need the same file. One rewrites the input validation, one rewrites the caller, one rewrites the test. Each is individually plausible; together they may not compile, and the orchestrator has to work out which combination was intended. You have converted a single well-scoped edit into a merge problem plus a review problem. ## The rule that survived The field walked around this twice. The 2025 position was close to "don't build multi-agents"; the 2026 correction is narrower than the original enthusiasm and sharper than the retraction: **let the extra agents contribute intelligence rather than actions, and keep the write path narrow.** Fan out for investigation, verification, critique and search. Do not fan out for mutation. A useful corollary: a role whose job is to *read and report* is cheap to add, because its worst failure is a wasted budget and an ignored report. A role whose job is to *change something* is expensive to add, because its worst failure is a corrupted shared artifact that other roles then build on. ## Second-order considerations Even on read-and-verify paths, specialization is not free. Each role re-establishes its own context, which costs tokens; a fan-out of five doing shallow work can burn far more than one agent doing the same work sequentially, for no accuracy gain. So the split should be justified by one of two things: real wall-clock parallelism on slow subtasks, or genuine context isolation where each role only needs its own slice and would be degraded by seeing the others'. There is also a verification benefit that is easy to miss. A verifier role that never saw the generation is not just a second opinion — it is a second opinion uncontaminated by the reasoning that produced the artifact, which is why review-shaped splits punch above their weight even when the underlying model is identical. ## How to answer in an interview State the discriminator (independent read-and-verify versus convergent mutation), give one concrete example of each, name the failure mode of the bad shape (stale premises, divergent interpretations, reconciliation cost), and finish with the operating rule: extra agents add intelligence, not actions. That answer demonstrates you have watched a crew fail, which is what the question is probing for.