It proposes, you merge

A little while after you assigned the issue, a pull request appears - opened by Copilot’s cloud coding agent (the one working in GitHub’s environment rather than your IDE). What it did, it did on its own branch: branch creation, commits, and pushes all land there, and the pull request is how the work reaches you (per the About page, as of September 2026). The documented flow ends at a pull request requesting your review - the agent does not merge its own work; merging, or configuring auto-merge, is repo territory humans control.

Why a pull request, and why it matters

Think back to your first change, where you read the diff before accepting it and you made the commit. The async surface (working through GitHub rather than your IDE) does not loosen that rule - it enforces it structurally, and that is control as the course uses the word: an enforced boundary, not a request. The agent ran with no one watching, in an environment you never saw, so the guarantee you get in exchange is the shape of its output: work on its own branch, delivered as a pull request, with review and merge left to you (auto-merge and required reviews, where configured, are repo settings humans control - nothing merges through a gate nobody enabled). A pull request is the agent saying here is what I would do in the most reviewable form GitHub has. The decision to merge still sits with your side - you, or the merge rules your repo configured - exactly as it was for the first small reviewed fix.

So the loop is identical to the one the whole course runs - agent proposes, you decide - just lifted up a level. The diff is not in a chat view anymore; it is a pull request, with all the review machinery that comes with: the file-by-file diff, the CI checks, your team’s review tools.

Review it like any other PR

Open the pull request and read it the way you read every change in this course - the same three questions, now against a PR:

1. Did it change what the issue asked, and only that? Scope creep is easier to spot in a PR diff than anywhere; flag it if the agent wandered.
2. Is the fix correct? Read the changed comparison and the test it added. A passing check is necessary, not sufficient - the agent wrote that test, and a test can pass for the wrong reason (and workflow runs may wait for an approval action, depending on your repository’s workflow-permission settings, so the board may not even be complete yet).
3. Does it match how this repo does things? Because it read the repo’s custom instructions and skills (the convention guidance you configured, if any - the support matrix lists the instruction files the cloud agent applies, and Agent Skills work with it too, as of September 2026), it usually does. When it does not, that is a signal those instructions have a gap.

That second question is the whole trust model of unattended work in one line. The agent ran with nobody watching, so the checks in its environment decided what “done” meant - and a green board can mean less than it appears. Scale the night up in your head - not your one issue but a batch of chores in the widget’s generic repo below - then watch it come back green and decide what its report has to get past before you believe it. The widget’s own ending makes the point in its last row - the misread ticket that stays green through every check - and says it better than prose would: green is not the same as right, so a batch that comes back green is a batch whose report still needs reading:

Nine chores, queued for an agent to run overnight. The terminal replays the night as it happened; the panel is the morning report - the only thing you’ll actually read. Watch what its checkmarks are made of, and when playback pauses, decide what the run has to get past before you believe it.

overnight batch - ledger-app

overnight batch · repo: ledger-app · 9 chores queued · nobody watching

the morning report

The flaw rate here is theatrical - seven duds in nine - because the point is what each wiring would have caught, not the odds. The checks wear different clothes per tool (a CI step, a test command the loop must pass, a verifier agent), but the question is always the same: what does this run have to get past before “done” reaches you? And the residual is real: no check catches a requirement nobody wrote down.

Iterate without leaving GitHub

If the PR is close but not right, you do not necessarily re-assign and start over. Comment @copilot in the pull request thread - “the test only covers the at-threshold case; add one just below it too” - and the agent continues work on the PR branch (the @copilot continuation and the branch-based flow are per the About page, as of September 2026; the docs restructured during 2026, and earlier material describes PRs as drafts - the review-shaped guarantee is what the current pages state). Do not assume the exact prior ephemeral environment is reused. The PR thread becomes the conversation, the way the chat view was in the IDE. You steer with words here exactly as you did in the Agent role (the role that edits files and runs commands for you); the medium changed, the move did not.

When the pull request is right, you do the step the flow leaves to you: review it, and merge it (or let your repo’s own auto-merge rules finish the job). One issue down.

That clears the backlog item - but the agent ran inside an environment you have taken on faith so far. The last lesson opens that box: what it can install, how long it is allowed to run, and who decides it is allowed to run at all - customizing the agent’s environment.