Note

Don't scale agents, scale leases

Cursor's agent swarm post scales to 1,000 commits per second and builds a custom version control system to survive it. We run a much smaller fleet and took the opposite lesson: orchestration is not a scale problem, it is a shared-state problem. The primitives are old: a lease, one writer or many readers, the discipline Rust's borrow checker enforces at compile time. What is worth writing down is not the mechanism but the scar tissue: where it held over five days, where it cracked three times, and the one thing a lease can never do, which is tell you the write it just protected was safe to ship.

The caveat, first

Our fleet is roughly eighteen agents on a thirty second tick, not a thousand worker swarm: about fifty-two closed cycles and two hundred fifty-plus Ship-Read-gated commits in five days, with write leases on two repos only (product code and marketing site) and read-only access everywhere else. So take the mechanism here as topology, not throughput. Five hundred scans in the same window are dogfood and build discipline, not traction.

And none of the primitives are new. The lease is a 1989 distributed-systems idea; "many readers or exactly one writer, never both" is the readers-writer lock from 1971, which Rust later made a compile-time law. We did not invent the mechanism and do not claim to. What makes this worth writing down is that the old discipline held once exactly as designed and cracked three times in ways worth naming. The cracks are the useful part.

Which work shares state

The scale question, how do we run more agents, is the wrong first question. The right one is smaller and older: which work is disjoint, and which work can two agents never touch at once.

Task descriptions answer it for you. As Wilson Lin puts it:

Cursor's swarm puts smart planners at the top and fast, cheap workers at the leaves.

In their runs, workers carried at least 69% of the tokens, and over 90% in most.

Two agents at different leaves never collide. Two agents at the same file collide constantly. So the real question in orchestration is not "how do we spawn more agents." It is "which work is disjoint, and which shares state."

Reads are disjoint. Writes are not.

Repo access is a mutable borrow

The cleanest mental model we found is Rust's, and the mechanism underneath it is older still. A value can have many readers or exactly one writer, never both, and the borrow ends when it leaves scope.

Map that onto a fleet:

So a writer claims the repo before editing, everyone else reads or works another repo, and the claim releases at the end. The lock itself is a thirty-minute TTL refreshed by heartbeat: passes often run nine to thirty minutes, so without refresh a healthy ship looks like a crashed holder. Sequencing sits on top: parallel where the outputs are disjoint (mostly read-only measure passes), serial where they share one repo. Measure after ship, plan after evidence, the pass that reclassifies everything runs last.

Cursor built a custom VCS because Git's coarse locks are:

And because:

Their swarm went from roughly 1,000 commits per hour to around 1,000 per second. Ours is humbler: a lock claimed before any write to a shared repo. Same spirit. The point is to make exclusivity a mechanism, not a convention. A convention breaks the moment two agents wake up at once. A lock does not.

Off to the side sits a disjoint read worker that never touches either leased repo: an offline generator that plants candidates and scores catch rate (first batch around forty-one in seventy), then routes misses into tests and improve. Same topology rule. Different substrate.

Where it held

The one moment the design did exactly what it promises: a background loop was pushing to a live site every minute or two, and a manual change needed to land in the same repo without a collision. Claiming the lease first stopped the loop's writes cold until the manual ship finished and released. No merge, no thrash, no lost work. That is the whole pitch in one event.

Two quieter holds matter for the same reason. After ships started logging "pushed before lease release," the write seat stopped stranding undeployed commits behind a closed lock. And when two agents need the same site repo in one pass, one waits: the second must acquire the site lease first and yield if the other already holds it, so parallel apply does not become a silent merge.

Where it cracked

Three cracks, each a lesson a bigger fleet would pay more to learn.

The claim has to come before the write, not after. Cursor's swarm saw the same class at scale, workers facing collisions:

Here, a change sat uncommitted in a working tree while a loop, holding no knowledge of it, committed the same tree under its own unrelated message and pushed. Nothing was lost, but the history now attributes the change to the wrong commit. The same class of failure showed up at fleet scale: a mid-cycle laptop sleep killed a worker with uncommitted work; twelve commits sat unpushed for twenty-five hours while other loops re-verified production for work that never deployed; forty-seven planning files sat uncommitted across a pause. A lease only protects work that is claimed before the write. Uncommitted intent is invisible to it.

Heartbeat granularity has to match your slowest write. A lease was reclaimed mid pass because the holder spent long enough on a build that its claim went stale, and another agent legitimately broke the stale lock. We learned the bound the hard way: URL-lane bench pins ran about 2.3× slower than the folder walk, and the README now documents a ninety-five-minute heartbeating ship that stayed exclusive while a crashed holder still auto-breaks at the thirty-minute TTL. The fix is not a longer timeout; it is a heartbeat during long operations. But you only learn your slowest operation by having one time out.

A lease says who may write, not whether the write was sane. An unattended installer wrote machine specific state into a file meant to be shared across machines, and an auto commit carried it out. The lease worked perfectly. One writer, clean commit. The write was simply wrong, install pass 13 later reverted a ship for the wrong path, not a collision. The offline generator made the same point from the other direction: a factory run found three detector regressions (CORS star-plus-credentials, middleware that skips /api, service_role JWT in the client) under clean locks, and all three shipped into the improve queue. Exclusivity is orthogonal to correctness.

The rule we landed on

• Parallelize disjoint read work: research, review lenses, offline generation.
• Serialize write work on shared state: one writer per repo per wave.
• Order by causality: evidence before planning, ship before measuring, the pass that reclassifies everything last.
• Gate on freshness: skip a pass whose inputs have not moved, so you do not pay coordination cost for redundant work.

You do not need a thousand agents. You need enough parallelism to keep each agent's context narrow, enough serialization to avoid merge thrash, and enough sequence to preserve cause and effect.

The part a lease cannot do

This is the promise from the top of the page, and the crack that matters most, because it is the seam where our product lives. A lease decides who may write. It cannot tell you whether what they wrote is safe to ship. Those are two different jobs. The first is a lock. The second is a review lens that reads the change on its own, with no stake in having produced it. Scale the first as hard as you want and you have not touched the second.

Our own corpus sits green at one hundred forty-six of one hundred forty-six, expected by construction on an authored fixture set, so that number is not the headline either. What a lock cannot see is correctness: coordination can ship a whole retention stack while the behavioral proof never fires (url_rescans still read zero after eight open-gate URL scans). A lock does not notice that gap.

Cursor found the same split from the other side.

A swarm that writes faster still needs something independent to check what it wrote before it reaches anyone. That check is the entire reason Seatbelt exists.

What we do not claim

We are not at swarm scale, and some of this is aspirational at ours. The receipts are five days of our own dogfood fleet, not a controlled study and not external usage. We invented none of the primitives; the lease and the readers-writer lock predate us by decades. What we are confident of is the shape: orchestration is as much about where not to parallelize as about how much to parallelize, treating shared state like a mutable borrow is a cheaper way to learn that than at a thousand commits per second, and no amount of coordination tells you whether the write was safe.

Connor · Seatbelt · July 21