Two agents, one board, zero collisions

Two agents working the same repository sounds like a merge conflict waiting to happen. It is — unless the board decides who works on what, atomically, before either of them starts typing.

The failure mode is familiar. You point one agent at the auth form and another at the billing page. Both grep the codebase, both pick the same shared component to "fix first", and both open a review for the same file. The second review is pure rework: rebase, re-resolve, re-explain. Parallelism bought you nothing.

One command hands out the work

The fix is a claiming discipline, not a bigger model. An agent that wants work runs one command:

npx @vibeflow-tools/cli tasks --next

That command claims the highest-priority todo task and prints it with its children. The claim is atomic: the task flips to in-progress in the same write that hands it out, so when the second agent runs the same command a second later, it receives the next available task instead of the same one. Two agents never take the same task, no matter how close together they ask.

The same operation exists for agents that speak Model Context Protocol rather than the command line — the MCP endpoint exposes it as a claim_next_task tool, with the same atomicity and the same review gates on the other side.

The board both agents see

Claiming only works if there is something worth claiming. Tasks on the board are sequenced roots with children: a root like "billing page overhaul" splits into claimable units, and each agent takes one child-sized piece. The human view is the local kanban board — start it with one command and watch both agents move their cards across it in real time.

Because tasks live as plain JSON files inside the repository, the two agents coordinate through the same mechanism your team already uses for code: the working tree. A claim is a file change. A review submission is a file change. Nothing travels through a side channel that the other agent cannot see.

Unverified work never lands

Handing out distinct tasks solves the collision. It does not solve quality — an agent can finish the wrong task quickly and submit it with confidence. That is what the review gate is for.

Nothing moves to review without the agent's own verification verdict: correct, not correct, or honestly unverifiable here. The gate refuses an unverified change the same way a type checker refuses a bad program — not with advice, with a closed door. When you look at the board, every card sitting in review carries its author's attestation of what was actually checked.

Try it with two terminals

The whole setup is one board, two terminals, and the same line pasted into both agents: get next tasks and implement them. The first agent claims the top root; the second gets the next one. Neither knows the other exists, and neither needs to.

If you are coming from prose-based delegation — a chat message per agent, a prayer that they divide the work sensibly — the difference is immediate. The board is the plan, the claim is the handshake, and the review gate is the definition of done. Read the tasks command reference for every flag, the kanban command for the human view, and the MCP setup guide if your agents connect over the protocol. The tutorial walks through all three steps in ten minutes.

• All posts — the blog index, newest first
• How to use Vibeflow — the three-step workflow in ten minutes
• vibeflow tasks — every flag of the claiming command