I would first ask what the agents are allowed to return. If they all write into one checkout, a green test has no clear meaning: another agent may have changed a file halfway through the run. Give each agent an isolated worktree or checkout from a recorded base commit. Its output is a patch and a description of the behavior it intended, not a change that has already landed. Git supports multiple worktrees, but worktree isolation alone does not isolate a shared test database, generated files outside the tree, or deployment credentials. Those need their own boundaries too.

Before splitting work, identify the contracts that cross the tasks. Suppose one agent changes an authorization helper and another updates a caller. If both can change the helper, nominate one owner for that interface and have the other work against an agreed signature or wait for the first patch. Independent UI copy and a parser fix can proceed together. A cross-cutting schema migration probably cannot be split into ten independent patches just because it touches ten folders. File ownership helps avoid clobbering. It is not proof of semantic independence.

I would keep a small integration record for each proposal: base commit, changed paths, dependencies on other proposals, patch hash, tests run and their environment, and what behavior the agent thinks changed. The description matters. A diff that applies cleanly may still alter the meaning of a function another patch relies on. The integration owner can see whether a patch was built against a contract that no longer exists.

Merge order follows the dependency graph. Land the shared contract first, then rebase or regenerate the callers against it. Independent proposals can be prepared in parallel, but acceptance into the protected branch goes through an ordered gate. The gate applies a candidate patch to the latest accepted tree, flags any textual conflict for reconciliation, and tests that candidate tree. GitHub's merge queue checks a merge group against the latest base plus changes ahead of it. The same principle applies if the team builds its own integrator.

Now the interviewer points at the agent whose tests passed before a second agent changed a shared file. I would not call that result a pass for the combined code. The result belongs to the earlier commit, command, and environment. Re-run the affected tests on the combined commit, including the caller and the shared module. If the change crosses authorization, persistence, or a public interface, run the integration and required repository gates too. A test log without the tested tree's identity is almost useless here.

There is a subtler case: no merge conflict and both agents' unit tests stay green. Agent A normalizes account IDs in a parser. Agent B adds an access check elsewhere that expects the original casing. The patches edit different files. The integrated behavior is still wrong. I would ask the agents to name invariants before writing tests: does authorization use the canonical account ID, and which component owns that canonicalization? Then test that interaction on the merged tree. Overlap is about behavior and shared dependencies, not only diff hunks.

What if both patches change the same helper and each has a reasonable implementation? I would stop automatic integration there. Ask for one reconciled design and have an agent or reviewer produce a new patch against the current tree. Blindly choosing the patch with more passing tests favors whichever tests happened to be written. A conflict resolver can propose a combined change, but it needs the original requirements and must pass the same integration gate. The agent that lost the merge may have useful tests even if its implementation is discarded.

Then the interviewer asks whether a merge queue will slow fifty agents to a crawl. Possibly. Parallelize work that really is independent and use affected-test selection for fast feedback, but keep required checks on the exact tree being accepted. Batch compatible patches when the integration risk is understood. Measure how often agents have to rebase, how long they wait in the gate, and how often a green branch turns red when combined. If that waste is high, reduce concurrent edits to shared contracts or change the task split. Adding agents does not increase the repository's integration bandwidth by itself.

The success condition is a tested integrated commit with a reviewable explanation of what changed. Individual agents' test results are evidence about their proposals. They are not transferable certificates for code that never existed in their worktree.