Delegation, parallelism, specialization and the cost of coordination
If one capable model can solve a problem, why use several? The answer is not "because more agents are always better." In many tasks a team of agents creates extra communication, duplicated work and more opportunities for error.
When should work be divided among several intelligences? Only when decomposition creates a real advantage.
A Short Reminder: An Agent Team Is Still Software Architecture
A multi-agent system usually has one or more model instances working on separate parts of a task and exchanging results through a harness. The instances may be identical or specialized. The important point is that the surrounding application defines who can delegate, what information each agent receives, and how results are combined.
Astra Is Explicitly Trained for Subagent Delegation
OpenAI states that Astra is trained to divide and delegate work to subagents that can operate in parallel, and its guidance recommends prompting the model about when delegation should be used. That is a notable shift: delegation is no longer only a framework trick built around a general model, but behavior the model has been trained to perform more effectively. It does not answer the question of when delegation is worth it. That remains a design decision.
Three Situations Where Multiple Agents Can Help
Anthropic has publicly emphasized three recurring cases where multi-agent systems make sense: context isolation, parallel execution and specialization. They are useful because each names an engineering reason for delegation, and each has a cost that can cancel the benefit.
Context isolation. A complex project may contain several large workstreams that do not need to share the same active context. One agent inspects security logs while another studies database performance, and each keeps a smaller, more relevant working set. The root agent receives conclusions rather than every raw detail. The cost is that evidence can be lost in the summary that crosses the boundary.
Parallel execution. Independent tasks can run at the same time: one agent examines application code, another reviews infrastructure configuration, a third researches vendor compatibility, a fourth challenges the proposed migration plan. If the tasks are genuinely independent, elapsed time falls substantially. If they depend on each other, parallelism creates rework instead.
Specialization. Different agents can be given different roles, tools or instructions. A verification agent looks only for contradictions; a security agent receives read-only scanning tools; a research agent has web access but no deployment authority. Specialization is partly about attention and partly about permissions, and the second half is the more important one.
The Root Agent Becomes a Manager
Once delegation begins, the root agent has a new problem: coordination. It must decide which tasks to delegate, how much context each subagent needs, whether two agents are duplicating work, how to resolve disagreement, when a subagent result is good enough, and how to combine partial answers into one coherent outcome.
Multi-agent architecture does not remove complexity. It moves complexity from individual reasoning into task decomposition and coordination, and a poor decomposition is harder to detect than a poor answer.
Disagreement Can Be Useful
Two agents reaching different conclusions is not automatically a failure. For high-risk decisions, disagreement can expose uncertainty that a single confident model would hide. A system can ask another agent to compare the evidence rather than simply vote on the answers. The goal is not consensus; it is to discover why conclusions differ and which evidence resolves the conflict.
Verification Agents Need Independence
A verifier is less useful if it receives the original agent's conclusion before examining the evidence, because it inherits the same framing. A stronger pattern lets the verifier inspect the task and evidence independently, then compares results afterward. This does not guarantee independence at the model-weight level, since two instances of the same model share the same blind spots, but it reduces direct conversational anchoring. Chapter 13 develops this further.
Cost Can Grow Faster Than Quality
Each additional agent consumes context, reasoning tokens, tool calls and orchestration time. If five agents repeat the same analysis, the system costs five times more without becoming meaningfully better. Good multi-agent design therefore needs a stated expected benefit: reduced elapsed time, better context separation, specialist tooling, independent verification, or coverage of genuinely distinct hypotheses. If none of those can be named before the second agent is added, the second agent is a cost.
State Must Be Shared Carefully
Some state belongs to the whole project; other state belongs only to one subagent. If every subagent can rewrite global state, coordination becomes dangerous. A safer pattern is for agents to return proposals or evidence to a coordinator, while a controlled layer decides which changes become authoritative project state. This is the Chapter 9 state store with one more rule: subagents propose, the coordinator commits.
Where It Can Still Fail
The decomposition is wrong. Every subagent does its part well, and the parts do not add up to the task.
Two agents touch the same resource. Neither knows the other is there.
Context is lost at the handoff. The detail that mattered did not survive delegation.
The team shares one mistake. Agents reinforce the same assumption instead of providing independent evidence.
Coordination costs more than it saves. The overhead exceeds the benefit of parallel work.
A subagent is over-equipped. It receives broader tools or data than its task requires.
The frontier is moving from one model handling one sequence of work toward systems that allocate intelligence dynamically. The capability that matters is not the number of agents but the ability to decompose work, preserve boundaries, coordinate evidence, and use parallelism only where it helps.
Three Things to Remember, One Thing to Do
1. Multi-agent systems are useful for context isolation, parallel execution and specialization, not by default.
2. Delegation creates a coordination problem that can be harder than the original task.
3. Verifier agents should be designed to add independent evidence, not repeat the first model's conclusion.
One thing to do. Before adding a second agent to any workflow, write one sentence naming the expected benefit, whether context isolation, parallelism, specialization, independent verification or distinct hypothesis coverage, and one sentence naming the cost in tokens, time and shared state. If you cannot write the first sentence, do not add the agent. Keep the pair; it is the beginning of a decomposition record.
How much do you need? Platform/DevOps: Master · Developer: Use · Architect: Use · Security: Use. Everyone else: Know.