Two Sessions on One Backlog
In one line: two agent sessions working the same backlog from separate checkouts with no shared memory buy a second read-reach — the one thing a single session cannot obtain from itself, however careful it is.
What: a second full session — not a subagent — runs concurrently against the same issue tracker and the same remote, from its own checkout. Neither can read the other's context. Each claims issues from the shared backlog, works them in its own git worktree, and opens pull requests into the same mainline. Coordination happens through the artifacts: issues, pull requests, reviews.
This is not §5.4. A subagent is dispatched by a controller, inherits a brief the controller wrote, and reports back into the controller's context — so the controller's blind spots propagate down. A second session has no such parent. It read different files, ran different commands, and formed its own picture of the same repository.
Why: because of a limit on what a negative control can prove.
A negative control proves a mechanism within the guard you looked at, and says nothing about the guard you did not read.
A session that mutates its own change and watches the test go red has proved what it examined (appendix-a §14). It has proved nothing about the consumer it never enumerated, the second writer it did not know existed, or the caller in a module it had no reason to open. That gap is a property of the reading, not of the code — which is why it is undetectable from inside. More care does not close it; more diligence searches the same neighbourhood harder. Only a reader who arrived by a different route closes it.
This is the §7 gate-admission rule turned on the reviewer: a guard verified only where it passes is indistinguishable from a guard that cannot fail, and a reading verified only by the reader who made it is indistinguishable from a complete one.
Evidence — measured on the flagship project over one working period, 2026-09-07:
| Observation | Count |
|---|---|
| Paths in the merge instrument where an unreadable answer was read as green — found by the other session, in the instrument being used to merge at the time | 5 |
| Merges stopped after an independent re-reading (a missing retention guard; a register change that would have turned the mainline red) | 2 |
| Completed, tested and mutation-checked fixes that proved to be regressions on enquiry and were never committed | 1 |
The third is the most instructive, because it shows what the pattern catches before code lands. One session had a correction ready for a fabricated-value defect: written, tested, mutation-checked. It did not commit — it asked first, because the change touched a decision the other session owned. The enquiry established that the fix would have raised a high-severity finding on every clean case, and that the verdict layer requires zero open high findings to release. A correction to a false clear would therefore have blocked every release in the product. It was rewritten before the first commit.
Two further properties, both measured rather than assumed:
- The blind spots are not correlated. Both sessions reported a wrong measurement on the same day — one concluded that no workable merge order existed, the other that a guard fired nowhere. Both were instrument faults, and each was refuted by the other with a counter-measurement rather than an opinion.
- It corrects the review layer too. Adversarial bot review (§7.7) is a third reader, and it also misses things: one finding it had explicitly rejected proved real on re-measurement. Two independent readers catch what one reader plus one reviewer does not.
The cost is review load, and it is visible. On the same project the heaviest pull requests of that period carried 28, 11 and 8 review rounds. The effort moves from producing to adjudicating. Budget for that explicitly; a team that plans this pattern as twice the throughput has mispriced it.
How — three rules:
- One issue, one session. An issue is claimed by exactly one session and the git worktree is the isolation boundary. Two sessions committing into one worktree corrupt each other's index; this is a recorded failure, not a hypothetical.
- Repeat every load-bearing exchange on the issue or the pull request, with the measurement attached — so a human can re-derive it rather than take it on trust.
- Disagreement is settled by counter-measurement. Neither session outranks the other; a claim that survives only because nobody re-measured it has not survived anything.
Declared gaps, stated rather than implied:
- Rule 2 is asserted, not mechanized. The sessions do have a direct channel, and nothing forces an exchange onto the board. Measured: one closed pull request whose reason exists only in that channel — read from the tracker, it is a closure with no stated reason. Every merge, review and finding is on the board; the intermediate reasoning is there by discipline. Wiring that repetition into the pipeline is the obvious next mechanism and does not exist yet.
- The pattern is recent. These figures cover one working period, not the project's life. §7.7's adversarial-review measurements span months; these do not, and should not be quoted as if they did.