TL;DR
More agents slow delivery when coordination grows faster than useful parallel work. Each new agent needs a clear boundary, shared state, conflict handling, evaluation and an owner for the final decision. Use one agent until separate tasks can run independently and their outputs can be combined cheaply. Add another only when measured waiting time falls more than review and reconciliation time rises.
In this article
6 min read
These two reader concerns frame the article: When does adding more AI agents make software delivery slower? and Is a multi-agent coding system better than one agent?. The links show the wording and context of the questions; the answer below uses primary or official sources for material claims.
Weak signal and stronger evidence
| Weak signal | Stronger evidence |
|---|---|
| The agent or tool says the work is complete | The named result is checked against the exact revision |
| A policy exists in a document | The rule is visible in the working delivery path |
| More output is produced | Accepted outcomes improve without hidden review debt |
That does not make throughput equal to agent count.
Every additional worker creates coordination: task splitting, context, permissions, state, file isolation, handoffs, integration, review, conflict resolution, and recovery.
This is the orchestration tax.
The bill has several line items
Context duplication
Each agent needs enough repository and task knowledge to act. Parallel workers may repeat the same exploration or carry different versions of the truth.
Work collision
Agents can edit the same file, change the same interface, or make incompatible assumptions in isolated branches. Worktrees prevent direct file collisions, not conceptual conflicts.
Integration
Independent changes meet at a boundary. Someone or something must reconcile interfaces, ordering, data, tests, and documentation.
Review
More output reaches the same group of people. Reviewer attention can become the actual concurrency limit.
State and handoff
Every role needs a clear input, output, status, and next owner. Messages without structured artifacts increase reconstruction work.
Recovery
Failed agents leave branches, partial artifacts, reservations, and decisions. Cleanup and retry must be designed.
Model and infrastructure cost
Tokens, compute, test environments, registries, external tools, and rate limits all scale with activity.
Parallelise independent questions
Good candidates for parallel work have:
- separate file or module ownership;
- stable interfaces;
- independent outputs;
- clear merge point;
- useful work even if another branch fails.
Examples can include concurrent repository exploration, independent specialist review, or separate implementation stories behind an approved interface.
Poor candidates share evolving state or require one result before the next decision.
Parallelism should follow dependency design, not enthusiasm.
Rehearse the split before running agents
Take an illustrative feature that adds an export endpoint and a user-facing download screen. It may look like two parallel stories: one agent owns the API and another owns the interface. The split is useful only after the response schema, authorization rule, error states and ownership of the shared test fixture are settled.
Run the plan on paper first:
- Give each worker an exclusive file and decision boundary.
- Name the contract both outputs must satisfy.
- List information that must be shared and information that must remain local.
- Define the integration order and the checks that run only after both branches meet.
- Assign a person or evaluator to disagreements at the boundary.
If the UI cannot proceed until the API agent invents the schema, the work is sequential. Calling it multi-agent adds a handoff without creating concurrency. If both sides can build against an approved contract and their own fixtures, parallel work may shorten the critical path.
Anthropic’s account of its multi-agent research system describes fast growth in coordination complexity and reports early failures such as excessive subagents, duplicated searches and vague delegation. Its measured speed result applies to Anthropic’s complex research workloads, not to software delivery in general. The transferable lesson is narrower: use parallel workers for genuinely separable exploration and give each one a precise objective, output format, tool boundary and stopping rule.
Give each agent one reason to exist
Before adding a worker, answer:
- What unique job does it perform?
- Which artifact does it receive?
- Which tools may it use?
- Which decisions are prohibited?
- What exact artifact must it return?
- Who checks it?
- How is disagreement handled?
- What happens on failure?
If the answer is “help the other agent,” the role may be too vague to justify its cost.
Design the merge point first
Multi-agent workflows often focus on dispatch and leave integration to the human.
Define:
- shared interface or specification;
- artifact schemas;
- writer ownership;
- branch or worktree policy;
- ordering constraints;
- required checks after integration;
- rollback;
- human verdict.
The merge point is part of the plan.
Measure net value
Track:
- accepted outcomes per unit of review;
- duplicated exploration;
- collision and integration time;
- correction turns;
- token and compute cost;
- unresolved handoffs;
- defects crossing role boundaries;
- human queue length.
More parallel output is valuable only when accepted value grows faster than coordination cost.
When another agent earns its place
| Observed condition | Keep one agent | Add a bounded worker |
|---|---|---|
| Dependency | Next task needs the current result | Tasks can finish against a stable contract |
| Ownership | Files and decisions overlap | Each worker has exclusive scope |
| Evaluation | One reviewer must reconstruct both paths | Each output has an independent check |
| Integration | Human synthesis is the main work | Merge point and combined checks are defined |
| Queue | Review is already waiting | A worker removes measurable idle time |
Measure elapsed time from approved task to accepted result, then separate active implementation, waiting, integration, correction and review time. If implementation becomes faster while the review queue and correction work grow, the system has moved the bottleneck rather than improved delivery. Compare like-for-like task classes and keep the same acceptance bar; otherwise more agents may appear faster only because more unfinished output is counted.
Run a small comparison before making the architecture permanent. Complete several similar tasks with one agent, then repeat with the proposed split. Record the same start and end points, including human review and integration. Inspect the slowest stage as well as the average. A two-agent workflow that occasionally saves an hour but regularly leaves the reviewer reconstructing mismatched assumptions is unstable. The result should also show where the benefit came from: reduced waiting, better specialist findings or lower correction work. Without that explanation, the team cannot know when to route the next task to one worker or several.
How paqad-ai approaches orchestration
paqad-ai’s current design describes routed workflows, specialist roles, sequential and parallel steps, structured artifacts, durable state, role separation, failure handling, and human decisions.
The point is not to run the largest number of agents.
It is to coordinate the smallest useful set of roles across the entire feature lifecycle.
Agents create options and output.
Orchestration turns those parts into one reviewable change.
Source notes
- Addy Osmani, The Orchestration Tax, practitioner analysis.
- Addy Osmani, Loop Engineering.
- Product mechanism: first-party details from the current Eliyce/paqad-ai repository.
Decision rule
Proceed only when the team can name the owner, inspect current evidence and stop or reverse the work without reconstructing an agent conversation.
Paqad is a first-party Eliyce product. Teams that want to test these controls on their own repository can explore the AI Delivery Programme.
Frequently Asked Questions
When does adding more AI agents make software delivery slower?
More agents slow delivery when they duplicate exploration, wait on each other, collide on shared files or produce more output than reviewers can absorb. The decisive measure is accepted work after integration and review, not the number of concurrent sessions or generated changes.
Is a multi-agent coding system better than one agent?
It is better for a task only when distinct workers need different context or tools, can act independently and return outputs that combine through a known contract. One capable agent is usually easier to observe when the work shares state or depends on a sequence of decisions.
How do you know two tasks are independent enough to run in parallel?
Freeze the interface and try to describe each task without referring to the other worker’s unfinished choices. If both can be checked with local fixtures and neither can invalidate the other’s scope, parallel work is plausible. If one must repeatedly ask the other what it decided, the split is premature.
Who resolves a disagreement between two coding agents?
Assign the decision before dispatch. A technical owner can resolve interface and architecture conflicts, while a product owner settles behavior. An orchestrator may surface the conflict and evidence, but it should not silently choose between incompatible requirements it was never authorised to decide.
What should be shared between agents, and what should stay local?
Share approved requirements, stable interfaces, decisions, artifact identities and integration results. Keep exploratory notes, failed guesses and task-specific tool output local unless they change a shared decision. This gives workers enough common truth without flooding every context with irrelevant history.
When should a team remove an agent from the workflow?
Remove or combine the role when its output is routinely duplicated, requires more correction than it saves, blocks on another worker or cannot be evaluated independently. Re-run the same task class with fewer workers and compare accepted delivery time, review demand and integration failures.
