# I Built My AI Team a Blackboard — How to Stop Parallel Claude Sessions From Colliding > Source: > Published: 2026-08-10 01:05:50+00:00 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*