AI agent orchestration for coding is how you get several coding agents to work on one job without stepping on each other. Every setup answers three questions: who splits the work (you, a lead agent or a planner), how the agents share state (results returned to a caller, a shared task list or direct messages) and how their changes come back together (in one context, through a git merge or through a review). Pick those three and you have picked your pattern; the tool comes second.
This post walks through the five orchestration patterns that matter for coding agents, what goes wrong with each, and which tools implement them as of October 2026: Claude Code subagents and agent teams, Codex cloud, Conductor, Claude Squad, Vibe Kanban and AgentVera. AgentVera publishes this blog, so we also say where the others fit better. Third-party details were checked on each tool’s own docs or repository.
If you want a tools roundup instead, read the best tools for parallel AI coding agents. This post is about the architecture underneath them.
The three decisions behind every setup
Before you look at patterns, it helps to name the moving parts:
- Decomposition: who turns “add billing” into tasks. A human splitting by hand is slow but predictable; a planning agent is fast but can split along the wrong lines.
- Shared state: how agent B learns what agent A did. The options, from tightest to loosest, are a return value to the caller, a shared task list with dependencies, and free messages between agents.
- Integration: how the code lands. Read-only work just returns text. Writing agents either share one folder (risky), or work in separate git worktrees whose branches are merged later.
Most orchestration bugs come from one of these being left implicit, for example two agents that both think they own the router file.
Five orchestration patterns
1. Orchestrator and workers
One agent keeps the conversation and sends focused jobs to workers. Each worker gets a fresh context, does one thing and returns a summary. The caller never sees the worker’s full transcript, only its result.
- Good for: research, code search, review, test triage. Anything where the worker reads a lot and reports a little.
- Weak at: parallel writing. Workers usually edit the same checkout as the caller.
- Example: Claude Code subagents.
2. Lead and teammates with a shared task list
A lead agent creates tasks with dependencies; teammates claim tasks, finish them and message each other directly. State lives in the task list, not in one agent’s head, so a teammate can pick up a task that was unblocked a minute ago.
- Good for: work that changes as it goes, where a tester needs to send a bug back to a developer without you relaying it.
- Weak at: cost and file safety. Teammates that share a folder can overwrite each other.
- Example: Claude Code agent teams; AgentVera’s agent messaging and task list.
3. Fan-out in worktrees, then merge
A planner splits one change into independent parts. Each part runs in its own worktree and branch, and the finished branches are merged one by one into an integration branch with the tests run at the end.
- Good for: large changes with separable parts: API, UI, migration.
- Weak at: parts that secretly depend on each other. The conflict shows up at merge time instead of edit time.
- Example: Conductor, Claude Squad and Vibe Kanban give you the worktrees; AgentVera’s parallel team adds the planner and the merge. Background in Git worktrees for parallel agents.
4. Handoffs in a chain
Planner hands to implementer, implementer hands to reviewer. Each step gets the previous step’s output and nothing else. This is the planner-implementer-reviewer setup most people try first.
- Good for: repeatable jobs where you want to read the plan before code is written.
- Weak at: speed. Nothing runs in parallel, and one vague handoff ruins every step after it.
- Example: covered in depth in AI agent workflow pipelines and AI agent teams.
5. Best-of-N
The same task goes to several attempts, and you or a reviewer agent keep the best one. There is no coordination at all, which is exactly the point.
- Good for: hard bugs and fuzzy UI work where the first answer is often not the best.
- Weak at: cost, roughly N times the tokens, and review time.
- Example:
codex cloud exec --attempts, or two different CLIs on the same prompt in separate worktrees.
The patterns side by side
| Pattern | Who splits | Shared state | How code lands | Main risk |
|---|---|---|---|---|
| Orchestrator and workers | The calling agent | Results returned to the caller | Caller’s own checkout | Workers editing the caller’s files |
| Lead and task list | Lead agent | Task list plus messages | Usually one folder | Overwrites, token cost |
| Fan-out and merge | Planner or you | Plan written up front | Branches merged with a check | Late merge conflicts |
| Handoff chain | You, when you design it | The previous step’s output | Last step’s branch | Slow, vague handoffs |
| Best-of-N | Nobody | None | You pick one diff | N times the cost |
What goes wrong, and the fix for each
Conflicts
Two agents in one folder will eventually edit the same file. The fixes stack: a worktree per writing agent, a split by folder rather than by feature, explicit file ownership, and merging one branch at a time onto the latest tip so the second merge sees the first. A merge queue is that last step done properly.
Cost
Every agent re-reads the code it needs, and every message between agents is more tokens. Anthropic’s docs say agent teams use significantly more tokens than a single session and suggest starting with 3 to 5 teammates. Keep the number of agents small, give workers a cheaper model where the docs allow it, and set a cap per agent so a loop can’t burn a day’s budget.
Drift and loops
An agent can drift from the plan, retry the same failing command for twenty minutes, or two agents can keep asking each other the same question. Clear acceptance criteria per task, an explicit “done” or “stuck” signal, message rate limits and a watcher that notices repeated commands catch most of it.
Trust between agents
When agents can message each other, a message from another agent is not a message from you. Treat it as input, not as permission: an agent should not delete a branch or push to main because a peer asked.
The tools, mapped to the patterns
Claude Code subagents (orchestrator and workers)
Subagents are Markdown files with YAML frontmatter in .claude/agents/ (project) or ~/.claude/agents/ (user). Each runs in its own context window and returns its result to the caller; its usage counts toward the same limits. You can restrict a subagent with tools or disallowedTools and pick a model. As of October 2026 subagents can start their own subagents up to three levels deep, controlled by CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (set it to 1 to turn nesting off).
---
name: test-triager
description: Runs the failing tests and reports the root cause. Use after a red CI run.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Run the failing tests, find the first real error and report file, line and cause in under 15 lines. Do not edit files.
Claude Code agent teams (lead and task list)
Agent teams are experimental and off by default as of October 2026. One session is the lead; each teammate is its own Claude Code instance with its own context. Teammates share a task list with pending, in-progress and completed states plus dependencies, claim tasks themselves and message each other directly. Turn it on in settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Teammates show in-process by default or in split panes with tmux or iTerm2. The docs list real limits: no session resumption for in-process teammates, task status can lag, one team per session, no nested teams and a fixed lead. They also warn that two teammates editing the same file leads to overwrites, so split the work by file. The TeammateIdle, TaskCreated and TaskCompleted hooks let you enforce rules; exit code 2 blocks the action.
Codex cloud (fan-out and best-of-N, remote)
Codex cloud runs tasks in a cloud environment you set up, each in its own workspace, and keeps going while your laptop sleeps. You review the diff, ask for follow-ups, then open a PR or apply it locally. The codex cloud command is marked experimental as of October 2026:
codex cloud exec --env ENV_ID --attempts 3 "Fix the flaky date test in billing/"
codex cloud list --env ENV_ID
codex apply TASK_ID # applies the diff locally; exits non-zero if git apply fails
--attempts takes 1 to 4 and is the simplest best-of-N you can get. Codex cloud is the better pick when you want work off your machine; it runs Codex only.
Conductor (fan-out, Mac)
Conductor runs Claude Code, Codex, Cursor and OpenCode in parallel, each task in its own workspace with its own branch, terminal and diff, then review, PR, merge and archive. It is Mac-only. Plans as of October 2026: Free, Pro at $50 a month and Teams at $60 per user a month. If your whole team is on macOS and you want a polished fan-out UI, it is a strong choice.
Claude Squad (fan-out, terminal)
Claude Squad is a terminal UI that runs Claude Code, Codex, Gemini, Aider, OpenCode or Amp in separate worktrees inside tmux. It is AGPL-3.0 and needs tmux and the GitHub CLI; on Windows it runs in WSL.
brew install claude-squad
cs # Claude Code by default
cs -p "codex" # another agent
n starts a session, Enter attaches, Ctrl-q detaches and s commits and pushes. It is the lightest option if you live in the terminal.
Vibe Kanban (fan-out, board)
Vibe Kanban turns tasks into cards, and each card gets a workspace with its own branch, terminal and dev server; diff comments go back to the agent and it can open PRs. It supports Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode, Droid, CCR and Qwen Code. Its README now says the project is sunsetting, so as of October 2026 treat it as community-maintained (Apache-2.0, npx vibe-kanban).
AgentVera (all five, local)
AgentVera is a desktop app for macOS, Windows and Linux that runs many coding CLIs side by side, so it can host each pattern instead of one:
- Orchestrator and workers: with agents that open agents (on by default), an agent starts helpers through the
spawn_agent,wait_agent,agent_status,message_agentandstop_agenttools. A helper can be any installed CLI, can work in its own worktree on anoto/…branch, and appears under its parent. By default each agent can open 3 helpers and 6 can run in total; helpers can’t open agents of their own. - Lead and task list: agent messaging gives every agent
send_message,reply_message,wait_replyand a shared task list (task_addwith an assignee and dependencies,task_claim,task_done,task_release). When a task’s dependencies are done it becomes ready and its assignee is told. It works across CLIs, so Claude Code can hand a task to Codex. - Fan-out and merge: a parallel team (Pro and Team plans) splits a job into up to 8 parts, each with acceptance criteria and expected files, runs them in their own worktrees, 3 at once by default and at most 6, and merges them into an integration branch. The project test command is the check; an integration agent fixes conflicts and failures, and the team stops if the check is still red after two fix rounds.
- Guards for the failure modes: file ownership refuses Claude Code edits outside an owner’s paths through a hook; the merge queue merges one branch at a time onto the latest tip; token budgets (off by default) cap an agent per turn and per day; and the supervisor flags an agent that repeats the same command 5 times in 15 minutes, hits the same error 3 turns in a row or goes 20 minutes without a file change.
It is local only for these features: agent-opened helpers and messaging don’t cover SSH agents. If you want tasks to keep running in the cloud while your laptop is closed, Codex cloud is the better fit.
How to choose a pattern
- Is the work read-heavy? Use orchestrator and workers. Subagents are enough.
- Do several agents need to write code at once? Use fan-out in worktrees with a merge step. Don’t let them share a folder.
- Do the tasks change as you learn? Use a lead with a shared task list, and keep it to 3 to 5 agents.
- Do you run the same job every week? Use a handoff chain with an approval before the code step.
- Is the problem hard and the answer uncertain? Use best-of-N, and pay for it knowingly.
Then pick the tool by platform: Conductor only on a Mac, Claude Squad if you want a terminal, Codex cloud if the work should run remotely, AgentVera if you want several CLIs and patterns in one desktop app on any OS.
A small orchestration you can try today
The smallest useful fan-out needs nothing but git and two CLIs:
git worktree add ../app-api -b feat/api
git worktree add ../app-ui -b feat/ui
(cd ../app-api && claude "Add the /invoices endpoint. Touch only src/api/.")
(cd ../app-ui && codex "Build the invoices page against the /invoices contract. Touch only src/ui/.")
git checkout -b integrate/invoices
git merge feat/api && npm test
git merge feat/ui && npm test
The rules that make it work are in the prompts: one folder per agent, an agreed contract between them and a test run after each merge. Everything a tool adds on top (planning, task lists, a supervisor, a queue) automates one of those lines. Parallel coding agents goes further on running Claude Code and Codex side by side.
Wrapping up
AI agent orchestration for coding is less about the tool than about three choices: who splits the work, where shared state lives and how the code lands. Orchestrator and workers suits reading, a task list suits changing work, fan-out with a merge suits big separable changes, handoff chains suit repeatable jobs and best-of-N suits hard ones. Whatever you pick, put guards on conflicts, cost and drift from day one.
If you want to try several patterns in one place, download AgentVera and start with two agents and a shared task list before you turn on a parallel team.