Parallel agents without branch collisions

Adding another agent does not automatically add another unit of throughput. Two workers can produce two useful changes at once, but they can also edit the same manifest, regenerate the same index, bump the same cache version, or leave the release branch in a state neither one intended.

The useful question is not “How many agents can run?” It is “How many independent ownership lanes exist?” Safe parallelism begins by finding those lanes, then making the shared parts deliberately serial.

§1Parallelise at the ownership boundary

A task is not independent merely because its description sounds different. “Write the guide” and “update the content index” may be two prompts, yet both can touch the same metadata and generated navigation. Conversely, a new guide and a read-only accessibility review can run together because their write surfaces do not overlap.

A strong lane combines three things:

• One bounded outcome: the concrete artifact the lane must leave behind.
• One owned surface: the files or components that lane alone may change.
• One integration contract: the evidence and handoff the integrator will receive.

If any of those is vague, the work is not ready to split. Clarify the boundary before creating another branch or worktree.

§2Map worktrees, ownership, and gates first

The map should make collisions visible before work begins. This example separates two writing lanes and one read-only review lane while reserving the shared release surfaces for a single integrator.

§3Worktrees isolate bytes, not decisions

A separate Git worktree gives each agent its own directory, index, and branch. That prevents one worker’s uncommitted files from appearing under another worker’s hands. It also makes each lane easy to inspect and discard.

But a worktree cannot decide who owns a shared stylesheet, whether two changes imply incompatible behaviour, or which agent is allowed to advance release state. It prevents accidental filesystem overlap; it does not prevent semantic overlap.

§4Issue a lane contract before the prompt

The lane contract is the coordination layer that Git does not provide. It should be short enough to scan before acting and specific enough to stop an agent from “helpfully” editing a neighbouring surface.

copy-usable parallel lane contract

LANE
Name and bounded outcome

WORKSPACE
Dedicated worktree and branch

OWNS
- Exact files, components, or artifacts this lane may change

MAY READ
- Context this lane may inspect but not modify

RESERVED SHARED SURFACES
- Manifests, lockfiles, generators, shared styles, cache versions,
  release state, or any file owned by another lane

ACCEPTANCE
- Observable conditions the artifact must satisfy

HANDOFF
- Focused diff, evidence, open risks, and integration notes

STOP IF
- The useful next change crosses ownership, needs a shared file,
  or conflicts with another active lane

The stop condition matters as much as the ownership list. Without it, an agent that discovers a dependency will often expand its own scope instead of returning the decision to the integrator.

§5Treat shared surfaces as reserved infrastructure

Some files attract collisions because many changes legitimately depend on them. Common examples include a central manifest, package lockfile, global stylesheet, generated navigation, route table, version constant, or release note.

Choose one policy for each shared surface before the lanes start:

• Integrator-owned: lanes provide the new record or instruction; the integrator edits the shared file once.
• Partitioned: the surface has stable, non-overlapping regions with one named owner per region.
• Deferred generation: lanes change inputs; only the integrator runs the generator after all accepted inputs are present.
• Read-only during parallel work: nobody changes the surface until the lanes stop.

Cache versions and release state deserve the strictest treatment. If every lane advances them independently, the final number or status describes merge order rather than reality.

§6Integrate serially, even when creation was parallel

The integration lane is intentionally narrow. Parallel creation ends at the gate; changes cross it one at a time.

1. Freeze the completed lane. No more opportunistic edits after handoff.
2. Compare the diff with the contract. Reject scope drift before it enters the shared branch.
3. Integrate the least coupled lane first. This keeps later conflicts small and meaningful.
4. Update shared surfaces once. Apply manifest entries, generators, and cache changes from the combined truth.
5. Check the combined behaviour. Lane-level evidence proves each part; integration evidence proves the parts still work together.
6. Record the new state. Close the accepted lane and make the next owner explicit.

This is where a compact handoff packet earns its keep. The integrator needs the state, evidence, boundaries, and remaining risks—not the lane’s entire conversation.

§7Watch for coordination that only looks parallel

• Different branches, same directory: uncommitted state still collides before Git can help.
• Different files, same concept: two lanes encode incompatible assumptions across separate surfaces.
• Every lane runs generators: derived files become noisy merge conflicts instead of a single consequence of accepted inputs.
• Every lane bumps a version: cache state advances without a coherent combined release.
• First finisher becomes integrator: ownership changes according to timing rather than judgment.
• Agents merge each other: no one retains a clean view of the intended final state.

When two lanes keep discovering the same shared decisions, they are probably one task. Merge the work plan before merging the branches.

§8Do not parallelise the critical decision

Parallel agents are useful for independent production, inspection, research, and bounded experiments. They are a poor fit when the next step depends on one unresolved architecture choice, one evolving schema, one global design decision, or one scarce release surface.

Sometimes the fastest coordination plan uses one agent until the critical choice is settled, then fans out. Parallelism is a shape of the work, not a target number of workers.

§9A five-minute launch sequence

1. List the desired artifacts, not the available agents.
2. Draw the write surfaces and circle every shared or generated file.
3. Combine coupled surfaces into one lane.
4. Assign one worktree, branch, owner, acceptance set, and stop condition per write lane.
5. Reserve shared surfaces and release state for the integration lane.
6. Start the lanes, collect bounded handoffs, then integrate serially.

The result is not maximum concurrency. It is useful concurrency: independent progress that still produces one understandable final state.