The first time you run two coding agents on the same repository at once, you learn what a shared working directory is. Agent A edits src/auth.ts. Agent B reads the same file two seconds later, gets A's half-finished edit, and builds on it. Neither agent did anything wrong. The checkout is one mutable surface and they are both writing to it.

Running a second agent in a second terminal does not help: the terminal is not the boundary, the working directory is. Both processes see the same files, the same index, the same HEAD. You cannot reason about what either one changed, because the diff you are reading is the sum of both.

The boundary is a worktree

Git already has the primitive. git worktree add gives a branch its own directory, with its own working files and its own index, sharing one object database with the main checkout:

git worktree add ../repo-agent-a feature/auth
git worktree add ../repo-agent-b feature/search

Two directories, two branches, one repository. An agent in the first cannot see or clobber the second's files. Nothing is copied that does not need to be: the objects are shared, so a second worktree costs a checkout, not a clone.

That is the whole mechanism, and it is why parallelism is a file-system problem before it is a scheduling problem. Once each agent has its own directory, the question "what did this agent change" has an answer again: it is the diff of that worktree against the branch it started from.

What changes once agents stop colliding

The collisions were hiding the real bottleneck. When two agents can run at once, you are no longer waiting on the agent — you are waiting on yourself. Three agents finishing within a minute of each other produce three change sets that all need reading, and reading is the part that does not parallelize.

So the parts of the loop that matter shift:

Isolation stops being interesting once it works. It is table stakes, not a feature you think about daily.
Review becomes the whole job. Every agent's work arrives as a set of changed files that you either understand or ship blind.
Cost becomes visible. Ten agents thinking hard in parallel spend ten times what one agent spends, at the same wall-clock moment.

Cohalen is built around that shift. Each Workspace is a git worktree on your machine, so the isolation is git's, not a sandbox we invented. What the app adds sits after the isolation: one surface that shows every agent's Changeset, the checks against it, and a spend cap that stops the next Turn rather than reporting the overage afterward.

Running this yourself, without the app

You do not need a tool to try the pattern. The manual version:

# one worktree per task
git worktree add ../repo-a -b agent/refactor-auth
git worktree add ../repo-b -b agent/add-search

# one agent per worktree, each in its own directory
cd ../repo-a && claude
cd ../repo-b && codex

Two things will bite you, and they are the reason the manual version stops scaling around three agents. Untracked build state (node_modules, .env, caches) is per-directory, so each worktree needs its own, and reviewing N branches means N rounds of git diff in N terminals with no shared verdict. Neither is hard. Both are tedious in exactly the way that makes people quietly go back to running one agent.

The rule underneath

One agent, one working directory, always. Everything else about running agents in parallel is a consequence of that rule or a workaround for breaking it.