THE SWARM.

One agent is a queue.

A single coding agent grinds your repo one task at a time. It is not slow because the model is slow. It is slow because it is a queue with one server.

Not one of those four waiting tasks needs the one above it to finish first. They are waiting on a scheduling decision you made by accident: one agent, one working tree, one thing at a time.

So open ten agents on the same folder.

This is everyone's first idea, and it half-works for about four minutes. That is what makes it dangerous: the failure does not arrive as an error, it arrives as damaged work.

One working tree is one shared mutable surface. Parallelism on shared mutable state is a race, and you do not get to win a race by adding more runners. The missing primitive is isolation, and git already ships it.

The conductor pattern.

One orchestrator owns the split. It does not write code. It has exactly three jobs, and every one of them is a judgement a worker cannot make, because a worker cannot see the other workers.

The conductor's only products are the plan and the merge. If you find yourself editing code as the conductor, you have stopped conducting and become a fourth worker with a global view, which is the one role that cannot be isolated.

Worktrees, not branches in place.

Branching is not the primitive you need. Branching gives you many histories. You need many desks.

Same history, N desks. One clone's worth of objects on disk, N directories to work in. That is the whole trick, and it has shipped in git since 2.5.

A worktree is not a sandbox.

It isolates four things. It shares everything else, and the sharing is invisible until it bites.

$ ./agent.sh sw/01 & ./agent.sh sw/02 & ./agent.sh sw/03 & wait
error: could not lock config file .../demo/.git/config: File exists
error: could not lock config file .../demo/.git/config: File exists
# two failed. all three committed anyway. now read the log:
d2298b6 agent-task03-docs  task01-auth: implement
a6225a4 agent-task03-docs  task02-billing: implement
da6d3a4 agent-task03-docs  task03-docs: implement

The commit messages are right, so the log looks fine at a glance. The author is wrong on every commit - it is whichever agent won the race - which is the one field you would use to audit who did what. A worker may write its tree. It must never write the repo's shared config.

One command per task. One arena per agent.

This is the entire setup half of the pattern. Four lines, and every one of them ran on this laptop tonight.

git worktree add ../sw/01 -b task/01-auth
git worktree add ../sw/02 -b task/02-billing
git worktree add ../sw/03 -b task/03-docs
git worktree list

# .../demo        4f81f30 [master]
# .../sw/01       4f81f30 [task/01-auth]
# .../sw/02       4f81f30 [task/02-billing]
# .../sw/03       4f81f30 [task/03-docs]

Each ../sw/NN is a full checkout an agent can build in without touching the others. Note what you did not pay: no re-clone, no second copy of history. The object store is shared, so the marginal cost of another agent is the working files alone.

Three agents, one repo, three hours of work in one.

A real run on a scratch repo: split into three independent tasks, three worktrees, three agents fired concurrently, then merged back. Before, and after.

.../demo   4f81f30 [master]
.../sw/01  4f81f30 [task/01-auth]
.../sw/02  4f81f30 [task/02-billing]
.../sw/03  4f81f30 [task/03-docs]

# four trees. one .git.
# all three agents start
# from the same commit.

*   ad6f110 merge task/03 (+seam)
|\
| * 633fe2b task03: pass 2
| * da6d3a4 task03: implement
* |   0a87c30 merge task/02
|\ \
| * | 7e0e380 task02: pass 2
| * | a6225a4 task02: implement
* |   863b639 merge task/01
|\ \

Three features advanced in the wall-clock time one agent takes to do one. The fan-out cost four commands. The fan-in is where the real work was, and slides 14 to 16 are entirely about that half.

The teardown that ate a venv, quietly.

N cheap worktrees usually means linking a shared .venv or node_modules into each one. That trick is what makes the swarm affordable, and it is also what arms this.

# sw/01/.venv  -->  ../../precious   (a junction, i.e. a reparse point)

$ git worktree remove --force ../sw/01
--- exit: 0 ---          # no output. no error. success.

$ ls ../precious
[ empty ]                # data.txt and data2.txt are gone.
                          # the DIRECTORY survived. the contents did not.

The removal followed the link out of the worktree and deleted the target's contents, then exited 0. rm -rf and shutil.rmtree do the same thing. This fired for real in our own agent fleet nine hours before doors, and there it at least printed an error afterwards. Here it said nothing at all.

Three things the dry run changed.

This deck was planned in June and the lab was run today, before it was written. The plan survived mostly intact. Where it did not, the slide changed, not the run.

Every VCN lab gets run before it gets taught. It is the cheapest quality gate we have: tonight it cost about twenty minutes and it caught two failures that pass silently and would have reached fifty laptops.

Step 0

Pick work that does not share a file.

Open your own repo. Name three tasks that touch disjoint sets of files. Independence is the whole game, and this is the only step where you get to choose it.

# from your repo root. ../sw/ sits NEXT TO the repo, not inside it.
git worktree add ../sw/01 -b task/01
git worktree add ../sw/02 -b task/02
git worktree add ../sw/03 -b task/03
git worktree list   # want 4 rows: main + 3

# from your repo root. ../sw/ sits NEXT TO the repo, not inside it.
git worktree add ../sw/01 -b task/01
git worktree add ../sw/02 -b task/02
git worktree add ../sw/03 -b task/03
git worktree list   # want 4 rows: main + 3

# PowerShell. same commands; mind the backslashes in output.
git worktree add ..\sw\01 -b task/01
git worktree add ..\sw\02 -b task/02
git worktree add ..\sw\03 -b task/03
git worktree list   # want 4 rows: main + 3

# on a cloud box, put the trees on the same volume as .git
cd ~/work/your-repo
git worktree add ../sw/01 -b task/01
git worktree add ../sw/02 -b task/02
git worktree add ../sw/03 -b task/03
git worktree list

Checkpoint · hard gateFour rows from git worktree list, three distinct branch names. If two of your three tasks want the same file, they are one task. Merge them now, before an agent touches anything.

Step 1

One agent per tree, and give it a name that survives.

One terminal per worktree. z.ai + Claude Code drives each worker; Nebius credits fuel the fleet. The identity lines are not decoration - they are the fix for slide 6.

# identity via ENV, per process. never `git config` - that writes
# the SHARED .git/config and races (slide 6).
export GIT_AUTHOR_NAME="agent-01"    GIT_AUTHOR_EMAIL="01@swarm.local"
export GIT_COMMITTER_NAME="agent-01" GIT_COMMITTER_EMAIL="01@swarm.local"

cd ../sw/01 && claude -p "Implement task 01: <scope>.
   Stay in this directory. Do not read or edit files outside it.
   Commit when the tests are green."

The brief, in three rulesTight scope (one task, named). Stay in your tree (no cross-task reads - agents must not coordinate). Commit on green (a branch is the handoff, not a diff you paste). Isolation is enforced by the filesystem, not by trust.

Step 2

Poll the fleet. Do not help.

While the workers run, you are a scheduler: who is alive, who has landed a commit, who is stuck. Resist opening an editor. The moment you edit, you are a fourth worker with a global view.

git worktree list                  # who exists

# last commit in each tree - the fleet's status board
for d in ../sw/*; do (cd "$d" && \
  echo "$(basename $d): $(git log --oneline -1)"); done

# 01: 3ae983f agent-01 task01: second pass
# 02: 7e0e380 agent-02 task02: second pass
# 03: 633fe2b agent-03 task03: second pass

CheckpointEach tree shows a commit authored by its own agent. If two rows share an author name, your identity scoping is broken and you have the slide 6 bug - fix it before you merge, because after the merge the attribution is permanent.

Step 3

Fan-out is parallel. Fan-in is one at a time.

The temptation is to merge everything at once and let git sort it out. Do not. Merge serially, so that when something conflicts you know exactly which branch introduced it.

git switch main

git merge --no-ff task/01    # clean: disjoint files
git merge --no-ff task/02    # clean
git merge --no-ff task/03    # CONFLICT (content): src/config.ts

# --no-ff keeps a merge commit per agent, so the graph still shows
# WHO did what after the fan-in. a fast-forward erases that.

CheckpointTwo clean merges and one conflict is a normal, healthy result - that is exactly what tonight's dry run produced. A swarm that never conflicts probably had tasks too small to be worth fanning out.

Step 4

Resolve by intent, not by line.

Two agents both edited the one file you thought was nobody's. Neither is wrong. The merge is not a contest to pick a winner - both features are supposed to survive.

export const VERSION = "0.1.0";
<<<<<<< HEAD
export const AUTH_ENABLED = true;      # agent 01 wanted this
=======
export const DOCS_URL = "/docs";       # agent 03 wanted this
>>>>>>> task/03-docs

# resolution: KEEP BOTH. neither intent excludes the other.
git add src/config.ts && git commit

When it is not this easyHand the conflict to a fresh agent with both intents as context - it has no stake in either branch. And note what the conflict told you: your split was imperfect. That file belonged to one task, not two.

The conflict git cannot show youThe dangerous one is the semantic conflict: both branches merge clean, no markers, and the result is still wrong - agent 01 renamed a field, agent 02 wrote a caller for the old name in a different file. Measured at 5 to 10 percent of parallel-agent runs (CodeCRDT, arXiv 2510.18893). Git will never flag it. Run the tests after the LAST merge, not after each one - that is the only place it surfaces.

Step 5

Unlink first, then remove.

Stale trees pile up and stale branches pile up faster. But if you linked anything into a worktree to make it cheap, the order of these commands is the difference between a cleanup and a data loss.

# 1. drop any link you put INSIDE the tree, first.
#    rmdir removes the link only. rm -rf follows it and deletes the target.
rmdir ../sw/01/.venv          # macOS/Linux: unlink ../sw/01/.venv

# 2. now the tree can go.
git worktree remove ../sw/01
git worktree prune            # clears stale metadata
git branch -d task/01         # -d refuses if unmerged. keep it -d.

Checkpointgit worktree list is back to one row. If you skipped step 1 and something outside the repo is now empty, that is slide 9, and it exited 0 while doing it. Keep -d rather than -D: the refusal is the only thing standing between you and deleting an agent's unmerged work.

When to fan out, and when not to.

You will over-apply this by Friday. Here is the line, and it is sharper than "it depends".

Those last two numbers are measured, not ours: CodeCRDT (arXiv 2510.18893) ran 600 trials of parallel LLM code generation and found up to 21% speedup on some task shapes and 39% slowdown on others. Fanning out is not free and it is not always a win. The test is one sentence: parallelize work that does not share a write surface. If two tasks edit the same file, they are one task, and splitting them converts a five-minute edit into a merge you reason about twice.

You came with one agent. You leave with a fleet.

Four things are running on your laptop right now that were not at 7pm.

Bring a repo with more than one thing to do. Split it where nothing overlaps. Let them run.