Course · Copilot · Automation: cloud coding agent

Assign an issue to Copilot

Take a typical backlog item on orders-service, the course’s illustrative order-management API your squad owns: the validation edge case where an order sitting exactly at the approval threshold (the amount above which an order needs a second approver) should require approval, but currently slips through, counted as under it. You could open VS Code and fix it in the Agent role (Copilot’s autonomous role that edits and runs commands) - it is a small change. But it is also the kind of task you would happily hand a teammate and forget about until their PR shows up. That is precisely what the cloud coding agent is for.

What “assign” actually does

When you assign work to Copilot, GitHub spins up an ephemeral GitHub Actions environment - a fresh, isolated checkout of the repo that exists only for the duration of this task and is torn down afterward. The agent works entirely in there: it reads the issue, explores the code, makes its changes, runs what it can within its execution limits (which come up later in this chapter), and packages the result. None of it happens on your machine. You are not watching a loop run; you have handed off a unit of work, and the next thing you hear from it is a pull request.

This is async in the fullest sense: there is no chat view to babysit. The unit of interaction is the issue, and the unit of return is the PR.

Where you can kick it off

There is no single button - assignment lives in several places, so you can start the agent from wherever you already are:

The Agents panel on GitHub.com (covered in the coding-agent how-to) - the central place to see and start agent work across your repos.
Assigning an Issue to Copilot - the most natural one for clearing a backlog. Open the issue, assign it to Copilot like you would assign it to a person, and it begins (assuming the cloud agent is enabled for your repo or org - availability varies by plan and policy, and the agent surfaces themselves carry preview labels and shift). This is the move for the threshold edge case: write the issue clearly, assign, walk away (each run draws on your plan’s allowance - the models chapter covers spend).
@copilot in a pull request comment - start or extend agent work from inside a PR thread, after the fact; the next lesson covers steering from the PR.
From VS Code - hand a task off to the cloud agent without leaving the editor, when you realize mid-session that something is better run async than driven by hand.
From security campaigns - assign security alerts to Copilot from a campaign and let it propose the fix.

There are also ways to assign from outside GitHub entirely - an issue tracker, for instance - but availability varies by integration, plan, and organization policy. Treat those as optional convenience paths and check the current integration documentation; the dependable spine is the GitHub-native list above.

Write the issue like you mean it

The quality of what comes back tracks the quality of the issue, the same way a prompt’s clarity shaped Copilot’s answer in chat - except now there is no follow-up turn to course-correct in real time. Describe the behavior you want and the boundary of the change: “Orders exactly at the approval threshold currently skip approval; they should require it. Fix the comparison and add a test for the boundary.” You are not writing pseudocode; you are writing a crisp behavioral description - it just has to stand on its own, because you will not be in the room while it works.

And it will not be working from a blank slate. The cloud agent reads the repo’s custom instructions and skills (packaged procedures installed in the repo, where present), so your conventions are already in its context before it touches a line.

Assign the issue. The agent goes to work, and what it brings back is the subject of the next lesson - it proposes, you merge.