Multi-agent coding: parallel work and review

Run more than one coding agent on the same repository only when each writer has a separate working directory, a non-overlapping file scope, and one owner who integrates the result. Start smaller than that: one agent implements a change, and a second reviews it. Add concurrent writers when the tasks can proceed without each other's unfinished edits.

Git worktrees↗ are the usual directory split. A linked worktree shares the repository and gives that checkout its own HEAD and index. Claude Code's own description of sessions↗ ties each conversation to a directory and points at worktrees for parallel sessions. A desktop workspace can create those directories for you. The isolation that matters is the separate checkout, not the button that created it.

A worktree is not a sandbox. It does not isolate ports, databases, credentials, or processes. Copying the same environment file into each worktree does not create a second database. File checks, and any environment files a harness copies in, are that harness's policy, not a boundary around the machine.

Example. A feature needs an API change, a UI, and docs. Agree the response shape first, such as { id, title }. One agent implements the handler. Another builds the UI against that shape. Write the docs from the behavior that actually merged. If the handler returns { id, title }, the UI reads an array, and the docs describe { items: [] }, each piece can look finished until one check runs on the combined tree. That combined failure is the reason one owner integrates.

Choose tasks that can proceed independently

Split work on stable inputs. An interface can proceed against an agreed API contract. Documentation should follow the behavior that ships, not a draft shape that another agent is still changing.

For each task, record:

• The intended outcome and acceptance criteria.
• The files or subsystem the agent owns.
• The inputs it can assume are stable.
• The changes it must coordinate with another owner.
• The evidence required when it returns.

If two agents need to redesign the same interface, settle that decision before asking them to implement competing assumptions.

Give concurrent writers separate workspaces

Separate Git worktrees let agents edit different working directories and branches. They reduce accidental interference between simultaneous edits. A linked worktree still shares the repository: refs and configuration are shared, and each worktree keeps its own HEAD and index. Git will not check the same branch out twice unless that safeguard is forced. Submodule checkouts are a poor fit for this pattern. Git's own manual calls that support incomplete.

Before starting two development servers, assign distinct ports. Keep credentials and shared services scoped deliberately. If both use the same port, the second server can fail to bind and then run its checks against the first server. Before running migrations, decide whether each task has its own database. Before integration, inspect both branches for changes outside their assigned scope.

A reviewer needs a stable version of the change. Freeze the diff during review or identify the exact commit being reviewed. Findings against a moving checkout can become stale before the reviewer finishes.

Give coordination an explicit owner

Someone must decide when a prerequisite is ready, resolve conflicting assumptions, and accept the final result. That can be the developer or an agent working under a bounded set of instructions.

OpenScout gives existing coding agents a shared coordination layer. A request for owned work uses an ask; a status update uses a tell. The returned reference lets you inspect the original request and continue it. A receipt establishes acceptance of the request; completion requires a finished result.

For an executable first workflow, follow the Claude Code and Codex review guide. It covers asking for a review, waiting for findings, and following up in the same conversation.

Integrate the results deliberately

Have each worker return its change, a short explanation, checks performed, and unresolved issues. Review that evidence before integrating. Run the relevant checks again on the combined result. Two changes that pass separately can fail together: an API that returns { id, title }, an interface that reads an array, and docs that describe { items: [] } can each look finished until one parse check runs on the merged tree.

Keep integration under one owner so agents do not independently merge competing branches or alter the same shared environment. If a task is blocked, inspect its existing request before launching a replacement that might duplicate work.

When to keep the workflow smaller

One agent is often sufficient for a tightly coupled edit or a task that takes longer to explain than to complete. An independent reviewer can still be useful. Increase concurrency when you have separable tasks and enough capacity to assess the output.

OpenScout is intended for high-trust local developer pilots. Each agent's provider usage and permissions still apply; coordination does not replace review or the underlying harness's safeguards.

Start with one handoff

Connect Claude Code or Codex, then try a focused review before adding more workers. For the broader design choices, see AI agent orchestration.

References

• Git worktree documentation↗: shared repository state and separate working trees.
• Agent-to-agent communication: requests, updates, and following the same work.

Estimate the coordination effort

Try the coordination cost estimator with your own assumptions for briefing, execution, review, and rework. The result is an illustration, not a measured productivity claim. The budget boundaries guide explains what usage alerts and enforced limits actually control.