AVP, version control that replaces Git for coding agents

October 25, 2026

AVP is version control for coding agents, built to replace Git. An agent opens a task, writes, and lands it. Every landing is proven against the exact head of the line before it counts, and two agents on the same code are replayed one on the other instead of going through pull requests. On our own repository, CI runs for pull requests went from 104 a day to 4, and a change reaches main in 3 minutes instead of 19. It is open source.

We built it at Murmell. Murmell is made by two people and a lot of agents, in one large monorepo, at the pace of a startup that ships every day. Gabriel and I run several agents at once on that repository, because that is how we go faster and how we keep the token bill sane: small tasks, in parallel, each agent on its own piece. For a while it worked. Then the agents stopped being the slow part.

Where the time went

Every change went through the loop everyone uses: a branch, a pull request, a CI run, a merge. Over the 3.8 days before we changed anything, GitHub recorded 34 merges a day and 104 CI runs for pull requests a day, about three per merge, for 1,287 minutes of CI a day. The median change took 19 minutes from opening to merged, and the slowest tenth took more than four hours.

Nothing in that loop was badly configured. It was built for people, who open a few pull requests a day and read each one. Agents open dozens, each waits for a run of several minutes, then rebases on a main that moved while it waited, then waits again. Two agents that touch the same file end in a conflict that somebody has to settle by hand. And every merge triggered a staging deploy that the next merge cancelled: 41 % of them never finished.

In October, Anthropic wrote that it had moved its monorepo off Git after its agents took it from about 2,500 merged changes a day to more than 30,000. Their system is internal. I wanted to know whether the same shape helps a team of two, so on 23 October I started an experiment. It became AVP, for agent versioning protocol.

How AVP works

Two agents start from the same position. The first one to land becomes the next position; the second is replayed on it and proven again before it lands. No branch, no pull request, no merge.

A server holds the truth about the code: a line of numbered positions, each one a complete tree. Agents reach it through MCP tools, backed by a small REST API that the avp command line uses too.

Open. avp_open with a one-line goal starts a task at the head of the line and lays it out in a fresh folder. It also says which other tasks are open, and on which files.
Write. The agent edits files in that folder and runs whatever it wants. Its files go to the server as it writes, and once it stops writing for a few seconds, the proof starts, while the agent is still running its own tests.
Land. avp_land takes the proof: the steps of avp.toml, typically the typecheck and the tests related to the files the task touched, run on the head of the line plus the task's files. Green, the task becomes the next position, in one compare-and-swap. Red, the agent reads the failure, fixes it and lands again.
Replay. If another task landed in the meantime, the task's changes are applied again on the new head, hunk by hunk, and proven again. Changes that do not overlap simply combine; overlapping ones come back to the agent as conflict markers in its own files, never to a person.
Mirror. Every position is written to main as an ordinary commit, with the task's goal, its author and its proof. Everything that still reads Git keeps working.

The whole test suite still runs, but once per batch of landings instead of once per change. When it is green, staging follows on its own. Production is a promotion: one command, by one of us.

Then we gave that work runners made for it. The proofs and the whole suite run on runners of our own, which take their work from AVP's queue and grow and shrink with it. The suite is cut into pieces that run side by side, so a full run takes the time of its slowest piece, and no change waits in a CI queue any more.

What changed on our repository

These are the first numbers: about six hours on AVP, on the day we converted our open pull requests, against the 3.8 days measured on GitHub before.

	Before	With AVP
CI runs for pull requests	104 a day, 1,287 min	4 a day, 61 min
Checking one change	a CI run, 5 to 15 min	15 s (median of 40 proofs)
Open to main, median	19 min	2.9 min
Open to main, slowest tenth	4 h 21 min	21 min
Staging deploys cancelled	41 %	none

In that window, 31 changes landed. Fourteen times the line had moved under a task, and each time it was replayed without a conflict. The whole suite ran four times on our runners and never disagreed with GitHub's CI about the code; GitHub's CI still runs beside it so we can keep comparing.

On a repository that is not ours

To check that this was not a Murmell quirk, we ran agents on go-chi/chi, a Go router, and never told them about AVP.

Claude Code went through AVP on its own in three runs out of three, and Codex did too once AGENTS.md carried one line about it. None of them made a Git commit.
Two agents changed the same function at the same time. AVP replayed the second on the first, with no conflict markers and the tests green. The same pair on Git ended in a conflict that a third agent had to settle.
One agent alone, three tasks in a row: 146 s and $0.330 through AVP, 151 s and $0.332 through Git. The same cost, with every change proven before it landed.

On the CooperBench flash_10 set, where two agents build two features and hidden expert tests judge the result, two agents sharing a Git remote passed 1 task in 10. Through AVP they passed 8, as many as one agent working alone.

Open source, and what comes next

It is early, and I am not claiming it is finished. It is open source because the point is to use it, on our repository and on yours, and to make it better a little at a time. It is one binary: avp up in a Git checkout imports its history, guesses the checks for Node, Python, Rust, Go, Java and Ruby, and connects Claude Code and Codex. The code and the log of what broke are at github.com/Mossab28/avp.

The next releases are about fixing what the runs find and making the proofs faster. After that, a hosted version, runners included, so a team can use AVP without running any of it itself.

By the way: with the team behind Murmell, we are applying to Y Combinator for this batch. If you run agents the same way, or have feedback on any of this, write to us at contact@murmell.com.

Straight answers

Does AVP replace Git?

For the agents, yes: they open a task, write and land it, with no branch, commit or pull request. Every landing is still written to main as an ordinary commit, so GitHub, deploy workflows and people keep reading Git while a team moves over.

Do agents need to be told how to use AVP?

No. On a repository that was not ours, Claude Code went through AVP in three runs out of three without being told, and Codex did too once AGENTS.md carried one line about it, which avp up writes.

Is it worth it with a single agent?

It costs the same as Git: on three tasks, one agent took 146 s and $0.330 through AVP against 151 s and $0.332 through Git, and every change was proven before it landed. The larger gains come with several agents at once and a slow CI.