Parallel agents stay separable when each assignment owns a named branch and worktree, shared-file conflicts are declared before editing, and cleanup never occurs from an inferred status message.
Bind one assignment to one branch and worktree
Git worktree allows multiple working trees to share one repository while checking out different branches. Record the assignment ID, branch, absolute worktree path, base revision, owner, created time, and expected merge target before editing begins. Do not infer ownership from a process name. A restarted agent should recover the recorded assignment rather than create a second branch for the same task.
Confirm that the proposed branch and worktree are unused. Capture the starting status and untracked files so pre-existing changes remain visible. Agents should not delete, reset, or rewrite work they did not create. A cleanup action needs an accepted or stopped assignment, preserved output, known merge disposition, and explicit authority from the repository owner.
Declare shared surfaces before edits collide
A dependency graph should list files, schemas, generated indexes, lockfiles, migrations, and central registries likely to be touched by more than one assignment. Give one task temporary ownership or sequence those edits. When parallelism is still useful, isolate independent source changes and defer the shared generated artifact to a single integration task after upstream branches are accepted.
Detect overlap from actual changed paths as work proceeds. A collision record should identify both assignments, their base revisions, overlapping files, dependency relationship, and permitted next step. Pausing one task can be safer than allowing both agents to resolve a semantic conflict without context. The manager, not the faster agent, chooses which change becomes the integration base.
Revalidate after integration changes the revision
A clean local test does not travel automatically across a rebase or conflict resolution. After integration, rerun the checks that depend on changed shared files and record them against the new commit. GitHub rulesets and required checks provide repository-side controls, but the fleet ledger should also preserve which assignment evidence became stale when the merge candidate changed.
Fleet Completion Control is installed by Reality Contact, LLC. The buyer approves branch naming, path ownership, integration order, cleanup authority, and merge policy. The system warns about recorded overlaps and stale evidence; it does not prevent every semantic conflict, delete worktrees, resolve disputed changes, or merge any branch without buyer action.
Where the service stops
Reality Contact, LLC installs bounded completion and evaluation controls but does not manage the buyer's staff, declare disputed work correct, merge or deploy changes, delete worktrees, reassign tasks, or operate the fleet indefinitely. The buyer defines completion and review authority, approves rubrics and stopping rules, resolves disputed judgments, controls repositories and credentials, and authorizes every merge and deployment. This is technical implementation, not legal advice. Automated evaluation supports named criteria; final technical, security, legal, and production decisions remain with the buyer. We do not promise conflict-free parallel work, correct grader judgments, successful merges, or coverage beyond the accepted sources, criteria, and scenarios.
Sources: Git documentation for git worktree; GitHub documentation for repository rulesets.