AI Coding Agent Orchestration: Gate Every Merge by Evidence

Parallel coding agents should not merge because every session says “done.” The reasonable default is stricter: give each mutating agent an isolated worktree and branch, declare what it may change, and admit its branch only when checks, review, base freshness, and a deliverable receipt all refer to the exact head commit. That is the operational core of AI coding agent orchestration . The orchestrator can schedule work and display activity, but merge readiness is an evidence decision. A branch may be working, legitimately waiting, blocked, stale, out of scope, or complete but unverified. Collapsing those states into finished is how parallelism turns into silent integration failure. This guide builds a content free merge receipt and replays eight cases against it. The result is deliberately inconvenient: only one case is ready. The others preserve the reason to wait or reject instead of hiding it behind a green session badge. Orchestrate for merge admission, not session completion The current tool landscape makes parallel execution easy. The VS Code team describes local, background, and cloud agent modes in version 1.109; its background agents use worktree isolation, while parallel subagents keep exploration out of the main context. The open source Agent Orchestrator project similarly puts coding sessions in isolated worktrees and routes CI failures, review comments, and merge conflicts back to the relevant session. Those are useful execution properties. They are not, by themselves, a merge verdict. Git’s git worktree documentation explains the important boundary. Linked worktrees share repository data, but each has per worktree state such as HEAD and the index. Git also refuses to check out one branch in multiple worktrees unless safeguards are overridden. That prevents a class of filesystem and index collisions. It does not prove that two patches are compatible, that an agent stayed inside its assignment, or that yesterday’s test result applies to today’s head. Use one receipt per candidate branch: The identifiers are synthetic. No prompt, source file, secret, diff, or test log is required. The receipt carries only the minimum facts needed to decide whether the exact branch head can advance. Five checks make the default useful: 1. Isolation: the worktree and branch belong to one active mutating session. 2. Ownership: every changed path is inside the declared assignment. 3. Freshness: the candidate is based on the expected base, and every check refers to its current head. 4. Review: an approval applies to the same head, with no unresolved request for changes. 5. Outcome: a deterministic artifact proves the requested work, not merely command completion. GitHub’s protected branch documentation supports the middle of this contract: branches can require reviews and successful status checks, and strict checks can require a branch to be current with the base. The outcome receipt extends that mechanism. A successful build proves that a build command passed; it does not necessarily prove that the requested export exists, the API contract works, or the user visible behavior is correct. Run the eight case merge readiness audit I encoded the contract in a small Node.js classifier and replayed eight branch receipts. The fixture uses one current base, two required checks, and no repository content. Run it with: The classifier applies the gates in this order: Order matters. A legitimate wait should not become a failed build simply because checks have not started. Scope drift should stop the branch before expensive evaluation. Stale evidence should not be reinterpreted as a current failure: it says “rerun against this head,” not “the code is broken.” The experiment produced one verdict in each category: Case Verdict Decisive evidence Complete branch merge ready Current head, owned paths, fresh checks, approval, verified artifact Shared workspace isolation failed Another mutating session owns the workspace Extra auth edit scope drift src/auth.ts is outside the docs assignment Schema decision waiting Named reviewer, reason, and deadline are present Old merge base stale base Candidate saw base 101 ; current base is base 104 New commit after CI stale evidence Checks and review belong to cli 8 , not cli 9 Requested changes review blocked Review applies to the head but is not approved No deliverable proof outcome unverified Build and test pass, but the requested result is unverified This is a stronger operational result than “seven failures.” The schema case is not failing; it is waiting on an explicit decision. The stale check case may contain perfectly good code; its evidence is about the wrong commit. The missing outcome case may have passed every generic test while still failing the task that justified the branch. The audit is falsifiable. If the classifier marks any incomplete case ready, the thesis fails. If it refuses the complete receipt, the contract is too strict or incorrectly implemented. In this run, exactly one of eight cases became merge ready . Bind every green signal to the candidate head The most reusable rule from the fixture is simple: Suppose an agent passes CI at commit cli 8 , then makes a small “cleanup” commit cli 9 . A dashboard may still display green checks and an approved review. The correct state is not green and not red. It is stale evidence. Rerun the affected checks and renew the review or use a platform mechanism that invalidates approvals when the reviewed diff changes. Apply the same identity binding to the deliverable. Useful receipts include: a contract test that calls the new API and validates its response; a generated artifact hash plus a decoder or parser check; a browser assertion against the integrated route; a migration rehearsal against a disposable database; a package import and smoke test from the built package, not the source tree; a destination lookup proving that an external effect reached the intended record. Avoid an LLM summary as the only outcome receipt when the result is deterministic. A coding agent can confidently say it created a file that is absent, ran tests that were later invalidated, or fixed a review comment on a different branch. Prefer direct inspection. Use a model judge only for properties that cannot be checked mechanically, and record the judge version, rubric, input identity, and uncertainty. Waiting also needs identity. Record the owner, reason, deadline, and resume condition. “Waiting for review” without an owner can sit forever. “Waiting for platform reviewer until 12:00 UTC to approve schema compatibility; resume at schema 3 ” is actionable and should stay out of the failure queue until its deadline or evidence changes. Know where the gate stops Path ownership is an early filter, not semantic conflict detection. Two branches can edit different files and still disagree about a shared type, event schema, generated client, migration order, feature flag, or API behavior. Worktree isolation prevents concurrent file state collisions; it cannot prove that independently correct patches compose. Therefore, run a final integration gate against the actual merge candidate: 1. update or recreate the candidate from the intended base; 2. combine the approved changes without bypassing conflicts; 3. run the required checks against the combined head; 4. repeat the deterministic outcome verification; 5. attach the resulting evidence to that combined head; 6. require human approval for the merge or any irreversible recovery step. This adds work. Strict base freshness can also cause repeated rebuilds while other branches land. GitHub documents that trade off: strict required checks improve base alignment but can require more builds; loose checks reduce rebuilds but may allow incompatibility to appear after merge. Choose the policy by failure cost, not by a desire to keep every agent busy. The merge contract also does not replace code review, security review, deployment controls, or incident response. It gives those systems a trustworthy candidate identity and a clear reason when work is not ready. Sidewisp is currently in private preview. Its product direction is a health layer around existing agent runtimes, with useful progress, waiting, tool, and outcome evidence kept distinct; production agent health collection and recovery adapters are not generally shipped. If you operate parallel coding agents, this merge receipt is the kind of bounded health contract worth testing now—before adding autonomous intervention. The final rule is intentionally conservative: an agent stopping is activity; a head pinned, reviewed, outcome verified branch is progress that may be approved for integration.