In the last five months three of the biggest names in AI rebuilt source control. Anthropic replaced git for its monorepo after merges went from about 2,500 a day in May to more than 30,000 a day in September. OpenAI rebuilt its git server for Codex after commits on its main branch rose 1,378%. Cursor opened an early beta of Origin, a git forge that lives inside its editor.
So "version control for AI agents" is now a real category. People search for it as agentic version control, AI version control, or an agentic VCS. This post says what that term should mean, what each of the five systems in the conversation actually does, and where Nool fits.
What an agentic VCS has to do
Git was designed for people. A person knows what their colleague is working on, waits for review, and remembers why a decision was made. Agents do none of that. They start in parallel, discover files mid-task, and forget everything when the session ends.
An agentic VCS has to handle three things that git leaves to the humans around it:
- Concurrency. Many agents writing at once without overwriting each other or colliding late in CI.
- Safety. Rules that run before a change lands, the same way every time, whoever or whatever wrote it.
- Scale. More agents in parallel without a matching rise in cleanup, review load or broken merges.
Throughput is part of scale. It is not the whole of it. A system can accept 30,000 merges a day and still let two agents rewrite the same function.
The five systems, honestly
| | What it is | What it solves | What it leaves open | |---|---|---|---| | Scion (Anthropic) | A centralized source-control system built to replace git internally | Merge volume and server load at Anthropic's scale | Two agents changing the same code; repaired after the fact | | Pando (OpenAI) | A rebuilt git server; the git client and protocol stay unchanged | Push and fetch speed, read scale, reliability | Which agent should touch which code; branches are treated as unrelated | | Origin (Cursor) | A git-compatible forge in the Cursor editor | Hosting, stacked pull requests, merge queues for agent-made changes | Deciding what is safe to merge before it reaches the queue | | jj (Jujutsu) | A git-compatible VCS with an append-only operation log and no staging area | Removes a class of index and lock-file races between concurrent writers | Coordination and policy between agents; it is a client, not a gate | | Nool | A version control layer designed for agents working at once, on top of git | Leases before edits, rules before landing, signed evidence on every change | Raw git throughput; Nool is not a git server |
Scion and Pando are storage and serving redesigns. Origin is a forge. jj is a better client. All four make source control faster or friendlier. None of them asks the question that hurts teams running many agents: should these two agents be touching this code right now, and should this change land at all?
What Nool adds
Nool answers that question before anyone types.
nool announce intent --agent-id quota-agent --intent "Tighten quota checks" --target-nodes src/api/limits.ts
nool propose --as-agent quota-agent --path src/api/limits.ts --intent "Tighten quota checks" --solidifyThe first agent claims the code it plans to change. A second agent that reaches for the same code is refused before it writes anything, so nobody reviews a collision. When a change is proposed, your rules run against it: tests, YAML policies, and hard rules your platform team compiled to WASM. Only a change that passes lands, and it lands with its intent, test results and approvals attached.
Your code stays in Git. Nool mirrors every landed change to an ordinary remote, so GitHub, GitLab or Origin stays your forge, and your reviews and CI keep working.
What the numbers say
In our coordination benchmark, 35 agents worked the same 60 tickets on one codebase. With Nool coordinating, 98 to 100% of tasks landed with zero merge conflicts. On plain git without coordination, 33 to 62% landed.
Agents discover files mid-task, so no fleet knows in advance exactly what each agent will touch. Nool does not need that plan: it sees the overlap at the moment an agent claims the code, and that is the gap an agentic VCS exists to close.
Which one do you need?
- If your git server is falling over under thousands of pushes, you need what Pando and Scion built. Most teams never get there.
- If you want hosting and merge queues inside Cursor, look at Origin.
- If your agents collide, drift out of scope, or land changes nobody can explain, you need the coordination and control layer. That is agentic version control, and it is what Nool is.
They stack. A faster store still needs a coordination layer on top. Read the deeper comparisons with Scion and Pando, or put Nool on your own repository.