Copilot makes it easy to do many things – understand why a test is failing, investigate a dependency, implement a feature, or review a pull request. It is tempting to assume it is a single all-purpose helper. In reality, Copilot CLI is more like a team of specialists. Each agent is a specialized worker, and the AI model decides which ones are best for helping you with your tasks.
Most components of AI are implemented in surprisingly simple ways. Agents are no exception. Under the covers, they are really no different than the agent profiles you can create yourself – just a bit of YAML and markdown to describe its purpose and capabilities. Because of this, it is surprisingly easy to learn about them. You just need to 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, adding or updating agents to improve different components of the overall development experience. In fact, each new update of Copilot can change the available options.
Meet the profiles
Copilot CLI will gladly tell you about its specific agent configurations, including each one’s intended purpose. At this moment, the list will look something like this:
| Name | Description |
|---|---|
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. Some, however, will specifically ask for only a few tools. This is helps limit what the agent can do by restricting its access. Instead of just simply relying on instructions that the model may ignore, the profile may ask for only a subset of the available features.
Review the descriptions above, and you may notice that explore even includes a list of its tools in the description. While it is meant to be read-only, you may notice it can still run bash and powershell. That means it can do much more than just search for files!
The model perspective
Agent profiles are also paired with specific models. For example, at the current moment, explore tends to use Anthropic’s Haiku. It may seem counter-intuitive to use a smaller model with less reasoning power for a task like code exploration. In practice, however, there are multiple benefits.
A smaller model is less likely to overthink a task and more likely to stay focused on exactly what you asked for. Higher reasoning can be helpful for complex planning, but it can add extra tokens for work that won’t benefit. More importantly, a reasoning model may choose to evaluate what it is being asked to do and then decide on a different course of action. By limiting the reasoning power, the model is more likely to focus on the requested task and nothing else.
Agent loading
Like tools from an MCP server, agent profiles are loaded based on the model’s assessment of which agent should be used for a task. This decision is based on the name and description of the profile. Any time the model decides a task may be a good fit for a specific agent, it is likely to use that agent automatically. So if the keyword explore or its description matches your current task or prompt, the model may choose that agent. In many cases, this leads to an optimal experience – but not always.
When a task is assigned to one of these agent profiles, it inherits both its instructions and its tools. The tools are not just a suggestion; they are provided or excluded based on what the profile demands. That means it is possible for the model to select a profile to run a task that looks reasonable based on its name, but then fail because the necessary tools are not available.
For example, imagine the task is to review the code and then update an issue. If that is assigned to an explore subagent, it will end up with a selection of search and shell tools, but it would not have access to the GitHub MCP server. As a result, it wouldn’t be able to complete that task. This is part of the reason why the agent’s description provides those extra details about its tools. It wants to help ensure that the AI doesn’t choose that agent if it ultimately can’t do the job.
Not all loading is automatic. You also have the option to explicitly request an agent in your prompt. Consider a simple prompt like this:
1Use a *rubber-duck* subagent to critique the current code changes.The model will reason that you want a specific agent to be used for that task. It will then request that the harness create an agent with that profile to execute the command. Whether the agent decides to load an agent automatically or you request one explicitly, the result is the same: the task is executed with the tools and instructions that are appropriate for that agent.
A clearer way to work with agents
As you can see, GitHub Copilot CLI provides a number of optimized agent profiles built into the same tooling you are already using. That makes them easy to learn about and saves you from having to reinvent the best setup for common tasks. Try exploring what they can do, and you may be pleasantly surprised by how much they can improve your effectiveness.
A useful rule of thumb is simple: match the agent to the kind of work you are doing and do not assume there is only one helper behind the scenes. If you want a quick scan, use explore. If you want validation, use task. If you want a critical review, use code-review. And if you want context from outside the repo, use research or security-review when the task specifically calls for it.
Once you see the roster, the pattern becomes obvious: Copilot CLI is not just one AI with a single voice. It is a small system of roles, each tuned for a different part of the workflow.