How to coordinate multiple AI coding agents.

What goes wrong when several agents share one repo?

Running several coding agents at once fails in four predictable ways, and each has its own fix. Worktrees fix file collisions. A shared board fixes double work and lost context. A review column, plus a person who uses it, fixes unreviewed changes.

Problem	What it looks like	Fix
File collisions	Two agents edit the same checkout; one resets or switches branch and the other's work vanishes	One git worktree and branch per agent
Double work	Two agents pick the same task because neither knows the other took it	One shared list of tasks, and a claim rule
Lost context	A session ends and the next one starts from zero	Progress written on the task, not only in the chat
Unreviewed changes	An agent decides its own work is finished	A review column that agents are told never to move cards out of

Anthropic's documentation states the first problem plainly: "Two teammates editing the same file leads to overwrites" (Claude Code agent teams docs, as of October 2026).

How do you give each agent its own worktree?

A git worktree is an extra working directory attached to the same repository. In the words of the git documentation, a repository "can support multiple working trees, allowing you to check out more than one branch at a time." Each worktree has its own HEAD and index but shares the repository's history and branches, so it is lighter than a second clone. Git also refuses to check out a branch that is already checked out in another worktree (unless you force it), which keeps two agents off the same branch.

Create one worktree per agent, each on its own branch:

git worktree add ../shop-api -b agent/api
git worktree add ../shop-web -b agent/web
git worktree add ../shop-tests -b agent/tests
git worktree list
# when a branch is merged:
git worktree remove ../shop-api

Then start one agent in each directory. Most agent tools can also create worktrees for you:

• Claude Code: claude --worktree feature-auth creates a worktree under .claude/worktrees/feature-auth/ on a new branch named worktree-feature-auth. A .worktreeinclude file lists gitignored files, such as .env, to copy into each new worktree (Claude Code worktree docs).
• Codex: the Codex app creates worktrees in $CODEX_HOME/worktrees and, by default, works in a detached HEAD rather than on a branch (OpenAI worktree docs).
• Cursor: "Worktrees let Agent work in isolated Git checkouts", and you can customize their setup with .cursor/worktrees.json (Cursor worktree docs).

All three were checked in October 2026, and they change often. A new worktree is a fresh checkout, so install dependencies and copy local config into it before the agent starts. Worktrees isolate files, not services: two agents on the same dev server port or test database can still get in each other's way.

Worktrees do not prevent merge conflicts later. Split work by area (API, web, tests), not into overlapping changes to the same files.

How do agents in different tools share one task list?

Worktrees say where each agent works, not what it works on. Claude Code has two built-in answers, and both stay inside Claude Code:

• Subagents work within a single session and return their results to the main agent.
• Agent teams are separate Claude Code sessions led by one session (agent teams docs). Teammates share a task list with three states (pending, in progress and completed), and, in the docs' words, "Task claiming uses file locking to prevent race conditions when multiple teammates try to claim the same task simultaneously." As of October 2026 agent teams are experimental and off by default, and you enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. The task list lives on your machine under ~/.claude/tasks/, and a session has exactly one team: "You can't create additional named teams or share a team across sessions."

So agent teams suit one person splitting a job inside one Claude Code session. They are not a shared list for a Codex agent in another terminal, a Cursor agent on a teammate's laptop, or tomorrow's session (the task list file stays on disk, but each session gets its own team). For that, the list has to live where every agent and every person can reach it.

A shared board does that job. Flux, task management for AI agent teams, is a hosted kanban board that agents use through the Flux MCP server or the REST API, and that people open in a browser. Give each agent its own named API key, so you can revoke one without disconnecting the others. Then add the server to each client:

Claude Code (one command, with that agent's key):

claude mcp add --transport http flux https://flux.umin.ai/api/mcp \
  --header "Authorization: Bearer flux_YOUR_API_KEY"

Codex (in ~/.codex/config.toml; Codex reads the key from the environment variable you name, per OpenAI's MCP docs):

[mcp_servers.flux]
url = "https://flux.umin.ai/api/mcp"
bearer_token_env_var = "FLUX_API_KEY"

Codex reads the key from the environment, so you can export a different FLUX_API_KEY in each terminal and give every Codex agent its own key. For Cursor, see the Cursor setup, and for Claude Desktop and claude.ai, the Claude setup.

Once connected, an agent can read the board, create and update cards, move them, add columns and post comments. For handoffs, use get_card. It returns a card's description and every comment, so a new session can read what the last one did and carry on.

How do you stop two agents taking the same card?

Flux does not lock cards, and it has no atomic "claim" operation: an agent whose key has the Write scope can move any card in a workspace where the key's owner is at least a member. So claiming is a convention you write into each agent's instructions. Two conventions work well together.

Give each agent its own lane. Instead of one Ready column, make one per agent: Ready - api, Ready - web, Ready - tests. A person, or a planning session, puts each card in the right lane, and each agent only pulls from its own. This is the most reliable option because it removes the race instead of managing it.

Claim before you start. When an agent pulls from a shared column, it moves the card to In Progress and posts a claim comment before writing any code, then reads the card again. Comments come back oldest first, so if another agent's claim is older, the newer agent backs off and picks something else. This narrows the window for double work but does not close it, which is why lanes come first.

Comments an agent posts appear under the name of the person who created its API key, and cards it creates record that person as their creator. Ask every agent to start its comments with its own name, so the board shows which agent did what.

Codex, Cursor and many other agents read instructions from an AGENTS.md file; Claude Code reads CLAUDE.md. Every worktree sees the same copy of these files, so put the shared rules in both and give each agent its name and lane in the prompt you start it with. For example:

## Working with the Flux board
- Your agent name and lane come from your start prompt, for example
  "codex-tests" and "Ready - tests". Start every comment with [your agent name].
- Only take cards from your lane column.
- Before you write code: move the card to In Progress, then comment
  "[your agent name] claimed. Branch <your branch>, worktree <your worktree>."
- Read the card again. If an older claim comment exists, stop and pick another card.
- When done: comment what you changed, how to check it, and the PR link.
  Move the card to Needs review. Never move a card to Done.

Where does the human review happen?

In a column. Agents move finished cards as far as Needs review. A person reads the agent's comments and the pull request from its branch, then moves the card to Done or sends it back with a comment. Because each agent works on its own branch, review maps cleanly onto pull requests: one card, one branch, one PR.

Flux does not stop a read and write key from moving a card to Done. The review step is a rule in the agent's instructions, and people keep it honest by checking Done. For an agent that only reports, such as one that writes a daily summary of the board, use a key with only the Read scope. The kanban board for AI agents guide covers this review layout in more depth.

An example layout: three agents, one board

Here is a starting layout for one repository with an API, a web app and a test suite. It is a suggestion, not a measured result; match the lanes to how your code splits.

Agent	Client	Worktree and branch	Flux key	Pulls from
claude-api	Claude Code	../shop-api, agent/api	"Claude Code - api", Read and Write	Ready - api
cursor-web	Cursor	../shop-web, agent/web	"Cursor - web", Read and Write	Ready - web
codex-tests	Codex	../shop-tests, agent/tests	"Codex - tests", Read and Write	Ready - tests
summary	Any MCP client	None, it only reads	"Daily summary", Read only	The whole board

The board has seven columns: Backlog, Ready - api, Ready - web, Ready - tests, In Progress, Needs review and Done. An agent with write access can add the lane columns itself with create_column. New columns are added at the end of the board, so drag them into place in the app. This fits on the Free plan, which includes one workspace with one board and no cap on members, and agents connected by API or MCP never take a seat. See pricing for the paid plans.

How many agents should you run at once?

Fewer than you think. Anthropic's guidance for agent teams is to start with 3 to 5 teammates for most workflows, because token cost and coordination grow with every agent. Your review capacity is usually the real limit. If cards pile up in Needs review, another agent only makes the pile taller. Start with two or three agents on separate areas of the code, and add more once the review column stays short.

What Flux does not do

• It does not run, start or schedule agents, and it does not create worktrees. You do that with git or your agent tool.
• It does not lock cards or make claims atomic. Use lanes and claim comments.
• It has no MCP tools for deleting cards, assigning people or adding labels. The REST API covers more of the product.
• Changes made over MCP are not recorded in the activity log yet. Changes made in the app and through the REST API are.

What Flux does is give every agent, in every tool, and every person on your team the same list of work: what is waiting, who took what, what each agent did, and what still needs a human.