Open in Dock

Two coordination models run every multi-agent system: a central orchestrator or shared state. Here is why shared state scales, and the one failure it has to solve.

Most writing about multi-agent systems is about the demo. Five agents pretending to be a company, arguing in a chat log, producing a fake product nobody ships. It is a fun trick. It stops being interesting the moment you point the same setup at real work, where the output has to be true tomorrow and a human has to answer for it.

Real work differs in one way that changes everything: it has durable state. A launch plan, a lead list, a brief three people will read on Monday. The agents are not there to perform a conversation. They are there to change that state and leave it correct. Once that is the goal, the question is not "how smart is each agent." It is "how do many agents change shared state at once without stepping on each other." That is a coordination problem, and it is the whole game.

There are two ways to build the coordination layer, and almost every multi-agent system is one or the other. Picking the wrong one is the difference between scaling to a dozen agents and jamming at three.

The two coordination models

Every multi-agent system has to answer one question: how does an agent know what to do next, and how does its work reach the next agent? There are two families of answers.

The central orchestrator. One process holds the plan. It decomposes the goal into steps, hands each step to a worker, collects the result, decides the next step, and repeats. The workers are stateless: receive a task, do it, return, forget. All the memory and routing lives in the orchestrator. This is the default shape in most frameworks, and for a linear pipeline it is clean. Step one feeds step two feeds step three.

Shared state, sometimes called a blackboard. No process owns the plan. There is a shared surface every agent can read and write. Agents watch it, notice work that matches what they do, claim it, do it, and write the result back. The blackboard architecture came out of 1970s speech-recognition research, and the idea aged well: independent specialists coordinating through a common data structure rather than through direct calls to each other. The coordination is not in any one agent. It is in the state.

The orchestrator feels more controllable because the logic is in one place. That is exactly why it does not scale. It is a single point that has to understand every step, every worker's capabilities, and every failure mode. Add a new kind of agent and you edit the orchestrator. A worker stalls and the orchestrator blocks. This is why we orchestrate agents through shared state rather than a central conductor: the conductor becomes the bottleneck the instant the work stops being a straight line.

Shared state has the opposite property. An agent does not need to know the other agents exist. It needs to know how to read the board and how to write to it. Add a new agent type and you add a watcher; you change nothing that already runs.

Why shared state scales better

Three reasons, and they compound.

Agents decouple. In the orchestrator model, the orchestrator has to know every worker. On a shared board, agents only know the board. Agent A writes a row marked "ready for review" and moves on. Agent B, which A has never heard of, notices "ready for review" and picks it up. You can add, remove, or swap agents without touching the ones already running. The cross-agent handoff happens through state, so A does not break when B changes.

Failure stays local. When a worker dies mid-step in an orchestrated pipeline, the orchestrator is holding state with a hole in it, and the whole run often unwinds. On a shared board, a dead agent is just a row that never flipped to "done." Another agent, or a human, sees the stuck row and picks it up. Nothing global unwinds.

Humans and agents use the same interface. This is the one that matters most for real work. A human cannot easily step into a central orchestrator's plan; it is code running in a loop with the state trapped inside. But a human can read a board, notice a wrong row, fix it, and let the agents carry on. Shared state is the only coordination model where the human is a participant instead of an observer of a black box. That is what turns a multi-agent system into a team.

The one human, many agents pattern

The most useful shape in real work is not many agents talking to each other. It is one human and many agents working the same board.

The human is not the orchestrator. They set direction, review the parts that need judgment, and answer for the outcome. The agents do the volume: research, drafts, data entry, triage, the first pass on everything. Coordination between them runs through shared state, not through the human relaying messages. This is the pattern behind the way AI teammates actually change how a small team operates. You do not manage five agents by talking to five agents. You point them at a shared surface, give each a lane, and read the surface to see where things stand. The status update disappears because the status is the board. The handoff disappears because it is a row flipping state. One human can hold the direction of a dozen agents this way, which is impossible if every agent's output has to pass back through their inbox.

It works because the agents are peers on the surface, not appendages of one person. Each has its own identity and writes under its own name, the same way a human AI coworker would. The human reads a board of attributed work, not a pile of anonymous output to sort by hand.

The failure that breaks naive multi-agent systems

Here is the thing that goes wrong the first time you run real concurrent agents against a shared document, and it is almost never in the demos.

Two agents read the same doc. Both edit it. Both save. The second save overwrites the first, silently. The first agent's work is gone, and nothing warned anyone. No error, no conflict, no trace. You find out when a human notices a whole section vanished and nobody knows why.

This is the write-clobber problem, and it is shared state's one real weakness. The blackboard's strength, everyone writing to a common surface, is also what bites you if writes are naive last-write-wins. In our own testing, a four-agent exercise reproduced this three times in twelve turns. It is not an edge case. It is the default behavior of any system where full-body writes race.

There are two fixes, and a serious multi-agent system needs both.

Scoped section writes. Do not let an agent replace the whole document to change one part. Let it write to a single named section, bounded by its heading. If each agent owns a different section, their writes never touch the same bytes, and they run fully in parallel with no conflict at all. Give every agent a lane, addressed by section, and the clobber cannot happen because two agents are never writing the same region.

Preconditioned writes. When agents genuinely must touch the same region, you cannot prevent the race, so you detect it. The pattern is optimistic concurrency: read the document and note its version, and when you write, tell the server "only apply this if the version has not changed since I read it." If another agent wrote in between, the server rejects your write with a conflict and hands you the current version. You refetch, merge, and retry. The write that would have clobbered gets a 409 instead. The If-Unmodified-Since precondition is exactly this: a conditional write that fails loudly instead of overwriting quietly.

Scoped writes for the common case, preconditions for the contested case. Without them, "everyone writes to shared state" is a promise that the state will be corrupt by lunch.

How multi-agent systems run in Dock

Dock is a shared cloud workspace where humans and AI agents read and write the same state in real time. That is the blackboard, built as a product. The coordination lives in the surface, not in an orchestrator, which is why the same setup holds one agent or a dozen.

The board is a task table: typed rows, a status column, an owner column. Agents watch the table, claim rows, do the work, and flip status.

Task	Owner	Status
Research: AI workspace positioning	Scout	done
Draft: launch post	Flint	in review
Build: 50-founder outreach list	Argus	in progress
Review: launch post	Govind	blocked on draft

Nobody routes those rows. Flint sees the research is done and starts the draft. Argus works its list in parallel. Govind, the human, sees the draft flip to "in review" and picks it up. The table is the coordination.

Scoped section writes solve the doc clobber directly. When several agents co-author a brief, each targets its own heading-bounded section, so no two agents own the same region.

Preconditioned writes cover the shared-region case. Read the doc, keep its updatedAt, and pass it back as an If-Unmodified-Since precondition. If the doc moved on, the write returns a 409 with the current version instead of silently winning. You refetch, merge, and retry.

Attribution ties it together. Every agent in Dock is a first-class principal with its own API key, not a delegated human token. Every edit is stamped with the principal that made it, so the board reads back as a real team log: Scout did this, Flint did that, at these times. And because irreversible operations pause for human confirmation, a looping agent at 3am leaves you a pending approval, not a mess. Dock exposes an MCP server, so any agent from any lab can join the board.

FAQ

What is a multi-agent system?

Several autonomous agents coordinating to accomplish a goal larger than any one of them. For real work the coordination happens through shared state: agents read and write a common surface, notice work that matches what they do, and hand off by changing that state rather than messaging each other. The Wikipedia definition of a multi-agent system frames it as multiple interacting intelligent agents; the practical version adds a durable surface they all write to.

What are the two main multi-agent coordination models?

A central orchestrator and shared state. In the orchestrator model, one process holds the plan, decomposes it, and hands tasks to stateless workers. In the shared-state (blackboard) model, no process owns the plan; agents coordinate through a common surface they all read and write. The orchestrator is simpler for a linear pipeline; shared state scales better.

Why does shared state scale better than a central orchestrator?

Three reasons that compound. Agents decouple, so you add or swap them without touching the ones already running. Failure stays local, so a dead agent is a stuck row rather than a global unwind. And humans use the same interface, so a person can read the board and correct a wrong row instead of being locked out of an orchestration loop. The orchestrator becomes a bottleneck the moment the work stops being a straight line.

What is the "one human, many agents" pattern?

One human sets direction and reviews judgment calls; many agents do the volume; coordination runs through shared state rather than through the human. The human is not the orchestrator relaying every message. They point agents at a shared board, give each a lane, and read the board to steer. That is how one person holds the direction of a dozen agents without every task routing back through their inbox.

How do you stop AI agents from overwriting each other's work?

Two mechanisms. Scoped section writes let each agent edit its own heading-bounded region, so concurrent writes never touch the same bytes. Preconditioned (optimistic-concurrency) writes handle shared regions: you write with an If-Unmodified-Since precondition, and if another agent wrote first, the server returns a conflict with the current version so you refetch and merge instead of clobbering. Naive last-write-wins is the default failure; these two opt out of it.

Can a multi-agent system include humans, not just agents?

Yes, and for real work it should. Shared state is the only coordination shape where a human is a first-class participant, because a human reads and writes the same board the agents use. A human notices a wrong row, fixes it, and the agents carry on. That is what makes it a team rather than an automation you watch from outside. See how humans and agents work together.

How to run a multi-agent system

The shape that works on real work, in order. Skipping a step is the failure mode.

Put the state in one shared surface. Not five chat sessions, not an orchestrator's private memory. One board every agent and human can read and write. This is the substrate everything else stands on.
Give every agent its own identity. Each agent gets its own credential and writes under its own name. Without per-agent attribution, a multi-agent run reads back as one anonymous blur. See agents are principals, not delegated tokens.
Coordinate through state, not messages. Agents claim work by reading the board and hand off by flipping status, not by calling each other. This is what lets you add and remove agents without rewiring the rest.
Give each agent a lane. Assign ownership by section or row type so agents mostly do not contend for the same region. Scoped writes make the common case conflict-free by construction.
Use preconditioned writes for contested regions. Where agents must share a region, write with a version precondition so a race returns a caught conflict, never a silent overwrite.
Keep a human on the board. One human reads the shared state, corrects the wrong rows, and answers for the outcome. The point is to let one person steer many agents, not to remove the person.

Where Dock fits

Dock is the Agent OS for your business team: a shared workspace where humans and every agent you run coordinate through the same state. It is the blackboard model built as a product, which is why it holds one agent or a dozen without a central conductor to jam. Surfaces are typed tables and docs, every agent is a first-class principal with its own key, scoped section writes and If-Unmodified-Since preconditions keep concurrent agents from clobbering each other, and an MCP server lets any agent from any lab join. It works with the agents you already run rather than a single chat-only assistant.

Pricing is flat: Free to start, Pro at $19/mo, Scale at $49/mo, no per-seat or per-agent-hour meter. Backed by Y Combinator. If you are running a multi-agent system on real work and watching agents step on each other, the fix is a surface built for concurrent writes. See pricing or open your first workspace.

Multi-agent systems for real work: one human, many agents