Orchestrating Coding Agents Without Losing Track

GitHub Copilot agent orchestration gets harder the moment Claude Code and Codex join the same repository, and it comes down to five decisions you make once. One person, or one planning session, assigns the work; agents do not pick it themselves. Every agent works on its own branch, in its own checkout or cloud environment, and no two ever share one. Each task has exactly one claim, recorded somewhere every tool can see, not in one tool’s session list. Everything comes back as a pull request into a single review queue that a person clears. And pull requests are merged one at a time, in dependency order, with the rest brought up to date after each merge. GitHub Copilot’s cloud agent, Claude Code and Codex each handle part of this on their own. None of them can see the others’ work, so the joins are yours.

The four ways to run several agents inside Copilot alone are in multi-agent setups with GitHub Copilot, and several Claude Code sessions side by side are in running Claude Code tasks in parallel. This post is about the mixed case: three vendors’ agents on one codebase, and one person keeping track.

Who assigns the work

Each tool has its own front door, and that is the first thing that goes wrong. Copilot’s cloud agent takes work from the Agents panel on GitHub, from an issue assigned to it, or from @copilot in a pull request comment. Claude Code runs in your terminal, and with the Claude Code GitHub Action↗ (opens in a new tab) installed it also answers @claude in an issue or pull request, working on a GitHub runner and pushing commits. Codex cloud↗ (opens in a new tab) takes tasks from its web page, from @codex on GitHub, from Linear, from Slack and from codex cloud in the terminal.

Three tools with six entry points each means work can start from a dozen places, and none of them knows about the others. So pick one place where work is assigned, and treat every other entry point as a way of carrying out an assignment, not making one. A simple routing table in the repository keeps the choice consistent:

• Copilot cloud agent: small, well-specified issues that fit one pull request, such as a bug with a failing test, a dependency bump or a documentation fix.
• Claude Code in a terminal: longer changes you want to watch and steer, refactors that need a plan first, anything that needs local services running.
• Codex cloud: independent tasks you can fire off and review later, several at once, each in its own environment.
• A person: anything touching payments, security, data migrations or a design decision nobody has made yet.

The table is a habit, not a rule the tools enforce. What matters is that the person assigning work uses it, so the same task is never sent to two agents by accident.

Isolation: one branch per agent, always

Each tool isolates its own work, in different ways. GitHub’s page on risks and mitigations for the cloud agent↗ (opens in a new tab) says it can push to a single branch only: the pull request’s branch when you mention it on an existing pull request, otherwise a new copilot/ branch.

Claude Code starts a session in its own checkout with claude --worktree <name>. The Codex view of the ChatGPT desktop app offers worktrees↗ (opens in a new tab) based on a branch you choose, working in a detached HEAD by default until you hand the work back to your local checkout, and Codex cloud gives each task its own environment.

• Never point two agents at the same branch. Mentioning @claude on a pull request Copilot is still working on puts two writers on one branch.
• Name branches after the task. A branch called bu-042-retry can be matched to its task by anyone, whichever agent made it.
• Isolation moves conflicts to merge time; it does not remove them. Two branches that change the same function will still meet. The cheapest fix is upstream: assign tasks that touch different parts of the code.

One claim per task, across every tool

Copilot lists its sessions on GitHub, Claude Code lists its sessions on your machine, Codex lists its tasks in its own app. Each is accurate about itself and blind to the rest. The claim, meaning the record that a task is taken and by whom, has to live somewhere all of them and all of you can read. A shared task list reached over MCP works, because every one of these tools can act as an MCP client. Write the rules once, in the file they all read:

## Work assignment
- Only work on a task you were given by ref (e.g. BUG-042). Never pick your own.
- Before starting: read the task. If it is In Progress with another agent's
  claim comment, stop and say so.
- Claim: move it to In Progress and comment "Claimed by <tool>, branch <name>".
- Branch name starts with the task ref, lower case: bu-042-short-name.
- Finish: open a pull request that names the ref, set how it was tested,
  comment the PR link on the task.
- Cannot finish: comment why, and move it back to Next Up.

The claim comment names the tool because several agents connected through one person’s account can otherwise look alike. How to split a job into claimable tasks, and the failure modes when agents choose for themselves, are in multi-agent workflows.

One review queue

Whatever the tool, the output converges on the same shape: a pull request. That makes the pull request list your review queue, and GitHub builds some of the gate in for Copilot. The same risks page says the cloud agent cannot mark its pull requests ready for review and cannot approve or merge them, the person who asked for the pull request cannot approve it, and by default workflows do not run on its changes until someone with write access presses Approve and run workflows.

The other tools do not add those limits for you, so add them yourself with branch protection: required reviews and required checks on the main branch apply whichever agent opened the pull request. Then keep the queue short.

• Cap open agent pull requests at what you can review in a day. If the queue grows, stop assigning, not reviewing.
• Review oldest first, so nothing rots while newer work jumps ahead and makes it conflict.
• Use a second agent as a first reader, not as the approver. The Codex GitHub integration↗ (opens in a new tab) runs a review when you comment @codex review, which is a cheap second opinion on a pull request Copilot or Claude wrote. A person still approves.
• Read the task’s test notes before the diff. “Tested locally, not against the staging database” tells you where to look.

Merge order

Parallel agents produce pull requests that were each correct against the main branch as it was when they started. Merged carelessly, two correct pull requests make a broken one. Merge them in a deliberate order:

1. Dependencies first. A schema change goes in before the code that uses it; a shared helper before its callers.
2. Then the smallest, most isolated changes, which are least likely to conflict with anything.
3. After each merge, bring the remaining branches up to date and let their checks run again. Ask the agent that owns the branch to do it: @copilot, @claude or @codex on its own pull request.
4. If two pull requests touch the same code, merge one and send the other back to its agent to rework against the result, rather than resolving the conflict by hand in a hurry.

On a busy repository, GitHub’s merge queue↗ (opens in a new tab) automates step three: it tests each pull request against the latest main branch plus the pull requests ahead of it in the queue, so the branch is not broken by incompatible changes.

Keeping track on a fenbs board

fenbs is one place to keep the assignments, claims and results for all three tools. Each task has a ref such as BUG-042, a Problem, a Plan and a Testing status, and sits in one of four lanes: To Do, Next Up, In Progress and Completed. Claude Code, Codex and Copilot in VS Code connect over MCP with a browser sign-in; an agent running on a server, such as a cloud agent, uses a token issued by hand under Settings, with a name, the scopes it needs and an optional expiry, and revoking it ends it. Every change is recorded in History under the assistant’s name and the person it acts for.

• Assigning without racing: a person marks a task with a plan Pre-approved for AI. An idle assistant calls fenbs_next_approved_task and gets the most urgent one in its project, held for it for a few hours, so two assistants never take the same task.
• Giving work back: fenbs_release_task returns the task to Next Up with the reason posted on it.
• Reviewing: a task an assistant finished shows “AI done · check it” until a person presses “I’ve checked it”, which is the review queue for work that never became a pull request.
• What fenbs does not do: it has no review lane, no WIP limits and no sprints, and it says nothing about committing or deploying. “No more than three agent pull requests open” is a rule you write in AGENTS.md, not a setting.