I Built My AI Team a Blackboard — How to Stop Parallel Claude Sessions From Colliding

A developer built a shared markdown 'blackboard' to coordinate multiple parallel Claude Code sessions after discovering that parallel AI agents collide because they lack shared context. The developer found that the industry already has tools and research on this problem, including Claude Code's experimental Agent Teams feature, but that feature is ephemeral and does not cover persistent coordination across days. The developer also learned that adding a reminder command to a pre-push hook accidentally overrode the hook's pass/fail signal, illustrating the pitfalls of hand-rolled coordination systems.

Series: Indie Dev Notes · T12 In the last post T11 , I said I'd turned my AI into a team and promoted myself from employee to CEO. This one is the reality sequel:the moment the team grew, it started crashing into itself. The way I develop now is to keep several Claude Code sessions open at once — one on the home page, one on orders, one sweeping governance debt. Each in its own git worktree a worktree: a separate working folder cut from the same repo, each on its own branch, files isolated from each other . Sounds great. Until one day: The common thread: these sessions have no idea what the others are doing. I the human became the only one who knew the whole picture — and my memory expires and gets things wrong. At first I thought the problem to solve was parallelism — how to run more agents at once. It wasn't. Parallelism is easy just open more sessions . The hard part is: when work is scattered across a pile of sessions over several days, there is no single place that remembers "who's doing what, how far, and what's left." Every new session is like an amnesiac new hire who has to re-grep keyword-search the whole codebase just to get oriented. The solo developer's bottleneck was never the AI's compute. It's my own context not being laid out and reconnected across sessions. What I made is crude: one markdown file. But it has rules: That's it. But it turns "I keep it in my head" into "the file keeps it," and it's the same single file shared by every session. Technical detail: I keep it on the mainline, and use a persistent worktree so any session can read/write it via the same absolute path — because an AI agent can read any path, not just its own working directory. That way even a session on a feature branch sees the same blackboard. I thought I was reinventing the wheel. A quick search showed the industry has studied this for ages: There are even off-the-shelf tools vibe-kanban, Claude Squad, Crystal … , and an academic benchmark studying whether AI coding agents can actually be your teammate CooperBench — its honest conclusion: not yet ; coordination is still hard . Halfway through researching, I found Claude Code has an experimental feature called Agent Teams — a lead session spins up a group of teammates, sharing one task list, grabbing tasks via file locks, handling task dependencies automatically. Almost exactly what I hand-rolled. But it doesn't cover my scenario: Agent Teams is ephemeral — one lead spins up a team on the spot, finishes, tears it down, one team at a time. My need is a persistent ledger across days, across independently-launched sessions. The two are complementary. That gave me a realization: when you hand-build something for your own pain, then discover the industry already named it — even supports it natively — that's not wasted effort. You independently verified the problem is real. You just hadn't read the paper yet. I thought writing the section above closed the topic. The real learning started when I used it — one of the sessions I coordinated with this blackboard was sharpening the blackboard itself very meta, I know . A few things I didn't see coming until they hurt: npm run board that pulls, straight from git, how long each branch has been idle and how far ahead/behind the mainline — a lie-detector for the hand-written progress note.And then the funniest, most worth-writing-down moment of this whole thing — I wanted the system to "automatically nudge me when I push a branch that isn't claimed on the blackboard." So I appended a "print a reminder" command to the end of my pre-push hook the gatekeeper script that runs automatically before a push . That one line ate the entire check's pass/fail signal. The hook was supposed to block the push when a governance check fails. But my reminder line always succeeds , and the shell's rule is "the whole block's success = the last line's success" — so from then on, regardless of whether the governance check passed, the hook reported "success." I had silently muted a safety net that blocks broken code, with my own hands. How did I catch it? I pushed a commit and the screen printed both "❌ governance check failed, push will be blocked" and "push succeeded." Two lines contradicting each other. That's the moment I realized what I'd done. This is a microcosm of the whole methodology: every layer of protection you add can accidentally break another layer. Which is why actually using it — dogfooding eating your own dog food, being your own first user — beats designing it beautifully. Only a real run surfaces the contradiction and shows it to you. As a bonus, this also let me fix a pre-existing problem sitting in the governance checks that had been failing but that nobody had pushed into until now. My board lives on the mainline, and my mainline triggers a cloud build on every push. Which means every claim = editing one plain-text file = a push = a full build — even though the build output is identical to last time. A plain-text board was quietly burning my limited free monthly build minutes. The fix is a path filter on the cloud side: only build when frontend code actually changes; docs / scripts / board commits skip automatically. This kind of invisible cost only surfaces when you actually wire the thing up — on paper you'd never think of it. By this point I felt it shouldn't only live in my own repo — it applies to anyone running multiple AI sessions at once, and it's absurdly light: one markdown file + one optional script + one line wired into your agent's rules. So I extracted it into a standalone public repo: 👉 https://github.com/dragon375014/agent-work-board MIT — use it anywhere, no attribution required It has: a copy-paste board template, that git lie-detector script, opening-ritual snippets for three tools Claude Code / Cursor / generic agents , and the full methodology English and Traditional Chinese . I agonized a bit over the name. I almost called it work-board-for-cross-session , but "cross-session" is insider jargon, long, and clunky. I landed on agent-work-board — short, and it's obvious at a glance that it's "a work board for AI agents to coordinate on." Leave the "why" to a one-line tagline; don't stuff it into the name. I deliberately did not bury it inside my heavier governance framework. Because this blackboard's value is exactly that it's "entry-level, universal, usable by anyone in five minutes." Hiding it under a high-barrier framework would hurt the very people it should serve most — you, just starting to feel "the more sessions, the messier it gets." If you're also pair-programming with AI on your own and starting to feel "more sessions, more chaos," here's my takeaway: Don't chase fancier multi-agent frameworks that's a problem teams are solving . Invest in the two most boring things: ① one persistent, cheap state that loads at the start of every session a blackboard , and ② a reusable "where things are and how to read them" agent, so every new session boots up smart instead of re-grepping from scratch. You're not managing a swarm of AIs. You're managing whether future-you, in another session, can pick up where present-you left off. And — the friction you feel right now collisions, not seeing what the others are doing isn't you doing it wrong. It's the frontier of this whole field; even big companies and research papers haven't solved it cleanly. You just hit it early. 本文原載於我的部落格： I Built My AI Team a Blackboard — How to Stop Parallel Claude Sessions From Colliding