Four sessions,
one body of work.
Swarm mode splits a spec across workers inside one session. Org mode splits it across sessions. Each peer is a full Claude Code session with judgement of its own. That is what makes one boundary carry the whole design: when a peer decides, and when it escalates.
A second axis
Article II governs what happens inside one session: decisions live in the main context, and subagents only run recipes that were already decided. Org mode adds a second axis, and leaves the first one untouched.
The distinction is worth getting right, because the two look similar from outside. A subagent has no context of its own worth trusting, so it gets a recipe. A peer session, by contrast, is a complete Claude Code instance with its own memory, its own hooks, and its own main context where Article II applies in full, so handing it a recipe would waste the judgement that makes it useful.
So peers get lanes. A lane is a slice of an approved spec with a declared write set, and the peer which claims it decides for itself how to build it.
The flat pod
Up to four peers work one spec at a time. They talk over a coordination broker that runs on your machine, on a Unix socket, with the project as its working directory.
The pod is flat for claiming: any free peer may take any unblocked lane it is eligible for, and where two try at once the broker picks a single winner. One peer also wears the lead hat, which adds two duties and no extra claiming rights, namely settling what peers escalate and relaying the rest to you.
A peer stays a peer for the whole of its session. If the same person happens to be running the lead session in another window, the peer keeps working lanes regardless: it arbitrates nothing, answers no other peer, and claims every lane it is eligible for. The broker bakes each session's identity and role into the instructions it hands out, so a session always knows which one it is.
One more rule protects the pod's state. If a second broker arrives on an occupied socket it refuses and exits, because a silent takeover would split the pod, leaving half the peers talking to fresh state and half to the old. A socket left behind by a crashed broker is reclaimed, since that case is safe.
Lanes and who claims them
The lead reads the approved spec and cuts it into lanes along its dependency graph, and each lane carries an id, a write set, and whatever it depends on.
Leave the lane unassigned and the first free peer takes it. Simplest to run. One fast peer can hoover up the queue while the others sit idle.
Name a peer and only that peer may claim it. The broker enforces it, so a claim from anyone else is rejected. This is how the lead spreads load or puts a specific lane with a specific session.
When a peer finishes a lane it signals done, which unblocks whatever depended on that lane. Work therefore flows as a pipeline rather than stopping at a barrier every round, and a peer whose next lane is ready can start on it immediately.
Completion is checked every time. The broker pushes events as lanes are claimed and finished, but a push can go missing, so the lead treats those events as hints only and confirms against the channel status (which carries a flag the broker always keeps current).
The decide-or-escalate line
This is the line the whole model rests on, and it has exactly one test. Does the choice stay inside the lane?
An in-lane implementation choice belongs to the peer, which decides in its own main context and carries on exactly as any single session would. If routine choices went to the lead instead, every peer would end up queued behind one arbitrator and the pod would run slower than a single session.
A choice which reaches across lanes, or which the peer genuinely cannot settle, escalates instead. Guessing across lanes is the failure this rule exists to prevent, because two peers guessing about a shared boundary will produce work that only conflicts later.
peer yield_fork — a fork tied to one task ask_lead — a free-form question ↓ lead settles what it can, in its own main context answer_peer — routes the decision back ↓ you anything that needs human judgement
If an escalation cannot be delivered it comes back as an error and waits in the channel status. Losing one silently would leave a peer blocked on an answer nobody knows it asked for.
What stays with you
Every hook fires on every peer write. A guard which blocks a commit in a single session will block it in a pod as well, four times over, with identical logic each time.
The consent gates work the same way. Approving a direction, a swarm plan or a commit still means you typing a command, checked by a hook which runs before Claude is invoked. No peer and no lead can satisfy one, and adding sessions changes nothing there, since the check was never about which session was asking.
Org mode ships off. It waits behind velocity.org_mode.enabled and needs git, and where either is missing the engine refuses with a named reason. Four sessions on one repository is a real change in how a team works, which is the sort of change worth switching on deliberately.
The default pipeline is untouched by all of this. org is one more track you can pick at triage, and every other track runs exactly as it did before.