In short
When five AI agents simultaneously manage a single repository, standard Git breaks down. Loom-VCS offers a coordination layer on top of Git—with intent leases and a guarantee of "green code." I'm trying to figure out if it's worth paying attention to.
The problem that loom-vcs solves may seem far-fetched right now—but only if you haven’t yet run multiple AI agents in parallel on a single repository. The zyads/loom-vcs project describes itself as “version control for many hands moving at once”—a coordination layer on top of Git, designed specifically for agents rather than people.
The key idea is “intent leases.” An agent declares what it intends to change and receives a “lease” on that area of code. This isn’t a branch or a lock in the traditional sense, but rather a contract: “I’m working on this—don’t mess with it.” If another agent attempts to modify the same files, the conflict is detected at the level of intent, rather than as a merge conflict in the code.
The second concept is “stitches” and “green-by-construction fabric.” Translating from marketing speak to engineering terms: the system attempts to guarantee that the result of building multiple agents remains “green by construction,” rather than catching errors after the fact in CI.
The project is written in Rust, which makes sense for a tool that needs to work quickly with dependency graphs and change trees. But the reality is harsh: 4 commits, 1 star, 0 forks. This is an early-stage concept, not a finished solution.
Why is it still important to read this right now? Because the problem is real and will only grow. Today, teams are running Cursor, Copilot, Devin, and custom agents on a single codebase. Git was designed for people who think in minutes and hours. Agents make commits in seconds; they don’t read other people’s branch names or coordinate via Slack. The classic Git flow—branch → commit → PR → merge—starts to get overwhelmed when there are too many “hands” involved, and they’re all automated.
Intent leases are essentially an attempt to move coordination from the “message a colleague on Slack” level to the protocol level. And this is the right direction: agents need a machine-readable way to agree on their areas of work, rather than hoping that they “won’t run into each other somehow.”
For now, loom-vcs is an idea, not a tool. But it’s spot on. The question to ask yourself is: the next time you run three agents on a single monorepo, what exactly will prevent them from overwriting each other’s changes? If the answer is “nothing,” then you already need a coordination layer. It’s just not yet certain that this is the right one.