When agents write most of the changes, the bottleneck in source control moves from merging content to coordinating state: refs, clones, and the merge queue. Two vendors said so in the same week of October 2026, and both answers move work from the client to the server. Everything else on the market is either a client that tolerates concurrency better (jj, GitButler), a server that never assumed a full clone (Perforce, Sapling's Mononoke), or a versioned store for something other than code (Dolt, Neon, Delta).

Falsifiable by: a team at agent scale that keeps plain git, a single merge queue and full clones, and reports no ref or clone bottleneck.

Sources fetched 2026-10-27. "Verified" means the claim is on the fetched page; release versions and dates come from the GitHub releases API.

Three groups fall out of the table:

1. Servers rebuilt for agents: Scion, GitLab Next-Gen SCM, and (older, not built for agents but the same shape) Perforce and Mononoke. All of them avoid the full clone and do the expensive work server-side.
2. Clients that tolerate concurrency: jj, GitButler, Sapling's client. They change what one machine does with many lines of work, not what the server costs.
3. Versioned state beyond code: Dolt, Neon, Delta, AgentFS, Lix. These answer "roll back what the agent did to the data or the session", which git never covered.

gitoxide sits under group 2: the jj and GitButler builds both depend on gix (their Cargo.toml files, checked 2026-10-27). It is the obvious substrate for anyone building group-1 ideas into a git-compatible tool. BitKeeper is history more than market: the system Linux left in 2005, now open source. Its nested repositories, with one changeset spanning many sub-repositories, are an older answer to the question Scion answers by never materializing the whole repo.

These are different bets. jj keeps git's distributed model and makes the client safe under concurrency: operations that race are both recorded and merged, and a conflict becomes part of a commit instead of stopping the command. That suits agents that branch freely and resolve later. Perforce never had a distributed model: the server owns history, a changelist is submitted atomically, a shelf is a server-side experiment with no ref, and files are fetched on demand. That is much closer to Scion, at the price of always needing the server, and it is the default where large binaries live (games, hardware). P4V, the desktop client, adds nothing for agents; what agents would use is the p4 CLI or the community MCP server.

To see the ref bottleneck at small scale, eight scripted agents (shell loops, not models) each made twenty changes against one repository on a laptop, with git 2.49 and jj 0.26. In git, each agent pushed to a shared main and rebased and retried when refused. In jj, each agent was a workspace of one repository and a single lander rebased their work onto main afterwards.

With no shared file at all, git needed 411 refused pushes to land 155 changes: the contention is on the ref, before any content overlaps. jj never refused a write and kept conflicts as data, but jj 0.26's working copies went stale under concurrent writers and stacks diverged. The agent loop had to refresh and retry, and the lander's count was not stable enough to quote. One run, one machine, an old jj; the current release (0.46) is the next thing to measure.

Once a change lands, three markets decide whether it ships: delivery (GitOps and promotion), testing that calls itself autonomous, and assurance (formal methods, property-based testing, fuzzing). Same fetch date and rules as above.

• Few refs, one writer to main. Let agents push to their own branches or shelves and have one lander move main; the load test shows why.
• Partial fetch instead of clones for agents: git's partial clone and sparse checkout today, GitLab's agent interfaces when they ship.
• Test after merge and before deploy when the queue is the bottleneck, and measure how long main stays red.
• Version the state agents touch outside code (databases, sessions) with a tool built for it rather than git.
• Put agents behind the same promotion gate as people (Kargo, Harness verification) rather than giving them their own path to production.
• Use properties, not examples, as the oracle for agent-written changes, and run the expensive exploration on a schedule rather than on every change.

All fetched 2026-10-27. Vendor figures are the vendors' own and were not reproduced here.

• Anthropic, Redesigning source control, 2026-10-13.
• GitLab (Bill Staples), Scaling Git for the agentic software factory, 2026-10-13.
• jj, Concurrency; releases.
• Perforce, P4V, free tier, p4mcp-server.
• Meta, Sapling.
• GitoxideLabs, gitoxide.
• BitKeeper, Why BitKeeper; source.
• Zed, Introducing DeltaDB; Graphite, Graphite joins Cursor; Databricks, Neon acquisition release, 2025-05-14.