Parallel agents should not edit the same checkout at the same time. A worktree gives each task a separate working directory while sharing repository history. That is a useful primitive, but it does not eliminate integration conflicts or turn a host into a sandbox.
Isolate the working directory
Give each active task a known base commit and its own worktree. Record the task identity, checkout location, and resulting change commit. Avoid depending on whichever branch happens to be open in a developer's main checkout. The runner should be able to explain where a change came from after the process exits.
Local isolation also makes cleanup more precise. A failed task should not require deleting an entire repository or resetting the developer's working directory. Cleanup decisions should target only task-owned paths and preserve evidence needed for diagnosis.
Own paths explicitly
Two tasks can have separate directories and still modify the same shared configuration file. Planning should account for owned paths and dependencies. If both tasks need to change an API contract, a sequential dependency may be safer than treating them as independent work.
Integration is its own verification boundary. Two changes that pass tests separately may fail when combined. Run appropriate gates against the integrated result, and keep its commit identity distinct from the individual task commits.
Do not confuse worktrees with containment
A process in a worktree still has the operating-system permissions of the runner. It may access other directories, networks, or a Docker daemon if those capabilities are available. Use host and container controls for execution security; use worktrees for checkout isolation.
Repository traversal also needs care. Context collection should prune Git metadata before descending into it. Filtering metadata paths only after traversing them can read irrelevant data or race temporary lock files. A context builder should select useful source deliberately and apply size limits.
A good parallelism test
Create two tasks with non-overlapping paths, integrate both, and run the combined gates. Then test overlapping paths and confirm the scheduler does not assume they are independent. Include cancellation and restart cases. Parallelism is valuable only when the coordination system can still explain ownership and reproduce the result. See the harness architecture discussion.