Running one AI agent is easy. You give it a task, it does the task, you read the result.
Running five agents on the same project at once is a different problem, and it is the one that actually decides whether a team of agents is useful or just noisy. Two agents edit the same document and one silently overwrites the other. Three agents all decide they are responsible for the same task. An agent picks up work a second agent is still in the middle of. None of these are model failures. They are coordination failures, and coordination is what orchestration is about.
AI agent orchestration is the practice of getting multiple agents to work toward one goal: deciding who does what, in what order, how they hand off, and how they avoid clobbering each other's work. This is the guide to how it works and how to do it without the mess.
Two ways to coordinate agents
There are broadly two models for orchestrating a group of agents, and the difference matters more than any framework choice.
The conductor model. One orchestrator agent holds the plan and hands out subtasks. It calls agent A to research, waits, then calls agent B to write, waits, then calls agent C to review. The orchestrator is the single point that knows the whole picture. This is how most agent frameworks demonstrate orchestration, and it works well for short, linear pipelines that finish inside one run.
The conductor model has a ceiling, though. The orchestrator has to stay running for the whole job. If it dies, the plan dies with it. Nothing is durable unless the orchestrator writes it down somewhere. And every subtask result has to pass back through the orchestrator, which becomes the bottleneck and the single point of failure at the same time.
The shared-state model. Instead of one agent conducting, every agent reads and writes a shared surface, and coordinates through the state of that surface. The plan lives in a document. Tasks live in a table with a status column. An agent claims a task by flipping its status to "in progress," does the work, writes the result back, and flips the status to "done." Another agent watches for "ready for review" and picks it up. No agent has to stay alive for the whole job, because the coordination is in the shared state, not in any one agent's memory.
This is the model that scales, and it is the one Dock is built around. It is older than agents, too: it is how human teams have always coordinated, through a shared board that outlives any single person's involvement.
The failure that defines the problem
Here is the specific thing that goes wrong, because naming it is half of solving it.
When two agents write to the same place at nearly the same time, the naive result is last-write-wins: the second write silently erases the first. Agent A spends four minutes drafting a section. Agent B, working from a copy it read before A started, saves its own version half a second later. A's work is gone, no error, no warning. Multiply this across a busy workspace and you get a team of agents that quietly destroys its own output.
Solving this is not optional, and it is not something a smarter model fixes on its own. It is a property the coordination surface has to provide. There are two standard ways to provide it, and Dock uses both:
- Scoped writes. Instead of replacing a whole document, an agent updates one named section of it. Two agents editing two different sections never collide, so they can safely run in parallel as long as each owns its own piece. This is the cheapest mental model for a multi-agent loop: give every agent its own lane.
- Preconditioned writes. When an agent does need to replace something wholesale, it sends the version it started from along with its update. If the surface has moved on since then, the write is rejected instead of silently winning, and the agent re-reads, merges, and retries. This is optimistic concurrency, the same technique databases have used for decades, applied to agent edits.
The point is that orchestration is not only about assigning work. It is about making concurrent work safe. An orchestration approach that does not answer "what happens when two agents write at once" has not actually solved orchestration.
How agent orchestration works in Dock
Dock treats the workspace as the coordination substrate. Agents do not message each other to coordinate; they coordinate through shared workspace state. Here is what each piece does.
The table is the task board. A typed table with a status column is the shared plan. Each row is a unit of work. The status column ("todo," "in progress," "ready for review," "done") is the signal agents watch and change. An agent claims a row by setting it to "in progress" under its own identity, so it is visible to everyone that this agent owns this task right now.
The document is the plan and the output. A planner (human or a lead agent) writes the plan into a doc. Executor agents write their results into docs and rows. Because Dock supports scoped section writes and preconditioned updates, multiple agents can work the same document without the clobber problem described above.
Attribution is how you see the orchestration. Every edit is signed by the agent that made it, time-stamped, on the record. When you open the workspace later, the orchestration is legible: you can see which agent claimed which task, in what order, and what each produced. This is what makes a crew of agents auditable instead of a black box, and it depends on each agent being a real principal with its own key, not a shared account. The identity model behind it is in agents are principals, not delegated tokens.
Handoffs happen through status, not chat. Agent A finishes a brief and sets the row to "ready for review." Agent B is watching for that status and picks it up. Neither agent has to be running at the same moment. This is the cross-agent handoff pattern from the agent collaboration primer, and it is the durable alternative to the conductor model's live-orchestrator requirement.
Orchestration, in this model, is mostly a matter of designing the board well: the right statuses, the right ownership, the right review gates. The agents supply the work. The workspace supplies the coordination.
How to orchestrate a team of agents
- Put the plan in a shared surface, not in an orchestrator's head. Write the goal and the tasks into a document or table that every agent can read. If the plan only exists inside one running agent, the whole job dies when that agent does.
- Give every task an owner and a status. Use a table with a status column. One agent, one task, one clear state at a time. The status column is the coordination signal; keep the set of statuses small and unambiguous.
- Give each agent its own lane. Assign agents to different sections, tables, or task types so their writes do not collide. Where overlap is unavoidable, rely on preconditioned writes so a late write is rejected and retried instead of silently overwriting.
- Coordinate through state changes, not messages. Have agents watch for status changes and act on them, rather than sending instructions to each other. State-based handoff works even when agents run at different times.
- Keep attribution on every action. Make sure each agent writes under its own identity so the audit trail shows who did what. This is what lets you debug the orchestration when something goes wrong, and it is the only version that scales past a couple of agents.
- Review the trail, not every output. As the crew grows, read the workspace's history to judge whether the orchestration is healthy, the same way you would read a task board rather than interrogating each person.
FAQ
What is AI agent orchestration?
AI agent orchestration is coordinating multiple AI agents so they work toward a shared goal without conflict: assigning tasks, sequencing work, managing handoffs, and preventing agents from overwriting each other. It is the layer above a single agent's task execution, concerned with how a group of agents operates as a team rather than how any one agent does its job.
What is the difference between an AI orchestrator and a single agent?
A single agent executes a task. An orchestrator coordinates several agents toward an outcome. In the conductor model the orchestrator is itself an agent that assigns and sequences subtasks. In the shared-state model, which scales better, there is no single orchestrator: agents coordinate through the state of a shared surface, claiming and handing off work through a task board rather than through a central controller.
How do you stop multiple agents from overwriting each other's work?
Two techniques. Scoped writes let each agent edit its own named section so parallel work never collides. Preconditioned writes attach the version an agent started from, so if the surface changed in the meantime the write is rejected and the agent re-reads and retries instead of silently overwriting. A coordination surface that offers neither will lose work whenever two agents write at once.
Do I need an orchestration framework to run multiple agents?
Not necessarily. Frameworks help with the conductor model, where a live orchestrator sequences subtasks. But you can orchestrate a durable, larger crew with just a shared workspace: a task board with statuses, per-agent identities, and safe concurrent writes. The workspace-based approach survives agents crashing or running at different times, which the framework-only approach often does not.
How many agents can you orchestrate at once?
With the shared-state model, more than with a conductor, because no single agent has to hold the whole job in memory and no results funnel through one bottleneck. The practical limit becomes review capacity and how cleanly the work divides into non-conflicting lanes, not the coordination mechanism itself.
Where Dock fits
Dock is the shared surface that makes multi-agent orchestration durable. The task board, the plan document, per-agent identity, safe concurrent writes, and full attribution are the workspace's native primitives, not something you assemble on top of it. You design the board; the agents do the work; the coordination lives in state that outlives any single run.
If you are already running more than one agent and feeling the collisions, that friction is the coordination surface missing, not the models falling short. You can start free and give your crew a board to work on.
Read next
- AI teammates: how to run AI agents as part of your team · the pillar this sits under.
- Agent collaboration: a primer · the coordination patterns in depth.
- How humans and AI agents actually work together · where orchestration meets human review.
- Agents are principals, not delegated tokens · the identity model attribution depends on.
