GH-600 · Domain 5: Orchestrate multi-agent coordination · 18% of the exam
Task 5.1: Operate and manage multi-agent workflows
Orchestration patterns for several agents, isolating agents that run in parallel, and resolving overlapping changes, duplicated work and contradictory results.
Study it
Orchestration patterns: orchestrator and subagents, /fleet, dynamic workflows
Isolating parallel agents and resolving overlapping or contradictory work
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 2
A team is deciding which of its backlog items to run with fleet mode, where a parent agent dispatches parallel sub-agents. Which items does GitHub's guidance say are poor fits? (Choose TWO.)
ARefreshing documentation where each worker owns one page
BReviewing a large set of diffs, one module per worker
CA migration where step two needs the concrete output of step one
DResearching the same question across five independent services
EA change in which every worker would need to edit the same three core files
Show the answer and why
ARefreshing documentation where each worker owns one page
Incorrect
Documentation refreshes with one owner per page are listed as good fits.
BReviewing a large set of diffs, one module per worker
Incorrect
Batch reviews with a separate module per worker are listed as good fits.
CA migration where step two needs the concrete output of step one
Correct
Sequential tasks where a step needs the previous step's output are listed as poor fits.
DResearching the same question across five independent services
Incorrect
Parallel research across independent services is a good fit.
EA change in which every worker would need to edit the same three core files
Correct
Tightly coupled edits where workers contend for the same files are listed as poor fits.
Fleet mode suits work that can be decomposed before execution, with each unit able to run without waiting for others: multi-file refactors with one owner per file or package, batch reviews, parallel research across independent services, documentation refreshes and migrations where each worker validates its own slice. Avoid it for sequential tasks, tightly coupled edits on the same files, small tasks and work that needs continuous shared reasoning.
A security team needs the same review process every time: collect the changed files, have an agent assess each one, and open an issue only for findings above a set severity. They want the steps and conditions fixed rather than chosen afresh by Copilot. Which orchestration approach fits?
AThe /fleet command, which repeats the same split of work every run
BAutopilot mode, which keeps a fixed sequence of steps across runs
CA custom agent whose prompt lists the steps in order for the main session to follow
DA dynamic workflow, whose author defines the steps, conditions and handoffs in code
Show the answer and why
AThe /fleet command, which repeats the same split of work every run
Incorrect
With /fleet, Copilot decides how to divide and coordinate the work each time.
BAutopilot mode, which keeps a fixed sequence of steps across runs
Incorrect
Autopilot is about autonomy: Copilot decides the next steps itself.
CA custom agent whose prompt lists the steps in order for the main session to follow
Incorrect
A prompt guides one agent's behavior; it doesn't fix the stages and conditions the way code does.
DA dynamic workflow, whose author defines the steps, conditions and handoffs in code
Correct
In a dynamic workflow the process is defined in code by its author, and agents handle the parts that need judgment.
Autopilot lets Copilot keep working without pausing for input, with Copilot deciding the next steps. /fleet encourages Copilot to delegate to subagents in parallel, deciding how to break the task down each time. A dynamic workflow carries out a process defined in code: its author defines the steps, conditions and handoffs, and agents handle the parts that need analysis or judgment.
In VS Code, a developer designs a workflow in which the main agent hands research to a subagent, and that subagent is supposed to start two more subagents of its own for deeper dives. What does GitHub document about this design?
AIt works, as long as each subagent uses a different model from the main session
BIt won't work as planned, because subagents can't create other subagents
CIt works, but each nested subagent pauses for the developer's feedback
DIt works only in Visual Studio, where nested subagents are supported
Show the answer and why
AIt works, as long as each subagent uses a different model from the main session
Incorrect
Subagents use the same model as the main session, and they can't create subagents.
BIt won't work as planned, because subagents can't create other subagents
Correct
Subagents use the same tools and model as the main session but cannot create other subagents.
CIt works, but each nested subagent pauses for the developer's feedback
Incorrect
Subagents operate without pausing for user feedback, and nesting isn't supported.
DIt works only in Visual Studio, where nested subagents are supported
Incorrect
Subagents aren't currently available in Visual Studio.
In your IDE you can delegate a self-contained subtask to a subagent with its own context window. It works independently without pausing for user feedback and returns its result to the main session. Subagents use the same tools and AI model as the main session, but they cannot create other subagents. They are available in VS Code, JetBrains IDEs, Xcode and Eclipse, not Visual Studio.
In a multi-agent workflow in Copilot CLI, which agent usually keeps track of the overall goal?
AThe last subagent to finish
BThe main agent, acting as orchestrator for its subagents
CThe rubber duck agent
DEach subagent, equally
Show the answer and why
AThe last subagent to finish
Incorrect
Subagents focus on their tasks; the orchestrator tracks the goal.
BThe main agent, acting as orchestrator for its subagents
Correct
The orchestrator is usually the main agent that delegates work to subagents.
CThe rubber duck agent
Incorrect
The rubber duck critiques work; it doesn't orchestrate.
DEach subagent, equally
Incorrect
One orchestrator keeps track of the overall goal.
Multi-agent work typically has an orchestrator, usually the main agent, that keeps track of the overall goal. It breaks the goal into tasks, identifies dependencies, assigns each task to a subagent with the context and tools it needs, runs independent tasks in parallel, and reviews and combines the results.
Why might a task run with /fleet consume more AI credits than the same task done by the main agent alone?
AEach subagent calls the model independently, adding interactions
B/fleet always switches every subagent to the most expensive available model
C/fleet bills Actions minutes as credits
DSubagents re-read the whole repository first
Show the answer and why
AEach subagent calls the model independently, adding interactions
Correct
Splitting work across subagents can mean more LLM interactions than the main agent alone.
B/fleet always switches every subagent to the most expensive available model
Incorrect
The extra use comes from more model interactions, not a forced model.
C/fleet bills Actions minutes as credits
Incorrect
The extra use comes from model interactions.
DSubagents re-read the whole repository first
Incorrect
The documented reason is independent model interactions per subagent.
Using /fleet can finish independent work faster, keep each agent's context focused and let you assign specialized agents. Because each agent interacts with a model independently, it may also mean more LLM interactions, and therefore more AI credits, than the main agent handling the work alone. Inherently sequential requests gain little.
How can a script start Copilot CLI in fleet mode for a task without opening an interactive session?
Acopilot --acp --fleet "TASK"
Bcopilot /fleet "TASK"
Ccopilot --fleet -p "TASK"
Dcopilot --cloud -p "TASK"
Show the answer and why
Acopilot --acp --fleet "TASK"
Incorrect
--fleet isn't supported in ACP server mode.
Bcopilot /fleet "TASK"
Incorrect
/fleet is a slash command inside a session; --fleet is the option.
Ccopilot --fleet -p "TASK"
Correct
--fleet wraps the prompt in fleet mode, and -p runs it non-interactively.
Dcopilot --cloud -p "TASK"
Incorrect
Cloud sandboxes can't be combined with -p, and --cloud isn't fleet mode.
The --fleet option is the command-line equivalent of /fleet. Supply the prompt with -i for an interactive session that starts in fleet mode, with -p to run a task without one, or through standard input. It is especially useful for automation; it isn't supported with --acp.
When does Copilot's chat agent start a dynamic workflow?
AWhenever a task has more than three steps
BAutomatically for every prompt in Autopilot
CWhenever an extension that defines dynamic workflows is loaded into the session
DOnly when you ask explicitly, or a skill or slash command tells it to
Show the answer and why
AWhenever a task has more than three steps
Incorrect
There is no step threshold; an explicit request is needed.
BAutomatically for every prompt in Autopilot
Incorrect
Autopilot doesn't start dynamic workflows by itself; an explicit request is needed.
CWhenever an extension that defines dynamic workflows is loaded into the session
Incorrect
Loading makes workflows available; running one still needs a request.
DOnly when you ask explicitly, or a skill or slash command tells it to
Correct
The chat agent only creates or runs a dynamic workflow on an explicit request or instruction.
Dynamic workflows are defined in Copilot extensions and run on request; you can ask Copilot to run one by name in natural language. Your chat agent only creates or runs a dynamic workflow when you explicitly ask it to, or when a skill or slash command instructs it to.