GH-600 · Domain 5: Orchestrate multi-agent coordination · 18% of the exam
Task 5.4: Manage the lifecycle of agents within multi-agent workflows
Adding, updating, replacing and retiring agents in a running workflow while keeping it working and its history auditable.
Study it
Adding, updating, replacing and retiring agents without breaking workflows
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 1
An organization wants to trial an updated version of its shared security-review custom agent with a few maintainers before everyone gets it, without disrupting the current version that teams use daily. What is GitHub's documented approach?
AEdit the live profile in agents/ and revert it if anyone complains
BAdd target: test to the profile's frontmatter while it is being tried
CAdd user-invocable: false to the new profile so only maintainers can select it
DPut the test profile in .github/agents of the .github-private repository, then move it to agents/ to release
Show the answer and why
AEdit the live profile in agents/ and revert it if anyone complains
Incorrect
That changes the agent for everyone at once instead of testing privately first.
BAdd target: test to the profile's frontmatter while it is being tried
Incorrect
target accepts vscode or github-copilot; there is no test target.
CAdd user-invocable: false to the new profile so only maintainers can select it
Incorrect
With user-invocable: false nobody can select the agent manually; it can only be used programmatically, and the setting doesn't target a group.
DPut the test profile in .github/agents of the .github-private repository, then move it to agents/ to release
Correct
Agents in .github/agents there are usable only from that repository; moving the file to agents/ releases it.
To test a custom agent privately, create its profile in .github/agents of your organization or enterprise .github-private repository; agents there are only available to members with access to that repository, and only when they start a task within it. Once satisfied, move the profile into the agents directory and merge it, which makes it available to all users.
An organization provides a custom agent named release-notes. One repository needs a variant with a different template and wants teams there to keep invoking it by the same name, without changing the organization's agent for everyone else. What should the repository do?
AFork the organization's .github-private repository and edit the profile there
BAdd its own release-notes agent profile in the repository's .github/agents folder
CAsk the organization owner to add a repository filter to the shared agent's frontmatter
DSet user-invocable: false on the organization agent for that repository only
Show the answer and why
AFork the organization's .github-private repository and edit the profile there
Incorrect
A fork doesn't change which profile the repository uses; a repository-level profile does.
BAdd its own release-notes agent profile in the repository's .github/agents folder
Correct
In naming conflicts the lowest level wins, so a repository agent overrides the organization's.
CAsk the organization owner to add a repository filter to the shared agent's frontmatter
Incorrect
Profiles have no repository filter; the override works by defining the agent at repository level.
DSet user-invocable: false on the organization agent for that repository only
Incorrect
user-invocable applies to the profile everywhere; it can't target one repository.
Custom agents can be defined at repository, organization and enterprise level. In naming conflicts, the lowest level configuration overrides higher levels: a repository-level agent takes precedence over an organization-level agent, which overrides an enterprise-level agent. The file name, without .md or .agent.md, is used for deduplication between levels.
How can an enterprise manage its enterprise-level custom agents?
AFrom the AI Controls view or with the REST API
BOnly by editing files on each developer's machine
COnly through GitHub Support requests
DOnly in each repository's settings page
Show the answer and why
AFrom the AI Controls view or with the REST API
Correct
Enterprise custom agents can be managed in AI Controls or through the REST endpoints for custom agents.
BOnly by editing files on each developer's machine
Incorrect
They are managed centrally in AI Controls or by API.
COnly through GitHub Support requests
Incorrect
Owners manage them directly.
DOnly in each repository's settings page
Incorrect
Enterprise agents are managed at the enterprise level.
Custom agents can be defined at enterprise level for control and compliance, or at organization and repository level for team flexibility. Enterprise-level custom agents can be managed from the AI Controls view or with the REST API endpoints for Copilot custom agents.
A custom agent profile defines mcp-servers for an internal tool. Where is that property used?
AEverywhere the profile is used, including IDEs
BWith Copilot cloud agent, but not by custom agents in VS Code and other IDEs
COnly in VS Code
DNowhere; MCP servers can only be set per repository
Show the answer and why
AEverywhere the profile is used, including IDEs
Incorrect
IDE custom agents don't use mcp-servers.
BWith Copilot cloud agent, but not by custom agents in VS Code and other IDEs
Correct
mcp-servers isn't used by IDE custom agents.
COnly in VS Code
Incorrect
It is the IDEs that don't use it.
DNowhere; MCP servers can only be set per repository
Incorrect
Profiles can define MCP servers for cloud agent.
An agent profile's mcp-servers property adds MCP servers and tools for that agent, and metadata annotates it. Both are not used in VS Code and other IDE custom agents. For cloud agent, a profile's servers are combined with the repository's MCP configuration.
Which file name is valid for a custom agent profile on GitHub?
Aapi reviewer.agent.md
Bapi+reviewer.agent.md
Capi_reviewer-v2.agent.md
Dapi@reviewer.agent.md
Show the answer and why
Aapi reviewer.agent.md
Incorrect
Spaces aren't allowed.
Bapi+reviewer.agent.md
Incorrect
+ isn't allowed.
Capi_reviewer-v2.agent.md
Correct
Only ., -, _, a-z, A-Z and 0-9 are allowed.
Dapi@reviewer.agent.md
Incorrect
@ isn't allowed.
When you create a custom agent profile, choose a unique, descriptive file name before .agent.md. The file name may only contain the characters ., -, _, a-z, A-Z and 0-9.
A developer creates a new custom agent with /agent in Copilot CLI. What must they do before using it?
APush it to the default branch
BRun /compact
CAsk an admin to approve it
DRestart the CLI
Show the answer and why
APush it to the default branch
Incorrect
Personal and project agents load locally after a restart.
BRun /compact
Incorrect
/compact summarizes context; it doesn't load agents.
CAsk an admin to approve it
Incorrect
No approval is needed for local agents.
DRestart the CLI
Correct
The CLI loads new custom agents on restart.
In Copilot CLI, /agent and then N creates a custom agent, either in the project's .github/agents/ or your ~/.copilot/agents/. You choose its tools, and then restart the CLI to load the new agent.