Declare the scope before the agents write

I run a small standing fleet of agents, and the rule I never break is that no two of them touch the same surface at the same time. Not because I lived through some disaster once and swore off it. Because the failure it prevents is cheap to design around and miserable to debug after the fact, and that asymmetry is the whole reason to take it seriously before it ever bites.

If you're trying to run parallel agents without conflicts, the fix is almost never a better merge. It's coordination declared up front: each agent gets a scope it is allowed to touch, and one shared contract that says what the finished thing has to be, decided before any of them writes a line. A merge tool only sees text. It combines two diffs that don't land on the same lines and reports success, with no idea the two changes contradict each other in meaning. The boundary has to exist before the write, not get reconciled after it.

why do my agents merge clean but break the app?

Because a clean merge is a statement about text, and your bug is a statement about intent. Those are different sentences. When two agents work the same feature in parallel, each one can finish correctly in isolation: one replaces a class, the other extends the class it expected to still be there. The edits sit in different files or different lines, so nothing flags a conflict, and the combined result is two changes that cannot both be true. The people measuring this keep finding the same thing, that agents writing in parallel collide markedly more often than one agent working alone, and the collisions that hurt are the ones the merge never notices. Version control was built to catch humans editing the same line. It was never built to catch two correct diffs that disagree about what the code is supposed to be.

what did version control actually give us?

It's worth being precise about this, because the reflex is to say "just use git better" and that misses the point. Before version control, several people editing one codebase was chaos, and branching plus an explicit merge step tamed it. But the merge was never the gift. The gift underneath was that work got a declared owner and a shared idea of what done meant before anyone touched the files. Parallel agents need those same three things, in the same order. Isolated worktrees, so one agent's half-finished state never poisons another's read of the world. A declared scope per agent, so ownership is explicit instead of emergent. And one shared task contract each agent claims before it writes, so done is defined once at the top rather than discovered, painfully, at integration. That is spec-first discipline lifted from a single build up to a team of builders.

how I set my fleet up so they don't step on each other

Here's the lived version, and it's less exciting than it sounds, which is the point. I run role-separated agents: a builder, a researcher, and an adversarial reviewer whose whole job is to try to break the result. But the roles are not the coordination. The coordination is that I write the contract first, the change, its invariants, and the exact files in play, and then each agent claims the slice it owns against that contract before it does anything. The researcher reads and proposes and never writes to the build surface. The builder writes only inside its declared files. The reviewer attacks the finished work against the same contract everyone started from. What that caught, or really what it stopped from ever happening, is the clean-but-contradictory merge, because two agents were never allowed to own the same surface at the same moment. It's the SpecMesh move applied to a group: the contract leads, the implementation follows, whether the thing implementing is one agent or five. Boring, and it holds, which is what you want from the layer underneath production software, especially a vibe coded project where you're already trusting a lot of generated code you didn't write by hand.

the move, in one line

Coordination is version control for agents, and version control was never really about the merge. It was about declaring ownership and intent before the work, so that the merge is a formality instead of a negotiation. Declare each agent's scope and the shared contract before the write. Reconciling after is exactly how you end up with a green merge and a broken build, and no line to blame.

If you're a vibe coder scaling from one agent to a fleet and want a second set of eyes on the coordination layer before it bites you in production, /work-with-us. Send me the shape of your fleet and the thing it keeps colliding on, and we'll design the scope contract together. Work with VibeKoded.

questions that keep coming up

Can't I just tell the agents to merge more carefully? Careful merging solves the wrong problem. The conflict isn't in the text, so there's nothing at the merge for care to catch. The two diffs are individually fine; it's their combination that's wrong. The only place to fix that is before the write, by making sure no two agents were ever building toward changes that can't coexist.

Do I actually need a separate worktree per agent? For anything running truly in parallel, yes. A shared working tree means one agent reads a half-applied state from another mid-flight and builds on sand. Isolated worktrees give each agent a stable picture of the world; the shared contract is what makes their separate results add up at the end.

Isn't writing a contract first just overhead that slows the fleet down? It's the opposite trade. The contract is a few minutes of orchestration that buys you the hours you would otherwise lose bisecting a merge that git swears is clean. The whole reason to run agents in parallel is speed, and an unplanned collision is the fastest way to give that speed back with interest.

The broken build is easy to fix once you stop blaming the merge. The merge did exactly what it promised, it combined two diffs that didn't overlap. What it can't do, what nothing downstream can do, is tell two agents what each of them was allowed to become. That has to be said before they write.