Worktrees isolate your agents.
AVP integrates them.

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, changes reach staging in 8.5 minutes instead of 91, and CI machine time fell by 77 %. You can read every line of it.

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.

Worktrees, now the standard answer, fix half of it: each agent gets a folder of its own and nobody writes over anybody while they work. The other half is the moment they all come back to main. That is the part AVP is about.

How AVP works

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.

1. 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.
2. 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.
3. 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. Red, the agent reads what failed, fixes it and lands again.
4. Replay. If another task landed in the meantime, the task's changes are applied again on the new head and proven again. Changes that do not overlap simply combine, two additions at the same place keep both, and real overlaps come back to the agent as conflict markers in its own files, never to a person. When many land at once, they land in turn.
5. Mirror. Every position is written to main as an ordinary commit, with the task's goal, its author and its proof. GitHub, your deploy workflows and your people keep reading Git.

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.

Many agents, one main: the benchmark

We built a benchmark where only version control changes. The project is Facturo, a billing API in TypeScript, specified in 112 sections, each with its own acceptance tests. 64 Codex agents work at the same time, each on its own sections, and deliver to one shared main. With Git, main is protected by CI, as on GitHub: a push runs the typecheck and every test on the exact commit it would make main, and is refused when they fail. With AVP, every landing is proven on the head of the line. Every agent gets the same instructions; only the paragraph about version control differs. A section counts when its original acceptance tests pass on main. Each team gets 40 minutes, and after each round the sections not done go back to their agents, the same way for both.

Why the big models stall with Git. The sections depend on each other: the acceptance tests of Customers need Invoices, and those of Invoices need Customers. With Git and CI, each push is red without the other's work, so CI refuses both, and Sol and Terra wait for a teammate who is waiting for them. AVP sees the cycle and lands the two tasks together, proven as one change: Sol delivered the whole spec in ten minutes, in a single round. Luna, the small model, writes the missing code itself and gets through with Git too; with AVP it costs 40 % less.

32 agents, three runs each

The merge queue is GitHub's own, on a private repository, with GitHub's default settings except the wait before merging, set to zero, which helps Git; its CI runs on runners of the same machine. Pull requests the queue turned down for a conflict or a red check rarely came back.

Where the time goes

On the 64-agent Git run with Luna, three commands in four that the agents ran were version control: pulls, rebases, pushes and retries, and 320 of 557 pushes were refused. CI itself, 393 runs of about ten seconds, was about 4 % of the agents' time. A faster CI would not change much: the time goes before it.

Codex for every team; cost is the tokens at the public API price. One run per point at 64 agents, three at 32. CI takes seconds here, where a real one takes minutes, which favors Git. The harness and the instructions are in the repository, under bench/.

What changed on our repository

On Murmell's repository, 48 hours of pull requests (22 and 23 October 2026) against 48 hours on AVP (25 to 27 October), same team, same product in production:

CI runs for pull requests went from about 150 a day to about one: there are no pull requests left to check. CI on main runs more often, because we ship more often.

Source available, and what comes next

It is early, and I am not claiming it is finished. All of AVP is in the source, the team server and the proofs on your own runners included, and it is free for any use, at work too. The one thing the Elastic License 2.0 reserves is offering AVP to others as a hosted service: that is AVP Cloud, which we run for teams that would rather run none of it. 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.

Every landing is written to main as an ordinary Git commit so that a team on Git today can move over without changing anything else. At Murmell we went further: we no longer use Git ourselves. Our agents and the two of us work through AVP, we are slowly moving to a client of our own, and GitHub stays as a fallback that keeps a copy of the code. I think most teams will make the same move in the coming years.

The next releases are about fixing what the runs find and making the proofs faster, and AVP Cloud: the hosted version, runners included, for a team that wants to run none 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.