Replacing a multi-agent coding pipeline with one agent

A multi-agent coding pipeline should exist only when parallel work saves more time than coordination consumes. If handoffs lose requirements, agents repeat the same checks, context has to be reconstructed, or a failed run takes longer to recover, replace the pipeline with one agent and keep the deterministic controls around it.

I have seen teams count agent activity as throughput. Five agents opening files, running tests, and commenting on one another look busy in a trace. The repository only cares whether a correct change reached a reviewable state sooner. Measure that outcome, not the number of concurrent model calls.

This is not an argument that one agent always wins. Independent migrations, broad research, and isolated package work can justify parallel workers. Most day-to-day coding tickets contain a shared chain of decisions, though: understand the behavior, select an approach, edit related files, interpret failing tests, and revise. Splitting that chain often creates more interfaces than useful concurrency.

One agent should be the default until concurrency pays

Start with one agent because a coding task usually has one evolving mental model. The agent reads the request, maps it to the repository, makes a change, observes the result, and updates its plan. Each observation changes what the next step should be. Keeping those decisions in one context avoids translating a half-formed understanding into a handoff contract.

A pipeline earns extra agents when work units can proceed independently and merge with little interpretation. Think of generating clients for unrelated APIs, updating isolated packages with separate test suites, or researching several external specifications before implementation begins. The workers need distinct write scopes, explicit outputs, and a merge owner. If two workers may edit the same abstraction or need each other's discoveries, the work is serial even if the runtime launches both processes together.

Anthropic's engineering account of its multi-agent research system draws the same boundary from a different workload. Its system performed well on breadth-first research, where subagents could explore independent directions in separate context windows. The authors also report that multiple agents used about 15 times the tokens of ordinary chat interactions, and they explicitly call out most coding tasks as less parallelizable because agents must share context and manage dependencies. That figure is not a price forecast for your stack. It is evidence that parallel capacity has a real operating cost and must buy a result that one agent cannot produce as well.

Use a simple admission test before adding a worker. Can you define its task without saying coordinate with the other agent, can it work in a separate file or worktree, and can the owner accept its output using a deterministic check? If any answer is no, keep that work with the owner. An agent role is not a reason to create an agent.

Treat orchestration as a tax you can measure

Orchestration cost is the extra elapsed time, model usage, retries, and human attention caused by dividing work. Record it at the run level. A cheaper model call is irrelevant if an engineer spends twenty minutes discovering that the reviewer assessed an obsolete patch.

The minimum useful trace is a tab-separated ledger that every agent and deterministic gate appends to. Keep the header stable:

run_id	stage	agent	started_at	finished_at	status	input_artifact	output_artifact

Use statuses such as ok, failed, retry, and superseded. Artifact fields should contain immutable commit IDs, patch digests, or result file names, not descriptions such as latest branch. With that ledger, a basic shell query exposes how often a handoff fails:

awk -F '\t' '$2 == "handoff" {total += 1} $2 == "handoff" && $6 != "ok" {bad += 1} END {printf "handoff_failure_rate=%.3f\n", total ? bad / total : 0}' runs.tsv

The output has one machine-readable field, for example handoff_failure_rate=0.125. That example only demonstrates the shape; your ledger supplies the value. Add similar queries for wall time, repeated gates, and time from failure to resumed productive work. Do not ask the model to grade its own coordination quality when the runtime can record events directly.

Compare complete task runs, not individual calls. For each ticket, capture time to a reviewable patch, accepted result on the first human review, model and tool cost, human intervention minutes, and recovery time after the first failed stage. Segment by task class and repository. A documentation fix in a small service tells you nothing about a schema migration across a monorepo.

The metric that makes the decision is useful lead time: elapsed time until the change passes its gates and a reviewer can understand it. Multiple agents may reduce raw generation time while increasing useful lead time. That is a loss disguised by a busy trace.

Handoff failures expose missing ownership

A handoff fails when the receiving agent cannot continue correctly from the artifact and context it received. A tool exception is easy to count, but semantic failures matter more: the implementer misses a constraint, the reviewer examines a different commit, the test fixer changes intended behavior, or the coordinator merges a patch whose assumptions no longer hold.

Separate three handoff outcomes in the ledger. A transport failure means the task or artifact did not arrive. A comprehension failure means it arrived but the receiver had to reopen source material or ask for missing facts. A validity failure means the receiver acted on stale or incorrect assumptions. Combining them under retry hides the engineering response. Better queues fix transport; a better contract may fix comprehension; fewer boundaries usually fix validity.

The common response is to make the handoff prompt longer. That works until the prompt becomes a lossy copy of the repository, issue, trace, and prior conversation. It also freezes a moment in a task whose understanding keeps changing. Passing the original artifacts is better than summarizing them, but the receiving agent still has to rebuild why each decision was made.

OpenAI's Agents SDK documentation makes an important distinction between handoffs and agents used as tools. In a handoff, the specialist takes control. In the manager pattern, the manager retains ownership and calls a specialist for a bounded result. Coding pipelines often use a handoff when they need a tool call: ask a specialist to inspect a migration or propose tests, then let the original owner integrate the answer. That single ownership change removes an entire class of stale-state failures.

Count a handoff as failed if a downstream agent must rediscover information that the upstream agent had, even when the run eventually succeeds. Rediscovery consumes time and introduces a chance of choosing a different interpretation. If more than a small, stable minority of handoffs need repair, inspect the task boundary. Do not set a universal percentage. A team that handles routine UI changes and a team that changes payment state machines carry different consequences.

A good handoff contract names the immutable input, the requested output, the acceptance check, and who owns the final decision. If the contract needs a page of narrative to remain safe, collapse the boundary and give one agent the source material.

Duplicated checks reveal fake parallelism

Repeated checks are useful when they provide independent evidence, and wasteful when agents rerun them because they do not trust or cannot see prior results. Two agents both reading the same modules, running the entire test suite, and reconstructing the dependency graph are not parallelizing implementation. They are paying twice for orientation.

Instrument checks by command fingerprint, input artifact, and result digest. Two executions of the same test command against the same commit are duplicates unless the environment or purpose differs. Label the purpose explicitly: author feedback, acceptance gate, security gate, or flaky-test confirmation. This prevents a necessary final gate from being mistaken for waste.

Review is where teams most often defend duplication. An independent reviewer can catch mistakes, but a second general coding agent with the same model, repository view, and prompt family may repeat the author's reasoning rather than challenge it. Independence comes from a different test oracle or focused instruction, not merely another process name. Keep deterministic lint, type, unit, integration, and policy gates outside the coding agent. Then use a specialist only where judgment adds evidence, such as checking a database migration for backward compatibility.

A pipeline that runs every gate after every worker also creates a queueing problem. The slowest suite becomes a barrier between dependent stages, while later agents may repeat it after small edits. Let workers run targeted tests for feedback. Run the full acceptance sequence once against the candidate commit owned by the integrator. If a later edit invalidates that commit, the ledger should show why the gate ran again.

Track duplicate-check time as a share of useful lead time. Also track duplicate orientation: repeated searches, repeated reads of unchanged files, and repeated attempts to identify the same entry point. Tool traces can reveal these events without inspecting private source contents. When duplicate orientation grows, more detailed prompts usually move the cost rather than remove it. One owner reading the code once is the cleaner fix.

Do not remove a check simply because it repeats a command. Remove repeated execution against identical state. A deterministic acceptance gate at the end still matters, even if the author ran the same suite earlier, because the final gate binds a result to the exact artifact you plan to ship.

Context loss costs more than a large context

Context loss occurs when the next decision lacks a fact that a prior stage already discovered. It appears as contradictory edits, reopened files, reverted choices, and explanations that no longer match the patch. Token count can signal pressure, but it does not measure whether the right facts survived.

Create a small decision record beside the run, not inside an agent's prose summary. Each entry should contain the decision, evidence, affected artifact, rejected alternative, and invalidation condition. For example:

decision: keep the legacy response field for this release
evidence: integration fixture billing_v1 expects the field
affected_artifact: src/billing/response.ts
rejected_alternative: remove the field with the new endpoint
invalidate_when: billing_v1 fixture and consumer are retired

This fragment prevents a reviewer or repair agent from treating compatibility code as accidental clutter. It is short because it records a decision, not a transcript. The repository and test output remain the authoritative context.

Measure context reconstruction time directly. Mark the first tool action after a handoff and the first action that changes or validates the candidate artifact. File reads, searches, issue rereads, and repeated test discovery between those events are reconstruction. Some orientation is unavoidable, but it should stay bounded for a supposedly specialized worker.

Summaries are especially dangerous around negative findings. An upstream agent may learn that a tempting module is unused, a test fails before the patch, or a generated file must not be edited. If the handoff preserves only the chosen plan, the next agent can repeat the dead end or misattribute the baseline failure. Decision records should include those exclusions when they change later behavior.

A single agent can still lose context through compaction or a long run. The answer is checkpointing, not automatic multiplication of agents. Save the task goal, current artifact, passing and failing gates, open question, and next action at natural boundaries. Resume the same owner from that state. Add another agent only when a separate context window enables independent work rather than compensating for poor memory discipline.

The sharp distinction is context capacity versus context continuity. Extra agents add capacity because they can inspect more material at once. They reduce continuity because every boundary must transfer meaning. Coding tasks that touch one connected design usually need continuity more than capacity.

Recovery time decides whether the pipeline is operable

Recovery time starts when a stage can no longer make productive progress and ends when work resumes from a known good artifact. Include detection, diagnosis, rollback or repair, context reconstruction, and queue delay. A pipeline that fails rarely can still be a bad production system if each failure strands several agents and forces a restart.

Anthropic's production account describes stateful agent errors as compounding and says its research system needed durable execution, checkpoints, retries, and the ability to resume rather than restart. The same design applies to code, but coding gives you a strong checkpoint primitive: an immutable commit plus external run state. If the pipeline cannot identify which commit each agent read and wrote, recovery begins with archaeology.

Record two recovery measurements. Time to known state ends when the operator can name the last valid artifact and failed boundary. Time to productive action ends when an agent makes the next relevant edit or validation against that artifact. The gap between them exposes context reload and scheduling cost.

Retries need a budget and an owner. An automatic retry is reasonable for a transient tool failure when the input artifact has not changed. It is dangerous for a semantic failure because the same prompt and state can produce a different-looking version of the same mistake. After one bounded retry, route the run to the owner with the failed command, exact artifact, prior successful checkpoint, and changed state.

Use this minimal recovery policy as a starting point:

owner: implementer
checkpoint: immutable_commit
retry:
  transient_tool_failure: 1
  semantic_failure: 0
resume_requires:
  - failed_stage
  - input_artifact
  - last_valid_artifact
  - gate_output

The policy prevents an orchestrator from restarting the whole graph when one worker fails. It also prevents a repair agent from editing an unknown worktree. Adapt the retry count to the cost and idempotence of your tools, but keep semantic retries visible.

One agent often recovers faster because the failure, hypothesis, and working tree remain together. Multiple agents can recover faster only when the pipeline isolates state cleanly and another worker can continue independent work while the failed branch is repaired. If every worker waits at a merge barrier, concurrency has disappeared exactly when you need it.

Run the same tickets both ways

Decide with a controlled comparison, not a meeting about architecture. Select a representative set of completed ticket shapes, remove incidents that require unavailable external systems, and replay each shape through the current pipeline and a single-agent version. Use fresh workspaces and the same model class, tool permissions, repository snapshot, acceptance gates, and stopping rules.

Do not use only clean success cases. Include a task with an ambiguous requirement, a baseline test failure, a cross-file change, a generated artifact, and a failed tool call. Recovery behavior separates a production design from a demo.

For each run, follow this sequence:

1. Pin the input issue, repository commit, environment manifest, and acceptance commands.
2. Start the ledger before any agent reads the task, and assign immutable artifact IDs at every ownership change.
3. Stop when the candidate passes the same final gates, or when it hits the same time and intervention budget.
4. Have a reviewer who does not know the run type assess correctness, scope, and clarity.
5. Compare medians and the worst recoveries by ticket class, then inspect traces behind the difference.

Averages can hide the reason a pipeline feels unreliable. Ten fast runs do not compensate for one run that corrupts shared state and takes an engineer an afternoon to untangle. Keep the worst credible recovery visible beside the middle result. Do not turn a small internal replay into a universal benchmark; it answers which design fits your repository and work mix.

The single-agent version should retain tools and gates. Removing agents does not mean asking one model to improvise every discipline. Give the owner repository search, targeted test commands, an isolated worktree, checkpoint storage, and access to focused specialist calls when a bounded question arises. Preserve the same final acceptance harness.

Run enough repetitions to distinguish a recurring pattern from one odd model path, but do not wait for statistical ceremony before fixing an obvious boundary defect. If traces repeatedly show the reviewer reopening the same files and correcting stale assumptions, that evidence already supports collapsing author and reviewer ownership for that task class.

Define the decision before viewing results. Keep the pipeline only if it reduces useful lead time or materially improves accepted quality, and if its additional cost and recovery tail fit the business value of the work. If it wins only on token throughput, it did not win.

Keep multiple agents for genuinely independent work

Multiple agents remain useful when decomposition produces outputs that can be judged independently. Broad codebase surveys, separate package upgrades, independent test generation against a fixed interface, and research across unrelated vendor manuals can fit. The coordinator should combine artifacts, not reconcile competing interpretations of one changing design.

Look for four properties. Work units have disjoint write scopes. Their inputs remain stable during execution. Each output has a local acceptance test. Failure in one unit does not invalidate the others. The more properties a task lacks, the more the pipeline depends on coordination rather than concurrency.

Latency also matters. Parallel workers can reduce elapsed time when tool waits dominate and the tasks do not share a bottleneck. They do not help when every worker queues on the same test environment, rate limit, database fixture, or merge owner. Measure actual overlap from timestamps rather than assuming simultaneous starts created simultaneous progress.

Use specialists as callable tools when expertise is bounded. A primary agent can ask a security specialist to inspect an authorization diff, a database specialist to assess migration compatibility, or a test specialist to propose missing cases. Return a structured finding to the owner instead of transferring the whole task. This keeps one decision history while still buying a different lens.

Keep a full handoff for a true change of ownership, such as routing unrelated tickets to agents responsible for separate services. The new owner should receive the original task and immutable artifacts, not a coordinator's paraphrase alone. Ownership must be visible in the trace so a person can tell which agent may write and which one only advises.

The hybrid design is often the durable answer: one agent owns the change, deterministic tools enforce policy, and short-lived specialists answer narrow questions. It has more capability than a lonely generalist and fewer semantic boundaries than an assembly line.

Collapse the pipeline without losing its controls

Replace agent roles one boundary at a time. Start with the handoff that has the highest repair time or most duplicated orientation, then let the upstream owner perform the downstream work. Keep its acceptance gate unchanged. This isolates whether the agent boundary added evidence or only ceremony.

Move instructions before deleting runtime components. Reviewer prompts may contain useful repository rules, release constraints, and test commands. Put stable rules in versioned project guidance, encode machine-checkable rules in the acceptance harness, and convert occasional judgment into a callable specialist task. Do not paste every role prompt into one enormous system message.

Preserve separation where it protects production. The coding agent should not silently approve sensitive deployment actions merely because it owns implementation. Human approvals, protected branches, credential boundaries, deployment permissions, and deterministic policy checks sit outside the agent count decision. One agent with broad unchecked authority is simpler but not safer.

Use a migration configuration that makes ownership and gates explicit:

mode: single_owner
owner: coding_agent
specialists:
  security_review: on_request
  migration_review: on_request
gates:
  feedback:
    - targeted_tests
  acceptance:
    - full_tests
    - lint
    - policy
artifacts:
  candidate: immutable_commit
  decisions: run_decisions.yaml

This prevents the common collapse failure where a team removes reviewers and accidentally removes tests with them. The owner may call specialists, but only the candidate commit enters acceptance. If the single-agent run cannot pass a gate, it must repair the same artifact or surface the failure to a person.

Watch the migrated task class for useful lead time, first-review acceptance, intervention minutes, and recovery tail. Also watch for quality signals that the former pipeline uniquely caught. If a focused reviewer consistently finds a class of defect, restore that check as a specialist or deterministic rule, not necessarily as permanent task ownership.

At oleg.is, I use the Team & AI Audit to map agent roles, handoffs, tool costs, and engineering payroll to observable delivery work before recommending a team change. The architecture decision should survive without that service, though: your trace must show where concurrency pays and where it merely spreads one task across more contexts.

The smallest design that preserves throughput wins

Keep orchestration when independent workers create accepted artifacts in parallel and recover without blocking one another. Replace it when handoff repair, duplicated checks, context reconstruction, and recovery consume the time that parallel calls appear to save. Those signals are stronger than opinions about whether agent teams sound more advanced.

Do not compare a mature pipeline with a careless single prompt. Compare the pipeline with one well-equipped owner inside an isolated workspace, backed by checkpoints, specialist tools, and the same acceptance gates. That is the actual alternative.

The decision can differ by task class. A repository survey may fan out to several readers, while the implementation that follows belongs to one owner. An isolated package migration may run beside another, while a schema change and its consumers stay together. Route work according to dependency shape rather than maintaining one architecture for every ticket.

Once the ledger shows that an agent boundary repeatedly loses state, remove it. Once it shows that two workers finish independent outputs sooner with no recovery penalty, keep them. Agent count is a runtime parameter, not an organizational identity.