Everything found so far.
As it comes in.

A tension with little evidence so far: agents are low-variance, so collisions are correlated rather than random. Naming, task choice and resource use converge. In a finite-bandwidth job-queue experiment with no way to coordinate, agents flooded it with 30-per-second polling daemons: 2.4 million job requests, 117 accepted. Implication for shared environments: rate limits, claim steps and randomised naming matter more than they would for humans. A central forum is offered as a mitigation but depends on the model's willingness to collaborate.

Conflict-free can mean no collaboration. A rising merge rate is not evidence of coordination if code sharing falls to near zero; track both. Early models committed to the same files and abandoned conflicting PRs (Sonnet 4.6 and Opus 4.6 opened 876 and 980 PRs at 80 agents and closed few). Only Sonnet 5 kept both a high merge fraction and real code sharing. Prescriptive-role and CEO-hierarchy prompts made little difference.

Names the failure behind the "speculative CI runs invalidated" watch-signal as a class: a verdict tied to a moving pointer (main) is invalidated by orthogonal progress. The proposed cure differs from merge trains: receipts keyed on code-tree hash plus rule-version hash, optimistic concurrency, rollback after merge. Single practitioner claim, no numbers, and the content-hash idea is untested against semantic conflicts. Worth setting against Mergify/GitLab trains.

Coordination failure by absence: no collision, no error, just a message path that never fires because the agents found an equivalent route (the Linear board). Tej's mitigations are worth keeping: ask each agent to describe its job and recent days, ticket number in every commit, a daily written readout, and an explicit list of when it must ask the human. Same post: DECISIONS.md reached 66,725 words in 12 days, about 18,000 of them in the 3 days pm was in charge.

A different memory answer from decision logs: don't persist the why, regenerate the what on demand. The tradeoff is that an explainer describes the code as it is now, not why it became so. Pairs with the same post's 'Changing course' point, where prior decisions are surfaced by people in open Slack threads rather than by any store.

Evidence that overlap can be settled by conversation rather than locks, at least on a highly decomposable task (ProgramBench rebuilds, six-hour budget, GPT-5.6-sol). Caveats: one benchmark family, one model, and community replies (daily.dev) keep asking about merge conflicts and cost. The three infra pieces are a shared workspace of proposed/ongoing/done work, a message interface, and shared context of findings and intentions.

Integration became a role agents created for themselves once volume grew, and the handoff protocol was patched after failures: a hint that the merge queue can be peer-run rather than a central gate. At 1,024 agents several integrators existed, with requests sent to many and cancelled once one accepted. Unproven outside this benchmark.

Shared memory is itself mutable state, so it needs the same treatment as source files: ownership, merge rules, conflict detection. Worktrees isolate code but agents still converge on one notes file, decisions log or memory store. Low-engagement single post, but it names a gap: decision rationale has no merge semantics. Pairs with Stodal (single writer) and Dotu (claims log) below.

The human is the shared resource agents contend for. Context-switch cost is context loading for the person, mirroring the agents' problem. His rule: delegate what you can verify, never delegate what you're trying to learn, and treat skimming as a signal to stop. Cites Bainbridge's ironies of automation and the METR slowdown study. Pairs with the existing Abralo "3 or 4 agents" finding, which hit the same ceiling from the tooling side.

The collision git cannot see. Proposed fix: orchestrator-ordered dependencies on shared interfaces plus rebase and compiler/test gate before fast-forward. Same thread has others naming shared DB/ports and a human "playing telephone" between agents with competing theories of one bug.

The cleanest statement found of decision-staleness across concurrent agents: 'When you run four, a decision made in one chat is a rumor everywhere else.' Also: a shared planning doc 'went stale by lunch, because keeping it updated was my job', and a stale ticket let a backfill agent corrupt 'a few thousand rows' (handoff from an agent whose two judgment calls were never written down). Their own tests, flagged as internal and vendor-run: an unaided agent respected 0 of 12 held decisions in a 36-issue cleanup; with a pre-action alignment check, 12 of 12 (tests delivery, not discovery of the decision). Treat the narrative as first-hand anecdote and the numbers as a vendor claim.

Notable as an advisory, cross-vendor, cross-human layer rather than a lock: it keeps agents unblocked and puts the cost on the contested file only. Its own docs concede the limits: with solo login your own two agents never warn each other, and a warning is muted for ten minutes so the next change can slip by. Closed beta, vendor claims (160 ms local latency) unverified. Described in the 'Two agents, one file' article.

Useful negative result from a vendor against its own interest: agreement is not correctness. Other numbers: in all 10 tasks the two agents' features touched the same file (same lines in 5) even in separate workspaces; with message-passing but no shared code, 7 of 10 merges conflicted; the benchmark's own shared-Git mode already reached 6 of 10 passing; a single agent building both features alone passed 5. They also published a correction (4-agent shared Git 2 of 10 became 3 of 10 after stale patches were excluded). Self-run, small (n=10), one model; read as direction, not proof. Supports 'one integrator' over 'every agent merges everyone'.

A concrete variant that decouples landing from trusting: main moves fast, release eligibility is the gate. It trades a possibly-broken main for throughput, the opposite of the merge-queue guarantee that main stays green. Practitioner claim, no numbers given.

The most concrete write-up found of emergent contention. Mechanism: a PreToolUse hook on every background Bash call walks each busy process up to its owning claude session and counts workers across all sessions (cap = cores/2); over budget, it blocks and tells the agent which session owns the load and to run foreground or batch instead. Three sessions each launching ~12 background workers at 8-10% CPU oversubscribed a 12-core M3 Pro. Also: a Stop/SessionEnd hook reaps orphaned processes, a hung release test sat 7h22m using 258 ms CPU, and a cleanup job silently ran as a dry run for a while because a helper's APPLY variable shadowed his (lesson: check what the job freed, not that it ran). Single practitioner, self-reported, but detailed enough to reproduce. Strong fit for the 'when is a branch not enough' tension and the 'agent time stalled' watch-item.

The contention that bites first here is not files but shared compute: "most time is waiting for inference results. The cost is entirely on builds and tests and tooling." His answer is a dedicated agent staffed to take "type check requests" off a queue, i.e. a shared resource gets a broker. Also a counter-position to worktree-by-default: he argues worktrees waste disk and resources and make collaboration worse, and prefers one shared checkout with a strong collaboration toolkit. A reply from Hudson Griffith (@useprized) pitches one big cloud box so all sessions share the checkout and the 32 vCPU type-check budget. Single-source, self-reported, no numbers beyond '50 sessions, ~8h'.

A concrete answer to what git worktrees leave out. From the main checkout, jj diff -r fix-retry@ shows an agent's in-progress edits, one jj rebase moves every lagging agent onto the new main, and conflicts are stored in the commit instead of halting the rebase. jj evolog recovers files after an agent runs git reset --hard, and jj undo refuses to revert another workspace's operation. The author is candid about limits: ignored files (.env, node_modules, target/) aren't copied, and edits only reach history at the agent's next jj command. Rules like "never push" are enforced with a PreToolUse hook and a pre-push hook, not just the prompt.

Not coding-specific (examples are webhooks, shipments), so lower evidence weight, but it names the failure that file-lock and lease tools for coding agents (symlock, Agentlocks, Concord) have to answer: a paused agent can wake after its lease is reassigned and still land its change. The proposed remedy is a fencing check at the point of acceptance (reject writes from a stale generation), not a better lock. Also: 'The model should not decide whether it owns the task from a conversational message. The durable claim result is the authority.' Worth testing whether any of the coding-agent lock tools implement generation checks on write.

A resource every worktree shares by design: the account's quota. Notable details: subagents default to 20 at once (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS), Anthropic suggests 3-5 teammates; on API keys the whole organization shares one limit; and 'Anthropic says 60 requests a minute may be enforced as one a second, which is how a burst of parallel subagents gets a 429 below the stated limit.' This is a gateway vendor with a product to sell, and the cost table is its own traffic estimate, so use it for the mechanism (shared, bursty, org-wide) and verify limits against Anthropic's docs before citing numbers. Complements the cost-per-resolved-task point in the Codex fan-out discussion.

Rare empirical, human-subjects evidence on supervising concurrency. Formative study (N=14): typical setup is 3 concurrent sessions (max 3-8), parallel use accounts for 45.3% of AI coding, triggered by idle time waiting on builds/tests; all 14 reported a coordination and monitoring tax ('over your brain, fried quickly'; 'like a quarterback across three sessions'). They name five supervisory practices, PILOT: Plan, Isolate, Log, Observe, Triage. The authors' own Discussion flags an 'abstraction tension': status awareness 'did not by itself establish whether its code was correct', so tools should lower the cost of the re-engagement moment (one-click return to the CLI, lead-in messages, retrievable history). Limitation: short coding tasks, design probe not a production tool. Strong anchor source for a note on the human attention ceiling; pairs with Abralo (3-4 agents) and Delegator (review WIP limit).

A prominent practitioner dropping worktrees for a remote machine per agent thread, where the agent installs ClickHouse, Kafka or whatever it needs. Replies split on it. One notes that worktrees separate files but two agents can still change the same running service. Another already skips worktrees locally with a scratchpad directory per agent and OCI containers. Alongside Shopify's remote environments, this suggests the isolation boundary is moving from the file tree to the whole machine.

WIP limits come back as the control for agent concurrency.

A controlled study across 180 configurations with prompts, tools and budgets held fixed. Multi-agent setups helped decomposable tasks (+80.8%) and hurt sequential planning (−70%). Returns turned negative once a single agent already scored above about 45%. This is the best evidence yet for deciding what to fan out at planning time.

Goes after the merge git can't judge: one change alters a signature, another adds a call to the old one, git merges both, the build breaks. zit accept checks each change against what landed since it started (same entity changed, interface changed, checks in zit.toml) and moves a ref by compare-and-swap. Copy-on-write workspaces also answer the disk cost of worktrees (their numbers: 57 worktrees, 4.4 GB, 88% dependencies). Claims only work between workspaces on one machine, and all the figures are the project's own. Compare with Weave and Foremerge.