GitHub Copilot CLI Tips & Tricks — Part 5: Delegation

We've covered modes, session management, parallelization with /fleet, and hooks. To close out the series, we're looking at delegation, the feature that lets you hand off work from your terminal to a background agent in the cloud, and build a network of specialized custom agents for your team.

Two flavors of delegation

"Delegation" in Copilot CLI means two related but distinct things:

1. /delegate — handing off a task to the Copilot coding agent in the cloud, which works asynchronously on GitHub while you continue with other work
2. Custom agents + /agent — routing tasks to specialized subagents tailored to specific types of work, running locally within your CLI session

Both follow the same principle: rather than one generalist agent handling everything, you route work to whatever agent is best suited for the job. Let's look at each in turn.

/delegate — Offload to the cloud

What it does

Running /delegate TASK-DESCRIPTION commits any unstaged changes to a new branch. After that, the Copilot coding agent opens a draft pull request, makes changes in the background, and then requests a review from you. Copilot provides a link to the pull request and its coding agent session in your terminal once this process begins.

In other words, /delegate is a fire-and-forget command. You describe the task, Copilot hands it off to a cloud-hosted agent on GitHub, and your terminal is immediately free.

When to use it

This is the right choice when:

• The task is well-defined enough that you don't need to steer it interactively
• You want to keep your local terminal unblocked for other work
• The output should be reviewed as a pull request anyway — features, fixes, refactors

It's less suitable for exploratory or ambiguous tasks where you'd want to guide the work as it progresses.

The & shorthand

You can also prefix any prompt with & to delegate work to the Copilot coding agent in the cloud, freeing your terminal for other tasks.

& "Add pagination to the /api/users endpoint and write integration tests"

This is the fastest way to offload a task without typing the full /delegate command.

Monitoring delegated work

Once /delegate or & fires, you'll get a link to the PR and the agent's session. You can track progress directly on GitHub, or pull the session back into your local CLI with /resume — you can kick off a Copilot coding agent session on GitHub and then use Copilot CLI to bring that session to your local environment. This gives you a seamless handoff in either direction: delegate from CLI, monitor on GitHub, and resume locally if needed.

Custom Agents — Building a team of specialists

What custom agents are

A custom agent is a specialized version of Copilot. When you prompt Copilot to carry out a task, it may choose to use one of your custom agents if Copilot determines that the agent's expertise is a good fit for the task. Work performed by a custom agent is carried out using a subagent — a temporary agent spun up to complete the task. The subagent has its own context window, which can be populated by information that is not relevant to the main agent. In this way, especially for larger tasks, parts of the work can be offloaded to custom agents without cluttering the main agent's context window.

Defining a custom agent

Each custom agent is defined by a Markdown file with an .agent.md extension. You can create these manually or use an interactive wizard inside the CLI.

A basic agent file looks like this:

---
name: Security Auditor
description: Reviews code for security vulnerabilities, OWASP issues, and credential exposure
tools: [agent, edit, search, todo]
---

You are a security-focused code reviewer. When asked to review code, you check for:
- Hardcoded credentials or secrets
- SQL injection and XSS vulnerabilities
- Insecure dependency versions
- Missing input validation

Always explain your findings clearly and suggest a concrete fix for each issue.

Save it as .github/agents/security-auditor.agent.md and it's immediately available in your CLI session.

Where to store agent files

You can define custom agents at the user, repository, or organization/enterprise level. The three locations are:

• ~/.copilot/agents/ — personal agents available in every session, on every repo
• .github/agents/ — repo-level agents committed to a specific repository
• {org}/.github repository — org-wide agents available to everyone in your GitHub organization

In the case of naming conflicts, a system-level agent overrides a repository-level agent, and the repository-level agent overrides an organization-level agent.

Invoking custom agents

There are several ways to trigger a custom agent:

Explicit invocation with /agent: Enter /agent in interactive mode and choose from the list of available custom agents, then enter a prompt that will be passed to the selected agent.

Tell Copilot which agent to use:

Use the security-auditor agent on all files in /src/app

Launch with --agent flag:

copilot --agent security-auditor --prompt "Review /src/app/program.cs"

This is useful for scripting and automation, where you want to guarantee a specific agent is used.

Automatic delegation

One of the most powerful behaviors: the AI model can choose to delegate a task to a subsidiary subagent process that operates using a custom agent with specific expertise if it judges that this would result in the work being completed more effectively. The model may equally choose to handle the work directly in the main agent.

This means you don't always have to explicitly invoke agents. If your prompt matches the description of an available agent well enough, Copilot will route to it automatically. The user-invocable property in an agent file controls whether Copilot considers it for manual delegation — set it to true if you want an agent that can be invoked directly from the UI.

Combining delegation and /fleet

As touched on in the previous post, custom agents and /fleet work well together. When /fleet breaks a large task into parallel subtasks, each subagent can use a different custom agent based on the nature of its work. For example, a task that involves both writing new code and auditing existing code could have its subtasks routed to a developer agent and a security-auditor agent respectively — running concurrently.

An agent setup example

Here's what a well-organized custom agent roster might look like for a typical product team:

• security-auditor.agent.md: OWASP checks, credential scanning, input validation review
• code-reviewer.agent.md: Style, patterns, test coverage, complexity
• docs-writer.agent.md: README updates, API docs, inline comments
• test-writer.agent.md: Unit and integration test generation, coverage gaps
• k8s.agent.md: Kubernetes YAML generation, optimization, validation

Stored in your org's .github repository, these agents become available to every developer in your organization — a shared team of specialists that anyone can invoke, and that Copilot can route to automatically.

Wrapping up the series

Delegation is the final piece of the Copilot CLI puzzle — it's what lets you move from a single-agent, single-task workflow to a team of specialists working in parallel, asynchronously, and in the cloud. Combined with the modes from post 1, session management from post 2, /fleet from post 3, and hooks from post 4, you now have the full picture of what Copilot CLI can do.

The through-line across all five posts is the same idea: Copilot CLI gives you fine-grained control over how much autonomy you give the agent at each stage of your work. From reviewing every step in standard mode to firing off a delegated PR with & and walking away — the right level of autonomy depends on how well-defined the task is and how much you trust the result. Get that calibration right, and Copilot CLI becomes a genuine force multiplier.