Keep parallel coding agents from colliding

The fastest way to keep parallel coding agents from colliding is to give each one a written scope before it starts: the files it owns, the files it must not touch, how to verify, and who merges it. Parallel coding agents are several agent sessions, in Cursor, Anysphere's AI code editor, or any CLI, editing the same repo at the same time. Two of them in one module is not double the speed. It is a race condition with commit access, where whichever lands second quietly rewrites the first.

That collision has a tell. The expensive bug is the one nobody can explain: "we cannot say why the agent chose this." When the answer lives only in a chat window, you cannot review it, and you cannot keep two streams out of each other's way.

Give each stream a scope ledger

A scope ledger is five lines that travel with the parent chat: goal, allowed paths, forbidden paths, verification command, merge owner. Write it before the session runs.

The point is to make conflicts visible on paper. If two ledgers both claim src/billing/, you see the clash before either agent writes a line of code. That is a lot cheaper than finding it in a diff at 5pm.

Tighter prompts do not save you here. During crunch weeks, summaries shrink to bullet vibes and streams keep meeting in the same files. A prompt is a wish. A ledger is a contract the repo can hold you to.

# Scope ledger: payment-retry agent
goal: add exponential backoff to failed charge retries
allowed:    src/billing/retry/**, tests/billing/retry/**
forbidden:  src/billing/ledger/**, any migration files
verify:     pnpm test billing/retry && pnpm type-check
owner:      @rogier merges

The Cursor agent docs explain how the agent works, not how to split lanes between two of them. That split is yours to write down.

Put precedence in CLAUDE.md, not in muscle memory

When several sessions run at once, bash approvals turn into reflex at every desk. Click, click, click. Permission creep is how a sandboxed agent ends up touching a folder it had no business in.

The fix lives in shared policy, not per-machine habit. The top of CLAUDE.md should state which hooks win, which folders need human eyes, and where temporary overrides go. The Claude Code getting started guide wires hooks per machine, so the precedence rules have to live in the file every stream reads.

For Codex CLI, OpenAI's coding agent, the same job falls to AGENTS.md. Parallel CLI runs are easy to spawn, which is the appeal and the trap: they merge greens nobody can replay. Make AGENTS.md require an intent line, then the command transcript, then a diff summary before any PR. When two streams touch neighboring code, reviewers compare transcripts instead of memories.

Steward your connectors before the second stream starts

A connector wired for one agent serves all of them. An MCP server with write access is shared, unowned capability the moment a second session can call it, and that is exactly when the blast radius stops being theoretical.

Give every server a card: allowed actions, forbidden actions, owner, rollback. One markdown file per connector, a named steward before anyone parallelizes. The OWASP Top 10 for LLM applications is the reading list for what unowned shared capability costs you.

Here is the whole lane-marker policy in one file you can adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

This is the least glamorous part of agentic coding governance, and it is also the sharpest test of whether a tool holds up under several streams at once.

Run a merge gate that reads from files

Before a parallel stream merges, ask four questions, all answerable without replaying a chat. If you cannot answer one from the PR alone, the stream is not ready.

Turn that into a checklist the author runs before opening the PR:

• Verification command output is pasted or linked.
• Forked agent work lists parent plus child responsibilities.
• Red-folder paths received explicit human acknowledgement.
• Scopes in the PR body match folders in the diff.

None of this replaces architecture judgement. Agents speed up execution, never ownership. The NIST AI Risk Management Framework would file lane assignment under governance; a tech lead files it under not doing the same work twice.

Common questions

• How do parallel coding agents avoid merge conflicts? By partitioning scope before the sessions start. Each agent gets a ledger naming goal, allowed paths, forbidden paths, verification command, and merge owner, so two streams claiming the same path conflict on paper instead of in the diff. Whatever still collides surfaces at the merge gate, with transcripts a reviewer can actually read.

• How many agents can one engineer supervise? As many as have honest receipts, and no more. The binding constraint is review bandwidth: every stream produces a diff someone must be able to defend. When your summaries shrink to bullet vibes, you have passed the limit, whatever the session count says.

• What is a scope ledger for agent work? Five lines in the parent chat: goal, allowed paths, forbidden paths, verification command, merge owner. It is the smallest artifact that makes a delegation inspectable, and in parallel work it doubles as the lane assignment that keeps streams out of each other's modules. Write it before the agent runs, not after.

• Why not just use tighter prompts instead? Because a prompt cannot bind a repo and a ledger can. Prompts decay under deadline pressure, and two well-prompted agents can still both believe a module is theirs. Scope written into a file is something every stream inherits and a reviewer can check against the actual diff.

Start with tomorrow's two streams

Write two scope ledgers tonight for the two streams you plan to run tomorrow, before either starts. The first path conflict you catch on paper pays for the habit, and you can build the rest of the gate from there in our training.