Parallel Agents Need More Than Separate Branches

Parallel agents need explicit ownership of the resources they can change, including those outside Git.

Two branch names do not give two processes separate working files. For simultaneous edits, give each agent its own checkout or worktree. That removes one source of interference. It leaves the test database, development ports and deployment target exactly where they were.

I would delay parallel execution until each shared mutation has an owner or a deliberately isolated target. Discovering the shared database halfway through a test run is an expensive way to document the arrangement.

What a worktree separates

The Git worktree manual describes linked working trees with their own HEAD and index. They still share repository data, including most refs; repository configuration is shared by default. A worktree is useful precisely because it separates ordinary working files without requiring a wholly separate repository.

In the earlier Gluon cockpit article, the claim that worktrees confine damage to a branch was too broad. Separate working directories prevent agents from accidentally editing the same checkout. They do not confine what those processes can access. A process with credentials for a shared database can still change it, whichever branch it checked out.

Filesystem restrictions and scoped service permissions address that different requirement. Naming an owner in a prompt is coordination; preventing other agents from writing requires enforcement outside the prompt.

Allocate the resources before the files

Consider a synthetic example: adding a category filter to a search page. Agent A handles the UI. Agent B handles the API. One integration owner agrees the contract before either starts: an optional category query parameter restricts results; omitting it returns all matching categories. The response shape stays unchanged.

That agreement gives the agents something stable to implement against. Each receives the same base commit and a bounded assignment:

These allocations are a proposed design, not capabilities supplied by Git. The ports must actually be available, and each test runner must point at its assigned server. If a port is already occupied, allocate another and update the test target. Connecting successfully to someone else's server would make a misleading test result.

For this small task, I would keep dependency updates with the integrator. Both workers can request a package, but neither needs to independently rewrite the shared dependency decision. That is a local simplification, not a claim that parallel dependency changes are impossible.

The stop condition matters as much as the assignment: if either worker needs to change the query contract or another owner's files, it returns that decision to the integrator. It can continue independent work while the question is resolved. Quietly changing category to categoryId would invalidate the other worker's starting assumption.

A namespace still needs rules

The fixture allocation is easy to write and easy to undermine. Agent B's test setup must write only to its assigned namespace. A cleanup operation that ignores the namespace can interfere with another run even when every source file lives in a separate worktree.

A namespace convention also does not restrict credentials. If the test account can write to every namespace, correctness still depends on the test code respecting the convention. Use a separately scoped account or isolated test service when the required boundary must be enforced. If the resource cannot be safely partitioned, assign one writer and serialize its use.

Keep that distinction when adding orchestration controls. GitHub Actions concurrency groups coordinate matching jobs or workflows within a repository. They do not lock a database against a developer's shell or a workflow in another repository. The control only covers the writers that participate in it.

Check the interface after combining the changes

Agent A can pass UI tests against a mock. Agent B can pass handler tests against fixtures. Their commits can merge without conflicts while the combined page still sends the wrong parameter.

The integrator therefore needs a check that crosses their boundary. For this example, seed the dedicated fixture store with results from two categories. Open the combined application's search page, choose one category, and verify that the request reaches the real handler with the agreed parameter and that only matching rows appear. Clear the filter and verify that results from both categories return. Mock unrelated providers, but do not mock away the interface this check is meant to exercise.

That is a proposed acceptance check, not a report of tests run. Its evidence should identify the combined commit, fixture configuration and server target. Individual results remain useful for diagnosing a failure; they do not establish that this combined candidate passed.

Before assigning the next pair of tasks, name their shared write targets alongside their files. If both need the same unpartitioned fixture store, let one finish that part first. They can still work concurrently on the parts whose ownership is clear.