Multi-Agent Workflows: Coordinating Several AI Agents on One Board

A multi-agent workflow is one job split across several AI agents: one plans and hands out work, or each does one stage and passes it on, or several work side by side on separate pieces. Whichever shape you pick, the hard part is not the agents; it is the coordination. Agents that cannot see each other will pick up the same piece, edit the same file, and finish work nobody hears about. The fix that works across every tool is a shared list of tasks outside any one agent: each piece of work is a task, an agent claims a task by moving it to In Progress before it starts, a task has one owner at a time, and the result is written on the task when it stops.

Start with one agent

More agents is not automatically better. Anthropic’s guide to building effective agents↗ (opens in a new tab) recommends finding the simplest solution possible and adding complexity only when it demonstrably improves outcomes. A single agent working through a list of tasks in order is a workflow too, and it has none of the problems below.

Reach for several agents when the work genuinely splits: pieces that do not depend on each other, a stage that needs a different set of tools or instructions, or more material than one context window can hold. If every piece waits on the one before it, a second agent mostly waits.

Three patterns

Orchestrator and workers

One agent breaks the job down, hands each piece to a worker, and puts the results together. The workers never talk to each other; they talk to the orchestrator. This is the right shape when you cannot know the pieces in advance — a bug hunt, a research question, a review across an unfamiliar codebase — because the orchestrator decides the split after it has looked.

Pipeline

Each agent does one stage and passes its output to the next: one writes the change, one writes the tests, one reviews both. The order is fixed and known in advance. A pipeline is easy to reason about, and its weak point is the join between stages: whatever the first agent knew and did not write down is gone by the time the second one starts.

Parallel independent tasks

Several agents each take a separate, self-contained task and work at the same time: three bugs in three different modules, a translation per language, a check per page. Nobody hands anything to anybody. This is the simplest pattern to run and the easiest to get wrong, because the only thing keeping two agents apart is that they chose different tasks.

What goes wrong

The failures are the same whichever tools you use, and they are coordination failures, not intelligence failures.

• Duplicate work. Two agents read the same list, reach the same conclusion and start the same task. Describing its own multi-agent research system↗ (opens in a new tab), Anthropic reports that without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.
• Conflicting edits. Two agents change the same file, and one overwrites the other, or both succeed and the result makes sense to neither. Separate checkouts such as git worktrees↗ (opens in a new tab) stop agents writing over each other’s files, but two branches that change the same function still meet at merge time.
• Lost hand-offs. A worker finishes, and its result lives only in its own transcript or in the orchestrator’s context. The orchestrator compacts, the session ends, or a person asks what happened on Tuesday, and nobody can say.
• Silent abandonment. An agent stops half way — an error, a limit, a closed terminal — and the work looks taken for ever, because nothing records that it stopped.

All four have the same root: each agent’s picture of the work is private. The cure is a picture they share.

Coordinate through shared tasks

Put the work on a list every agent can read and write, outside any one of them. A task board over MCP↗ (opens in a new tab) works well, because any agent that speaks the protocol can reach it, whichever tool it runs in. Then give every agent the same short set of rules.

1. One task per piece of work. If it is not on the list, add it before starting it. The orchestrator’s first job is writing the tasks, not doing them.
2. Claim before you start. Moving a task to In Progress is the claim, and a comment saying which agent took it and what it is about to do makes the claim readable.
3. One owner per task. Never work on a task someone else has claimed. If two pieces of work need the same file, they are one task, or two tasks done one after the other.
4. Record the result on the task. What changed, where (the commit, the file, the document), how it was checked, and what was not done. The next agent reads that, not a transcript.
5. Hand off with a new task. A pipeline stage finishes by filing the next stage’s task, linked to its own, with what the next agent needs in the note.
6. Stop cleanly. An agent that cannot finish says why in a comment and puts the task back where the next agent will look for it.

## Working with other agents
- Before starting, list In Progress. Anything there is taken; leave it alone.
- Take one task from Next Up. Move it to In Progress, then comment:
  "Claimed by <agent name>. Plan: ..."
- Read the task back. If another claim comment is ahead of yours, pick again.
- Finished: comment what changed, where, and how you checked it;
  move it to Completed.
- Next stage needed: file it as a new task linked to this one.
- Stopping early: comment where you got to and move it back to Next Up.

The rules map on to each pattern. An orchestrator writes the tasks and reads the results off them instead of holding every worker’s answer in its own context. A pipeline becomes a chain of linked tasks, each stage filing the next. Parallel agents each take a different task, and the claim keeps them apart. How to split the work into tasks an agent can actually finish is its own subject: see AI agent task decomposition.

Some tools build a version of this in. Claude Code’s experimental agent teams↗ (opens in a new tab), for example, give a lead and its teammates a shared task list with file-locked claims. A list inside one tool only coordinates the agents in that tool, though; a colleague’s session or an agent running in a different product cannot see it.

Doing it on a fenbs board

On fenbs the list is a board with four lanes — To Do, Next Up, In Progress, Completed — and each agent connects over MCP as an AI assistant with its own connection, scoped to read, write and comment. A few things line up with the rules above:

• Duplicates are held back. When an agent calls fenbs_create_item and an open task, or one finished in the last 14 days, looks like the same thing, nothing is filed: it gets created: false and the likely matches, so it can comment on the existing task instead.
• Every change is attributed. The history records each move and comment as “<assistant> via <person>”, so you can tell an agent’s work from a person’s. Several agents connected through one person’s account read the same, which is why the claim comment names the agent.
• Hand-offs link. relatesTo links a task to the one it came from, both ways, and each task keeps its problem (the note) apart from how it will be done (the plan).
• Pre-approved tasks are held. A person can mark a task with a plan “Let AI do this”; an idle assistant calls fenbs_next_approved_task and the task is held for it for a few hours, so two never take the same one. fenbs_release_task gives it back with a reason.

An ordinary move to In Progress is not a lock: two agents moving the same task in the same moment both succeed, and the history shows both. That is why the rules say to read the task back after claiming it. fenbs has no WIP limit setting and no sprints either, so “one task per agent” is a rule you write, not a switch you turn on.

How many agents

Fewer than you think. In the same research write-up, Anthropic reports that its multi-agent systems used about fifteen times more tokens than chat interactions, and notes that most coding tasks involve fewer truly parallel pieces than research does. Every extra agent also adds results someone has to check. Start with two, and add a third only when the list of tasks in Next Up is growing faster than they can clear it — and the review of Completed is keeping up.