Multi-Agent Setups With GitHub Copilot: What You Can Run Today

Multi-agent work with GitHub Copilot happens at four levels. Inside one chat, an agent can hand pieces of a task to subagents, including your own custom agents, each with its own context. Across a sequence, custom agents with handoffs pass the work from one role to the next, such as plan, then implement, then review. Across sessions, VS Code runs several agents side by side, on your machine or in the cloud, with Copilot, Claude or Codex doing the work. And on GitHub, you can assign issues to Copilot’s cloud agent or to Claude and Codex, several at a time, and follow them all from one page. The Copilot CLI adds /fleet, which splits a plan across parallel subagents. The features differ; the thing that keeps them all from colliding is the same: one piece of work per agent, and a shared record of who has what.

What custom agents and skills are, individually, is in GitHub Copilot agents vs skills, and how the cloud agent turns an issue into a pull request is in the GitHub Copilot coding agent. This post is about running several at once.

Level one: subagents inside a chat

A subagent is a separate agent the main one calls for a focused job. VS Code’s page on subagents↗ (opens in a new tab) says a local subagent does not inherit the main conversation’s history, so the task it is given must be self-contained, and only its result comes back into the main chat. The main agent delegates through the Run Subagent tool (agent/runSubagent), either because you asked in plain words or because it decided to. Subagents calling further subagents is off by default; the chat.subagents.allowInvocationsFromSubagents setting turns it on, up to five levels deep.

Any custom agent can be a subagent, which is where it gets useful. A coordinator agent can name the specialists it may call:

---
description: "Splits a change into research, implementation and review"
tools: ['agent', 'search/codebase', 'edit']
agents: ['researcher', 'reviewer']
---
First send the researcher the question, with the files to look at and the
shape of answer you want. Implement from its answer. Then send the diff to
the reviewer and fix what it reports. Summarise both results for me.

The agent tool must be in the list for delegation to work, and agents limits which custom agents it may call: * for all, an empty list for none. On the specialists, user-invocable: false keeps them out of the agent picker so they are used only as subagents, and disable-model-invocation: true does the opposite, stopping other agents from calling them.

Level two: custom agents that hand off

A handoff is a button, not a delegation. VS Code’s custom agents documentation↗ (opens in a new tab) describes handoffs in an agent’s frontmatter: each has a label, a target agent, a prompt, an optional model, and send, which submits the prompt automatically when true. After a response, the buttons appear; selecting one switches to the next agent with the prompt filled in.

---
description: "Plans a change. Never edits files."
tools: ['search/codebase', 'search/usages', 'fenbs/*']
handoffs:
  - label: Implement the plan
    agent: implementer
    prompt: Implement the plan above. Stop and ask if it is unclear.
  - label: Ask for a review of the plan
    agent: reviewer
    prompt: Review the plan above for risks and missing tests.
---
Read the task with fenbs_get_item. Write a numbered plan with the files to
change and the tests to add, and save it to the task's plan.

Handoffs suit a fixed sequence where a person checks each step. Subagents suit work the agent should split up by itself. You can combine them: a planner that hands off to an implementer that calls a reviewer as a subagent.

Level three: several sessions side by side in VS Code

VS Code treats each chat as a session, and sessions are independent: they can run in parallel and appear together in the Chat view and the Agents window. What runs a session is a harness. The agent harnesses page↗ (opens in a new tab) lists Local, running in the editor; Copilot, running in the Agent Host on your machine, a remote host or a Dev Container; Claude, using Anthropic’s Claude Agent SDK; Codex; and Cloud, which runs a provider’s harness on remote infrastructure against a GitHub repository.

• Isolate the files, not only the context. A session can work in a New Worktree, a separate Git checkout, so two agents editing at once do not overwrite each other; you then merge the result. Folder mode applies edits straight to your workspace.
• Hand a session on. The Session Target dropdown moves a session to another harness or environment, and VS Code carries the conversation and context across, though tools, permissions and models may change.
• Keep the count small. Each running session is another stream of changes you have to review.

Level four: a fleet of agents on GitHub

On GitHub, the cloud agent works on an issue or a prompt in its own environment and answers with a pull request. Several can run at once, and GitHub’s page on agent management↗ (opens in a new tab) describes where you follow them: the Agents tab in a repository and the Agents page across repositories. You can open a session’s log to watch its reasoning, steer it mid-run with more input, or continue it in VS Code or the Copilot CLI.

The agent does not have to be Copilot. GitHub’s page on third-party coding agents↗ (opens in a new tab) lists Anthropic Claude and OpenAI Codex, in public preview and switched on through policy. You start them the same ways, from the Agents tab, by assigning an issue, or by mentioning them in a pull request comment. GitHub’s announcement of Claude and Codex on Agent HQ also describes assigning several agents to the same task to compare how each approaches it, which is a cheap way to get options on a design question before anyone writes the real change.

The cloud agent’s limits shape how you split the work: one repository per task, one branch and one pull request per task, and a hard limit of 59 minutes per session. Split anything bigger into several issues and give each its own agent.

In the terminal: /fleet

The Copilot CLI has its own version. /fleet, or --fleet on the command line, has the main agent break a plan into independent subtasks, act as orchestrator, and run them in parallel through subagents, choosing a custom agent for a subtask when one fits. GitHub notes that the extra subagents mean more model calls, so it is worth it only when the work genuinely splits.

Keeping several agents from colliding

The features differ; the failure is the same. GitHub’s own guide to orchestrating agents with mission control↗ (opens in a new tab) warns that agents working in parallel can create merge conflicts if they touch the same files, and recommends keeping tasks with dependencies sequential while research, documentation, reviews and work in separate modules run in parallel.

• One task, one agent. Before assigning, check nothing else is working on the same files.
• Parallel for independent pieces, sequential for dependent ones. A migration and the code that uses it are one agent’s job, or two in order.
• Give each agent a brief that stands alone: the goal, the files, what not to touch, how to check it. Neither a subagent nor a cloud agent sees your chat.
• Read the session logs early. A wrong turn caught in the first few minutes is cheaper than a pull request you reject.

One record across all four levels

Each level keeps its own record: subagent results in one chat, sessions in one editor, cloud sessions on GitHub, third-party sessions beside them. None of them shows the whole piece of work, and none reaches a colleague using a different tool. A board every agent can reach over MCP can. On fenbs, each piece of work is a task with a problem, a plan and a testing status, in lanes To Do, Next Up, In Progress and Completed. Connect Copilot in VS Code to it, allow the fenbs tools in the agents that need them, and have each agent move its task to In Progress with a comment naming itself before it starts. Every change is recorded with the assistant’s name and yours. The cloud agent connects differently, with a token as a header, which the coding agent post sets out; the claim-and-report rules themselves are in multi-agent workflows.