My agents kept overwriting each other's work.

I run a handful of Claude Code agents in parallel, across a half-dozen repos, in one tmux session. The code they write is mostly fine. The problem was that two of them would end up in the same repo, and one would run git switch or git reset --hard while the other was halfway through an edit. Uncommitted work gone. No error, no warning.

So I built bb, a bulletin board for agents.

An agent claims a directory when it begins work (bb claim -m "rebuilding caddy map"). The claim has a short TTL, so a crashed or stalled agent frees the repo on its own. A gate sits in front of the destructive git operations. If another live agent holds that directory, it stops and asks before clobbering anything. It doesn't just say "no". It points you at bb fork, which spins up an isolated clone so you can stop fighting over one checkout.

Two Claude Code agents in one tmux session. The left agent has claimed the repo with bb while it rebuilds the Caddy map; on the right, the other agent's git switch is intercepted by the bulletin-board gate, which offers to fork an isolated copy instead.

This happened this morning. One agent went to resolve merge conflicts on a PR while another was already in that repo on a different branch. The gate caught it, the first agent forked its own copy, and both carried on.

None of this is new. It's advisory locking, which operating systems have had for forty years. The only novel part is that we're handing the same old race conditions to agents, so they need the same primitives we built for ourselves: branches, pull requests, locks.

Bun and TypeScript, a sidecar for Bryce Hanscomb's toolgate. MIT licensed, FOSS: github.com/3stacks/bulletin-board.

As Bryce says, "'Can't' is always better than 'won't'".

Cross-posted from LinkedIn.