VAMSHI.

Agentic Engineering

Parallel Agents Need Isolation, Not Just More Agents

A field guide to deciding what should run in parallel, isolating writes, and designing handoffs that are cheaper to verify than to redo.

5 min read
multi-agent systems coding agents git worktrees orchestration software engineering
A primary agent delegates independent exploration, testing, and implementation tasks before integrating their evidence-backed handoffs.

Three agents can finish a task faster than one.

They can also search the same files three times, make incompatible assumptions, edit the same lockfile, and leave the primary agent with a merge conflict disguised as progress.

Parallelism is useful when the work is independent. Agent count is not a strategy.

Run the independence test first

Before delegating a branch, ask five questions:

  1. Can it make progress without waiting for another branch?
  2. Can it own a narrow question or artifact?
  3. Can its result be verified independently?
  4. Can it avoid writing to the same files as another branch?
  5. Is the expected time saved larger than the coordination cost?

If the answer is no to several of these, keep the work in one thread.

Good parallel work includes codebase mapping, security review, test-gap analysis, log triage, documentation research, and changes behind stable module boundaries. Poor parallel work includes choosing one architecture, rewriting a central type, modifying a shared migration, or iterating on one tightly coupled user flow.

Parallelize discovery before implementation

For a large authentication bug, a useful first split might be:

  • one agent maps token creation and refresh
  • one reproduces the failure and finds missing tests
  • one reviews recent auth changes and security implications

Each returns a short evidence-backed memo. The primary agent reconciles the findings and decides the implementation boundary.

Only then does it make sense to split writing work—perhaps one isolated server change and one client-side test update.

This order matters. If three agents begin coding before the system agrees on the failure, they encode three interpretations into the repository and call the conflicts “integration.”

The primary agent is an editor, not another worker

The coordinating agent should preserve the goal, constraints, and decisions. Its responsibilities are different:

frame the task
  → assign bounded ownership
  → resolve shared questions
  → inspect returned evidence
  → integrate in a deliberate order
  → run end-to-end verification

The primary thread should not fill with every search result and test log. Subagents should return conclusions, artifacts, and uncertainty. The coordinator needs enough detail to challenge the work, not enough noise to repeat it.

OpenAI’s subagent guidance recommends a similar starting point: parallelize read-heavy exploration, tests, triage, and summarization before attempting write-heavy workflows. It also notes the economic fact that every subagent performs its own model and tool work. Faster wall-clock time can mean higher total cost.

Isolate writes with worktrees

Two agents writing in one checkout create hidden shared state.

One agent changes a base type while another compiles against the old type. Both update a generated client. A test passes only because the working directory contains a mixture of their changes. Git shows a diff, but it no longer shows clear ownership.

A Git worktree gives each writing agent its own directory and branch. That does not eliminate merge conflicts. It moves them to the correct place: an explicit integration step where the coordinator can see competing changes and choose an order.

Use one worktree per write-heavy task when:

  • branches can be reviewed independently
  • the work may run for a while
  • generated files or lockfiles may change
  • a failed branch should be easy to discard

Do not create a worktree for every two-minute read-only check. Isolation has cleanup and coordination costs too.

Make handoffs verifiable

“I investigated the auth flow” is not a handoff.

A useful handoff answers:

Owned question:
Starting revision and assumptions:
Finding or artifact:
Evidence:
Commands or checks run:
Uncertainty and risks:
Dependency on other branches:
Recommended next action:

For a code change, return a commit or diff and the tests that failed before and passed after. For research, cite file locations and distinguish observation from inference. For a blocked task, state the smallest decision required to continue.

The handoff should be cheaper to verify than to redo. If it is not, delegation has merely relocated the work.

Merge in dependency order

Suppose three worktrees contain a shared type change, a server implementation, and client tests.

The safe integration order is rarely “merge whichever agent finished first.” Merge the shared contract, rebase or update dependent branches, merge the implementation, then run the client tests against the integrated state. Finish with the repository’s end-to-end checks.

The coordinator owns this global verification. A passing test in three isolated branches does not prove the combined system works.

Know when one agent is better

There is a useful counterweight in the research. Agentless approaches have shown that careful localization, repair, and validation pipelines can perform competitively on software-engineering benchmarks without elaborate agent orchestration.

The lesson is not that agents are unnecessary. It is that orchestration must earn its complexity.

Use parallel agents when they reduce elapsed time or protect the main context on genuinely separable work. Use one agent when the task depends on a single evolving mental model.

The unit to optimize is not agents running. It is verified work integrated.

Further reading