When Multi-Agent Orchestration Actually Improves Software Delivery

Multi-agent systems are having the moment that microservices had a decade ago: the architecture is genuinely useful for specific problems, the tooling has made it easy to spin up, and it is being applied to a lot of work that would be better served by something simpler. Every coding tool now ships some form of subagent, orchestrator, or swarm — so the question facing engineering teams is no longer can you run multiple agents, but when it's worth it.

My position, after building agent systems for production customer operations and using coding agents daily on my own repositories: a multi-agent architecture is justified when work decomposes into bounded responsibilities with explicit contracts, independent context, and verifiable outputs. It is harmful when agents duplicate context, edit overlapping files, or add coordination cost without adding correctness. More agents is a cost you pay, not a capability you gain — and the burden of proof sits with the added agent.

The default architecture for coding work should be one capable agent with full context. This isn't conservatism; it follows from how the work behaves. A single agent holds one coherent model of the task: every decision it makes is informed by every file it has read and every command it has run. There is no translation loss between what one agent learned and what another agent was told. Ownership is unambiguous — one actor made every change, and the conversation is the audit log.

Most feature work has densely coupled context: the data model informs the API shape, which informs the UI, which informs the tests. Splitting that across agents means serializing shared understanding into prompts — and every serialization is lossy. Anthropic's own guidance on agent design makes the same point from the vendor side: start with the simplest composition that works, and add machinery only when it demonstrably improves outcomes.

Decomposition earns its cost when the boundary between agents is real — meaning the work on each side can proceed with independent context and be verified independently. In practice, I see six situations where that holds:

• Genuinely independent workstreams. Two features touching disjoint parts of the repository, with no shared files and no shared design decisions. The boundary already exists; agents just inherit it.
• Specialized review. A reviewer agent with fresh context reads the diff without the builder's accumulated rationalizations. Its value comes precisely from not sharing context — the isolation is the feature.
• Parallel investigation. Broad, read-only questions — "find every place we construct this payload" — fan out well because reads don't conflict and results are cheap to merge.
• Large repositories. When no single context window can hold the relevant surface, scoped investigators that return summaries beat one agent paging through the whole tree.
• Security and permission boundaries. An agent that only reads and reports can safely run with broader access than an agent that writes. Splitting by privilege is a boundary a single agent cannot express.
• Independent validation. A test-runner or deployment-verifier whose only job is executing deterministic checks and reporting evidence — valuable specifically because it has no stake in the implementation being judged.

Within those boundaries, a small set of roles shows up repeatedly because each maps to a real seam in engineering work: the planner (read-only investigation producing an explicit plan), the repository investigator (scoped search-and-summarize in large codebases), the implementer (executes an approved plan on an isolated branch), the test and validation agent (runs deterministic checks, reports evidence), the security reviewer (reads diffs for injection points, permission changes, secret handling), the documentation agent (updates docs from the merged diff — trailing, never blocking), and the deployment verifier (confirms post-deploy behavior against expected outcomes). Notice what's common: each role has a natural input artifact, a natural output artifact, and a verification story. Roles invented without those three properties — "the creativity agent," "the strategy agent" — are prompt fragments cosplaying as architecture.

Every agent you add taxes the system in ways that don't show up in the demo:

• Context duplication. Each agent re-reads the same files to build its own model of the repository. Ten agents exploring one codebase can spend more tokens on redundant reading than on the task.
• Contradictory assumptions. Two agents reading the same ambiguous code reach different conclusions, and both build on their own version. The contradiction surfaces late — usually in review, sometimes in production.
• Stale plans. A plan written against commit A is executed against commit B. The longer the pipeline, the wider the gap between what was planned and what is true.
• Overlapping edits and merge conflicts. Parallel writers touching shared files produce conflicts that neither agent has context to resolve — so a human inherits a merge between two strangers' work.
• Token and latency overhead. Handoffs serialize; supervisors re-read outputs; retries multiply. The cost curve is superlinear in agent count.
• Unclear ownership. When a defect ships, which agent's context produced it? Distributed authorship without distributed accountability makes post-incident learning genuinely harder.

Sequential pipelines (plan → build → review) trade latency for coherence: each stage sees a settled artifact from the previous one. Parallel fan-out trades coherence for wall-clock time — which is only a good trade when the parallel units are truly independent. My rule is mechanical: parallel agents may share a repository, but they may not share writable files. Reads parallelize beautifully; writes parallelize only along ownership boundaries you can name in advance — separate packages, separate services, separate directories with an explicit interface between them. If two agents might plausibly edit the same file, they belong in sequence, or they belong merged into one agent.

That diagram is also the concrete example: a planner investigates read-only and emits a plan; a human approves it (the cheapest gate in the whole system); a builder implements exactly that plan on a branch; a reviewer with fresh context checks the diff against the plan; tests and builds decide, not opinions. The same two human gates — approved plan, reviewed diff — anchor my single-agent delivery workflow with Claude Code; the multi-agent version just distributes the stages between them.

The difference between an agent pipeline and an agent pile is whether handoffs are structured. Free-text handoffs ("here's what I did, good luck") force the next agent to reconstruct state by re-reading the repository — which is exactly the duplication you built the pipeline to avoid. Every handoff in my workflows carries the same schema:

objective:        # what this stage was asked to accomplish
inputs:           # artifacts received (plan, diff, ticket, prior report)
assumptions:      # what was taken as true without verification
files_inspected:  # paths read, with why
files_changed:    # paths written, with a one-line summary each
commands_run:     # exact commands and their exit status
validation:       # tests/builds executed and their results
risks:            # what could break, and where to look if it does
open_questions:   # ambiguities deliberately left unresolved
next_action:      # recommended next step, with a reason

Two fields do disproportionate work. Assumptions is where contradictions between agents become visible before they become bugs. Validation is what turns "the agent says it's done" into "the build passed and here's the output" — the difference between a claim and evidence.

If you can't measure whether adding an agent helped, you're doing architecture by vibes. The metrics that matter are boring and countable, per task class:

• Completion rate — tasks finished without a human taking over.
• Human interventions — how many times a person had to redirect, unblock, or correct.
• Regression rate — defects introduced per merged change, caught in review or after.
• Rework — changes that had to be substantially redone after review.
• Time to completion — wall clock from task start to merge-ready, including retries.
• Model and token cost — total spend per completed task, not per attempt.
• Review defect density — findings per diff when a human reads the result.
• Reproducibility — does the same task brief produce a comparable result twice?

Run the same task classes through the single-agent baseline first. A multi-agent configuration justifies itself only when it beats that baseline on correctness metrics without collapsing the cost and time metrics. In my experience the honest comparison kills most proposed agents — which is the point of making it.

None of this is an argument against multi-agent systems — it's an argument for treating them as what they are: distributed systems with all the classical failure modes, plus non-determinism. The teams getting real value from orchestration are the ones that earned it with boundaries, contracts, and measurement. The ones getting burned skipped straight to the org chart.