title: Discovering the Built-In Agents in GitHub Copilot CLI abstract: | It is easy to treat a coding agent as one helpful black box: ask for a change, then wait for an answer. But Copilot CLI can draw on several specialist agents, each suited to a different kind of work. A single question lets you see the roster in your own session, understand what each role is for, and make much more deliberate requests. description: “Ask GitHub Copilot CLI which native agents it provides, then learn how explore, task, review, research, and security roles differ.” categories: [AI, DevOps, GitHub] tags: [AI, GitHub] weblogName: KenMuse.com postId: 274e15d8-819d-4d63-b4db-61c4a6a8cc52 postStatus: draft draft: true
publishDate: 2026-08-22T05:00:00-04:00 date: 2026-08-22 month: 2026/08 year: 2026
slug: discovering-built-agents-in-github-copilot-cli banner: images/banner.png banner-source: | Gemini (gemini-2.5-flash-image) -> A photorealistic overhead view of a modern technical operations desk arranged into six distinct work areas around a central GitHub Copilot CLI terminal. Each area visually represents a specialty: a magnifying glass over source files, a terminal running tests, a multi-step project board, a code diff under review, an open research notebook, and a security shield examining a lock. Clean professional workspace, balanced cyan, green, amber, and red accents, realistic monitors and paper textures, cinematic natural lighting, horizontal blog banner composition, no readable text, no logos.
Copilot makes it easy to find why a test is failing, investigate a dependency, implement a feature, or review a pull request. It is tempting to think of it as being a bare-bones agent. The truth is a bit more complex. In order to make it perform well, it actually requires a number of specialized agent profiles that can help you with your tasks. Since agent profiles are exposed in the session context, it’s surprisingly easy to learn more about them. You just ask!
Summarize the agents that are natively available to you and what they doCopilot will then report back to you the agents it can see in the context. The list can and does change over time, with new or update agents being created to improve different parts of the overall experience. Each new update of Copilot can change the available options.
Meet the profiles
At the current moment, if you ask Copilot to provide a list of the agents and their descriptions, it may return something like the following:
explore- Fast agent for codebase exploration and research. Use it for multiple independent research threads that each need substantial context, such as complex cross-cutting investigations across a large codebase. It can use grep, glob, view, bash, and PowerShell with a lightweight model.
task- Agent for executing commands with verbose output, including tests, builds, linters, and dependency installation. It returns brief summaries on success and full output on failure. Use it when you primarily need command execution and success/failure status.
general-purpose- Full-capability agent running in a subprocess. Use it for complex, multi-step tasks requiring the complete toolset and high-quality reasoning. It can perform investigation, editing, testing, and other development work.
code-review- Read-only reviewer of existing staged, unstaged, or branch diffs. It reports only high-confidence bugs, security vulnerabilities, and logic errors, while ignoring style issues and trivial concerns. It requires a change set to compare.
research- Research subagent that performs thorough searches based on instructions. It can search GitHub, fetch files, verify claims, and report detailed findings with citations.
security-review- Read-only specialist for explicitly requested security vulnerability reviews. It looks for high-confidence, exploitable security vulnerabilities and reports severity and confidence, while ignoring non-security noise.
Agents and their tools
Most of the agents are allowed access to all tools, but not all of them. This is what limits how much the agent can do. While the profile may contain a list of instructions to restrict what the agent can do, the available tools are what actually enforce those restrictions. You’ll notice that explore even lists its tools in its description for convenience. In fact, you can see that even though it is meant to be read-only, it can still run bash and powershell. That means it actually has access quite a bit more functionality that its name implies.
The model perspective
In addition, the agent profiles configured to use specific models. For example, at the current moment, explore tends to use Anthropic’s Haiku. It may seem counter-intuitive to be using a smaller model with lower reasoning support. However, this has two big benefits. First, reduced reasoning means that it is less likely to overthink its task and more likely to do exactly what is requested. Higher reasoning can help with problem solving and planning, but for simple task execution it can lead to the agent getting distracted. Second, you want to use the smallest token window that will perform a given task. This minimizes the chance of hallucination. By targeting models that are best aligned to the task, the agents help to control the behavior.
Agent loading
Like tools from an MCP server, agent profiles are loaded based on the model reasoning that they should be used for a task. This comes from the name and description. Any time the model reasons that the task may be appropriate for a specific agent, it is likely to automatically use that agent. So if the keyword explore or its description relates to the current task or prompt, the model may reason that it should use that agent. In many cases, this leads to an optimal experience – but not always.
It’s important to know that if the task you are performing is assigned to one of these agent profiles, it inherits both its instructions and its tools. Unfortunately, the list of tools is not a consideration for that assignment. That means that it is possible for one of these profiles to be used for a task, causing it to execute a subagent that looks the necessary tools for the job. For example, imagine the task is to review the code and then update an issue. If that is assigned to an explore subagent, the limited set of available tools may prevent it from being able to update the issue! That’s one reason that its description includes the tool details. The name and description can make it a match for a number of potential tasks, and providing a list of its capabilities helps to ensure that it is not selected for a task that may need access to additional tools.
Of course, you also have the option to explicitly request an agent in your prompt. A simple statement like Use an *rubber-duck* subagent to review the current code changes is often enough to ensure that a specific agent is used for the task. While you can’t directly select most of the agents, most models will send back a tool request to use a specific agent if you ask for it.
A clearer way to work with agents
As you can see, GitHub Copilot CLI provides a number of optimized agent profiles natively to help you with your work. The great thing is that they are something build on the same tooling that you are already using. That makes them easy to learn about, and saves you from having to figure out the best way to create agent profiles for common tasks. Try exploring what they can do to understand how they can help you do more with less effort. You may be pleasantly surprised at how much they can improve your effectiveness!