Most days I have somewhere around a dozen Claude Code sessions running against my repos at once: building Blink, grinding kazi goals, doing research, writing docs. People hear that number and picture chaos. It's less chaotic than a five-person team, honestly, because the coordination problems are the same ones distributed systems already solved, and I stole the solutions instead of inventing new ones.
One lead, named workers
The shape is a lead session and a set of named workers, blink-a, blink-b, blink-c, and so on. The lead doesn't write much code itself. It reads the board, decides what's next, and dispatches. Workers claim a lane, do the work, report back, go idle or get reassigned. It's a small org chart, except every employee can be spun up in ten seconds and never asks for a raise.
Two coordination layers, not one
The part that took longest to get right was realizing I needed two separate coordination mechanisms doing two separate jobs, not one mechanism trying to do both.
There's an ephemeral message bus for pings: "done with X," "blocked on Y," "starting Z." It's fast and cheap and it's exactly what you'd expect from a chat channel between agents. It's also unreliable in a specific way: messages get lost. A session crashes mid-send, a context window fills up before it reads its inbox, a worker goes dark between one tool call and the next. None of that is a bug in the bus. It's just what happens when you have a dozen independent processes talking over something that isn't durable.
So the actual system of record is a markdown file, a coordination board that every session reads before acting and writes to after acting. Files don't get lost. If a worker dies with three hours of undocumented context in its head, the board still has whatever it wrote down, and the next session that picks up the lane starts from that, not from nothing. The bus is for urgency. The board is for truth.
Claimed, not assigned
I don't hand out tasks by typing "you do X, you do Y" into each session, because two sessions racing for the same file is a real failure mode, not a theoretical one. Work gets claimed instead, through atomic locks implemented as git refs. A session tries to grab a lane by pushing a ref; git's own atomicity means only one push wins. There's no window where two sessions both believe they own the same task, because the lock isn't a convention I'm trusting them to respect, it's a property of the thing they're pushing against.
This is the same trick every distributed system uses for leader election and resource locking: compare-and-swap on something that can only be written once. I didn't design it fresh. I just noticed the problem was the same problem and reached for the same tool.
Sessions go dark, and that's fine
Sessions die without warning constantly. Hit a context limit, crash on a bad tool call, get closed because I needed the terminal for something else. In a single-session workflow that's a lost afternoon of unrecorded reasoning. In this setup it's a shrug, because the board is where the durable state lives, not the session's context window. Whoever picks up the lane next reads the board, not the dead session's memory.
Every decision comes to me as a card
The one rule I enforce hardest across all of this: no session asks me anything in prose. Every decision that needs my input, which approach, is this a blocker, can I delete this, comes as a multiple-choice question with a recommended option. I have a dozen terminals open. A question buried in a paragraph of status update is a question I will miss, and a missed question is a session sitting idle for six hours waiting on an answer that was never going to come unprompted. A card I can clear in one glance between other things. Prose I have to actually stop and read.
It's managing a team
None of this is agent-specific wisdom, really. It's what you'd build for any team of workers who don't share memory, might disappear mid-task, and need a source of truth that outlives any one of them. Turns out managing a fleet of Claude sessions and managing a team of contractors converge on the same answer: durable written state beats verbal handoffs, locks beat trust, and nobody should have to guess what you're actually asking them.