You can open eight terminals right now, start Claude Code in each, and point all of them at the same repository. Nothing stops you. What you get is eight capable engineers who have never met — each in its own process, its own context window, blind to what the other seven are doing to the files under their feet. One renames a function; the others never hear about it. Two reach for the same file, and the second silently clobbers the first. The git index they share stops being a convenience and becomes a loaded weapon.
The industry has a name for fixing this, and the name is orchestration. The shelves are full of it: directed-graph runtimes, role-based crews, conversational group chats, cross-vendor wire protocols with cryptographic agent identities. Most of it is real engineering aimed at a real problem. Almost none of it is what you need when the eight engineers are sitting at the same desk.
I told the story of what eight Claude Code instances actually built in Converge, Not Fork — the culture they reconstructed, the contracts they negotiated, the moment one of them publicly retracted its own design rather than ship a fork. This is the other half of that story: the machine that let them talk. It is not a framework. It is a shared log and three hooks, and the reason it works is that it quietly implements the oldest coordination pattern in artificial intelligence.
The hard part was never coordination
Start with the question the frameworks answer, because they answer it well: when does running several agents beat running one?
The clearest published answer comes from Anthropic's own multi-agent research system. It is an orchestrator-worker design: a lead agent plans a research strategy, spins up three to five subagents that each explore an independent thread in their own context window, and synthesizes their condensed findings into one answer, with a separate pass for citations. On Anthropic's internal research eval, the multi-agent version outperformed single-agent Claude Opus 4 by 90.2% — a figure worth reading as a vendor's own benchmark, not an independent result — while burning roughly fifteen times the tokens of an ordinary chat. That token multiplier is the price of admission, paid on purpose, and it only pencils out for high-value breadth-first work.
The lesson Anthropic drew from building it is the one that matters here: architecture follows task structure. Multi-agent orchestration wins when the task decomposes into independent parallel threads — many searches, many documents, many leads, recombined at the end. Fan the work out, let the workers run, gather the results. The orchestrator never touches the work itself; it plans, dispatches, and reconciles.
Now look at the task in front of our eight terminals. It does not decompose into independent threads. It is the opposite: several agents converging on one artifact, editing one tree, racing for the same files. There is nothing to fan out and gather. The agents do not need a manager to divide the work and reassemble it. They need to see each other.
This is the inversion the orchestration literature mostly misses. Coordinating co-located coding agents is not a delegation problem. It is a shared-memory problem — and shared-memory problems have a different, older answer.
The design space you'd otherwise reach for
If you strip away the branding, multi-agent coordination reduces to a handful of primitives that recur across every framework:
Fan-out / fan-in scatters independent subtasks across workers and merges the results — Anthropic's research system, and the right shape for parallel search or auditing separate modules. Pipelines chain one agent's output into the next, a linear plan-implement-review. Hierarchical delegation puts a supervisor over specialists. Handoff chains pass control from agent to agent as the task shifts. Consensus runs several agents on the same problem and has a judge pick or merge the best. And the blackboard: agents read and write a shared state, and a controller wakes them when the parts they care about change.
The frameworks each bake in some subset of these. OpenAI's Agents SDK (March 2025) makes handoffs explicit and ships guardrails and tracing, at the cost of binding you to one vendor's models. LangGraph models a workflow as a directed graph with typed state and checkpointing, which buys you time-travel debugging and human-in-the-loop approvals — and costs you a verbose graph definition even for trivial flows. CrewAI leans on a role-and-backstory metaphor that is quick to prototype but gives you little control over how agents actually talk. Microsoft's AutoGen / AG2puts the agents in a conversational group chat where they debate and critique — natural for review, expensive because every turn is a full model call. Google's Agent Development Kit builds a hierarchical agent tree and speaks the cross-vendor wire protocol. And Anthropic's Claude Agent SDK takes a tool-use-first stance, with MCP as the standard conduit to external systems.
Above the frameworks sit the protocols, for when agents must reach across machines and vendors. MCP standardizes how an agent reaches a tool — the vertical layer, agent-to-tool. A2A, launched by Google in April 2025 with a stated fifty-plus partners and since handed to the Linux Foundation under vendor-neutral governance with 150-plus organizations now behind it, standardizes how agents reach each other — the horizontal layer, agent-to-agent, with signed agent cards for identity. The two are complementary, and both are built for scale, distribution, and heterogeneity.
Every one of these is the right tool for some shape of work. None of them is the right tool for eight Claude Code instances on one disk, because all of them are solving for routing, delegation, or cross-network transport — and the agents at our desk don't need any of those. They share a filesystem. The shared state already exists. What they lack is a way to see it and a way to be woken when it changes.
That is the blackboard, and only the blackboard.
The oldest pattern in the room
The blackboard architecture is not new and it is not from the LLM era. It comes from Hearsay-II, the speech-understanding system built at Carnegie Mellon in the 1970s. The idea: independent knowledge sources never address each other directly. They read from and write to a common structure — the blackboard — and a control mechanism notices when a region of the blackboard changes and wakes whichever source has something to contribute. No source needs to know the others exist. The shared state is the entire communication channel.
Hold that next to several agents editing one repository and the fit is exact, not analogical. The blackboard is the working tree and the message log on the disk they share. The knowledge sources are the Claude Code instances. The thing that has been missing — the only thing — is the control mechanism: something to wake an agent when the shared state has news for it, and something to keep an agent from walking away while a teammate still needs it.
A blackboard needs no orchestrator by definition. There is no lead, no router, no agent that plans and dispatches. Coordination is a property of the shared state and the rules for touching it, not of a coordinator. Which means the whole apparatus can be small — small enough to be a single file and a few scripts.
The implementation: a shared log and three hooks
Here is the entire system. It is dependency-free Python on top of two things every Claude Code user already has: SQLite, and the hooks that fire at fixed points in a session's life.
The transport is one SQLite database. It runs in WAL mode, which lets many readers proceed alongside a writer without anyone tripping over a lock — exactly the concurrency profile of several agents on one disk, and the reason no server and no network are required. Two tables carry everything:
messages id (monotonic) · ts · sender · kind · body · mentions[]
agents session_id · handle · cwd · pid · status · last_read_id
messages is an append-only log. Each row has a monotonically increasing id, the sender's handle, the body, and a mentionsarray parsed out of any @handle tokens. agents holds one row per live session, and the load-bearing column is last_read_id: a single cursor per agent. "Unread" means nothing more than id > last_read_id. There is no read-receipt table, no per-message delivery tracking, no second cursor. One monotonic number per agent is the complete delivery model, and the invariant that keeps messages from being shown twice or dropped is exactly as simple as it sounds: surface everything past the cursor, then advance the cursor past everything you surfaced.
The three hooks turn that log into something seamless. Each reads the hook payload Claude Code hands it on stdin, imports the transport module, and — this is non-negotiable — fails open. A hook that raises or exits non-zero on the wrong event doesn't just misbehave; a UserPromptSubmit hook that exits 2 will block the user's own prompt. Every handler is wrapped so that any error becomes a clean exit. A coordination layer that can break a session is worse than no coordination layer.
SessionStart registers the new session, assigns it a handle, and injects a briefing — who else is active, what's been said recently — through additionalContext, the field whose contents Claude reads on its first turn. It then marks that history as read, so the next turn doesn't dump it all over again.
UserPromptSubmit runs before every turn. It injects whatever has been posted since this agent's cursor, then advances the cursor. When nothing is new, it says nothing. New messages simply appear in the agent's context, on their own, before it acts — no polling, no read loop.
Stop is where the cleverness lives, and it deserves its own section.
The Stop hook is the coordination primitive
The frameworks assume an agent is a process that is always running, always available to receive a message. A Claude Code session is not that. It acts only on a driving turn — a user prompt, or a Stop hook that blocks and hands control back. Between turns it is inert. You cannot push a message to it; there is nothing listening. This is the constraint no orchestration framework has to deal with, and it is why the genuinely novel piece of this design is not the message bus at all. It is the use of the Stop hook to manufacture availability out of a turn-driven runtime.
When an agent tries to finish, the Stop hook does three things in order.
First, if there's an unread message that @mentions this agent, it returns decision: "block", which prevents the agent from stopping and continues the conversation — and hands the mentioning messages back so they aren't lost. The agent answers its mention before it's allowed to leave. General chatter is deliberately not blocked on; it waits for the next prompt. Only a direct mention interrupts, which is what keeps a busy room from nagging everyone about everything.
Second, if the inbox is empty, the hook reads "trying to stop with nothing waiting" as the agent's signal that its slice is done, and marks it so. No new ritual, no special command — stopping cleanly is the done signal.
Third — and this is the part with no analogue in the framework world — the hook consults a team barrier. A finished agent does not exit. It parks: the Stop hook blocks in a sleep-poll loop, roughly a 570-second window in ticks of a couple of seconds, well inside the hook's timeout. While it sleeps, no model call happens, so by construction the parked agent costs essentially nothing — it is dormant, not thinking. But it is still alive, and a teammate's later @mention wakes it, lets it reply, and sends it back to sleep. The agent leaves only when the whole team is done, or when a hard ceiling releases it regardless.
Why bother? Because the failure mode this prevents is specific and infuriating. Several agents run the same goal in tandem. One finishes first and exits. Twenty minutes later another agent realizes it needs the first one — to reconcile a contract, to answer a question only it can answer — and there is no one there. The session is gone. In a normal team you'd just message your colleague; here, the colleague evaporated the moment it ran out of its own work. Parking keeps the colleague at their desk, asleep but reachable, until the work is collectively finished.
A barrier like this has two classic ways to go wrong, and the design closes both. A ragged start — a fast agent finishing and parking before its slower teammates have even registered, finding an empty barrier and leaving prematurely — is handled by a startup guard: either declare the team size up front and require that many registrations, or fall back to a ninety-second grace window in the zero-config case. A wedged team — one crashed agent that never reports done, holding everyone else hostage forever — is handled by aging silent agents out of a fifteen-minute active window, and by a thirty-minute ceiling that releases any continuously-parked agent no matter what. A mis-set team size can make the system inefficient. It cannot make it hang.
Two more details make it portable. Identity comes from a fixed pool of handles — ada, turing, hopper, and on down — assigned to the lowest free name on first contact; an agent need only remember its own handle to post, and never has to know its own session id. And the store location is resolved by anchoring to the git common directory, which means every worktree of one repository lands on the same database. Run each agent in its own worktree for branch isolation, and they still share one chat. The coordination layer rides along in each checkout; the live database is gitignored.
That is the whole system. A log, a cursor, three hooks, a barrier.
Leaderless on purpose
It is worth being precise about how far this goes, because Claude Code now ships its own answer to the same problem. The agent teams feature — experimental, behind a flag, recent — lets multiple sessions coordinate through a shared task list with direct messaging between teammates. It is a real, well-built feature. But its model has a team lead: one session that coordinates, assigns tasks, and synthesizes. It is, in the vocabulary above, hierarchical delegation with a messaging layer. There is an orchestrator; it is just an orchestrator made of the same stuff as the workers.
The shared-log bus has no lead. No session plans the work, assigns it, or reconciles it. Every agent is a peer reading and writing the same blackboard. When two of them reach for the same surface, neither escalates to a manager — one yields, explicitly, with a reason, and the resolution is recorded in the log where everyone can see it. The thing that makes a leaderless design hold together is not a coordinator filling the gap. It is a shared set of values precise enough that independent agents appeal to it and reach the same verdict — the twelve numbered rules in the repository's CLAUDE.md, cited by number across the chat like case law. Converge, Not Fork is the field evidence that this actually produces convergence rather than chaos: eight instances, one tree, no manager, and no deadlock or silent overwrite across an afternoon of building.
This is the real claim, and it is sharper than "you don't need a framework." It is that for agents sharing mutable state, the coordinator is the wrong abstraction. What you need is a place to write things down and a rule set worth appealing to. The orchestrator was never load-bearing; the shared memory and the constitution were.
When to graduate
None of this argues the frameworks away. It argues them into their proper scope, which is the scope Anthropic named: architecture follows task structure.
The shared-log bus is for one machine, or several machines on one filesystem. The transport is a file; that is its whole strength and its whole limit. The moment you need agents on different hosts, the SQLite layer has to become a networked store — and the design's nicest property is that this swap touches only the transport, never the hooks, because the hooks only ever talk to the log through a thin interface. For genuinely cross-vendor or cross-network coordination, that is where A2A earns its cryptographic agent cards and MCP earns its tool schemas. For work that really is a branching graph with checkpoints and human approval gates, that is where LangGraph's verbosity becomes a feature. For breadth-first research that fans out into independent threads, that is where the orchestrator-worker pattern and its fifteen-fold token bill are simply correct.
Reach for orchestration when the task is independent threads recombined at the end. Reach for the blackboard when it is several hands on one artifact. The mistake is reaching for the first when you have the second — paying for routing and delegation and distributed transport to solve a problem whose entire substance is a shared file and the discipline not to corrupt it.
The discipline was the product
It is tempting to read all this as a trick: replace a heavy framework with a clever little hack and save yourself the trouble. That is not the finding. The finding is that the trouble was never where the frameworks put it.
Watch eight agents work in one tree and the bottleneck is never intelligence and never message routing. It is the same bottleneck human teams have always had — shared mutable state, and the agreement on how to touch it without ruining it. The agents that succeeded did it by inventing, in real time, the things every functioning engineering culture already knows: announce before you act, own a small surface, make agreement a test result rather than a vibe, and write your principles down somewhere everyone reads them. The shared log didn't supply any of that. It just gave the discipline a place to happen.
Which leaves a question worth sitting with. If the coordinator was never the hard part — if a forty-year-old pattern and a dozen numbered rules are enough to make eight language models converge on one codebase without a manager — then the thing we are actually building, when we build multi-agent systems, is not better orchestration. It is better constitutions. And nobody yet knows how large a team one constitution can hold.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.