Skip to content
Follow
← GitHub Copilot in Practice: Agentic Coding for Production Engineering Teams

Lesson 8 of 8 · 20 min read

Capstone: Supervising and Validating an End-to-End Agentic Workflow

This capstone introduces no new Copilot feature.

1. Capstone Overview and Change Scoping

What This Chapter Draws On

This capstone introduces no new Copilot feature. It runs one more change through the reference project by applying, in a single connected pass, everything you have already built up:

  • Chapter 1: the reference project itself, plus your first completions/chat-assisted change.
  • Chapter 2: the Copilot plan you chose for the team's workflow.
  • Chapter 3: the pull request from the Chapter 3 workflow — produced by the cloud agent or, on the fallback path, via another surface such as local Agent mode, as your Chapter 3 note records.
  • Chapter 4: the Copilot code review pass applied to that pull request — or, if code review was not available to you there (recorded on Chapter 4's Path B), the manual-review triage you completed instead.
  • Chapter 5: your recorded Chapter 5 MCP outcome, carried forward as an input to this capstone.
  • Chapter 6: the context-assembly and prompt-composition habits you practiced for the project, including the context inventory and composed prompt you produced for "the project's next real change" at the end of that chapter — Activity 1 below offers that artifact as a starting point for this capstone's change.

Chapter 7's legacy billing reference material isn't needed here — this capstone doesn't depend on it, so its absence from this recap is intentional, not an oversight.

None of this is re-taught here — if you need the mechanics behind any of it, go back to the chapter that owns it.

The chapter itself follows one arc, mirrored by its activities: plan → implement → review → validate. "Plan" covers both scoping the change (Activity 1) and assembling context and a prompting/validation plan (Activity 2); the closing reflection (Activity 6) sits outside this four-stage loop rather than adding a fifth stage to it. Seeing the whole arc up front matters, because the value of this capstone is in supervising the full sequence, not any single step in isolation.

Scoping your change

Before touching any Copilot surface, this capstone needs one realistic change to make to the reference project — one that touches more than one concern, since the review and MCP-tooling steps later in this chapter need something real to act on. This section explains why that requirement matters; it does not restate the bounding criteria, the failure modes to avoid, or the scope-statement and surface-naming instructions — Activity 1 carries the actual scoping procedure, step by step.

2. Assembling Context and a Prompting Plan

With the change scoped, this section explains why you now apply the context-supply and prompt-composition technique from Chapter 6 before touching any Copilot surface — it does not re-explain progressive specificity, task decomposition, unambiguous referents, or the four context-supply mechanisms, and it does not restate the procedure; Activity 2 carries the actual steps.

If Activity 1 started from Chapter 6's context inventory and composed prompt, treat that as your draft and revise it against the change you actually scoped; otherwise, build the context and prompt fresh using the same habits you already practiced there.

GitHub's own best-practices documentation recommends choosing the interaction mode that fits the task at hand, and states that any suggestion Copilot produces should be reviewed for correctness and security and paired with linting or code-scanning tools rather than accepted uncritically. The reason to apply that guidance now, before implementing anything, rather than after seeing what Copilot produces: naming your validation checks in advance keeps the bar honest instead of letting it quietly bend to fit whatever comes back. Activity 2 has you state that plan explicitly; Section 5 is where you follow through on it.

3. Implementing the Change: Agent Mode or Cloud Agent, MCP-Assisted

Implement (or delegate) the scoped change now, on the surface you named in Activity 1, following the context and prompt you assembled in Activity 2. Whether there's an MCP server to invoke here, and on which surface, depends on your recorded Chapter 5 MCP outcome; Activity 3 carries the full statement and what to do under each. This section briefly recaps the local-vs-cloud-agent distinction (Chapter 3) and MCP's approval model (Chapter 5) only to the extent needed to interpret what you observe; it introduces no new MCP configuration and no new cloud-agent eligibility or billing detail.

The one thing worth watching closely here, if you have an MCP server available, is tool-call approval. Current first-party GitHub documentation establishes a surface-dependent MCP approval model, not a single universal rule:

  • For repository-level MCP servers configured for the Copilot cloud agent or Copilot code review, Copilot uses the configured tools autonomously and does not prompt for approval, because these are unattended surfaces with no interactive session watching.
  • For interactive IDE Copilot Chat/Agent mode sessions — a human present at the keyboard — Copilot still requests explicit approval before invoking an MCP tool by default (you may optionally enable session/workspace auto-approval yourself).

Whichever behavior your implementation surface produces, explain it by naming the surface you were on, not as "MCP always/never asks for approval" — that single-rule framing is exactly what current documentation rules out. Activity 3 has you record what you actually observed, consistent with your recorded Chapter 5 MCP state, or that no MCP server was available to observe.

4. Reviewing the Change: Code Review and Scoped Custom Instructions

This section explains why the review step matters and what boundaries carry over from Chapter 4; Activity 4 carries the actual procedure for running review and triaging comments.

Code review's plan eligibility and the Path B manual-review fallback are exactly as Chapter 4 established them — confirm the state you recorded there still holds before Activity 4.

Copilot code review's feedback is comment-only and non-blocking. That means every comment you receive is an input to your judgment, not a command: for each one, you decide whether to act on it or dismiss it, with a rationale either way. A change is not "reviewed" until every comment has that explicit disposition — an unexamined comment left dangling is a gap in your own oversight, not Copilot's. The same standard applies to observations from a manual review pass on the Path B manual-review fallback.

This section does not re-teach the full custom-instructions mechanism inventory (repository-wide files, path-specific instructions, AGENTS.md, custom chat modes) — that belongs to Chapter 4 — and it does not generalize the review-scoped composition guidance beyond code review; both boundaries carry over unchanged from Chapter 4.

5. Validating with Real Engineering Checks

A clean Copilot code review is not evidence that the change works — this section explains why that's true and lets Activity 5 carry the actual checks to run.

This is the same documented habit you applied when planning validation in Section 2: GitHub's own best-practices guidance states that suggestions should be reviewed for correctness and security and paired with linting or code-scanning tools rather than accepted on Copilot's word alone. Here you close the loop on that guidance rather than restate it: the project's own checks, not Copilot's review comments or its confidence in the diff, are the deciding signal on whether the change actually works.

No new testing framework or CI configuration is introduced here; use what the reference project already has.

6. Capstone Synthesis and Reflection

What This Section Teaches

Everything up to this point has been application of concepts already owned elsewhere. This section teaches the one thing that belongs to this chapter alone: the pattern you just practiced, not any new Copilot fact.

The plan → implement → review → validate pattern

Supervising an agentic change end-to-end means treating it as four distinct stages, each with its own responsibility:

  1. Plan — scope the change and decide, in advance, which surface will implement it and which checks will judge it.
  2. Implement — carry out the change on that surface, watching how it behaves (including tool-call approval) rather than treating it as a black box.
  3. Review — apply human- and Copilot-assisted review, with every comment resolved by explicit judgment.
  4. Validate — confirm the result against the project's own engineering checks, which decide correctness, not the review pass alone.

None of these stages is optional, and skipping straight from "implement" to "merge" is the failure mode this whole capstone exercise is designed to counter.

Recapping what shaped the exercise

Two earlier decisions shaped what was available to you here, and neither needs re-deriving:

  • What determined your implementation surface. Agent mode's availability was determined by your Chapter 1 IDE record — which surfaces your chosen IDE actually supports — not by your Copilot plan. The cloud agent is different: the Copilot plan your account is actually on now — your most recent plan record, which is still the one from Chapter 2 Activity 3 unless Chapter 4's eligibility check recorded a switch that superseded it — determines cloud-agent eligibility, and for Business and Enterprise plans, the administrator-gated eligibility (or access blocker) you confirmed in Chapter 3 also shaped what was actually available to you.
  • The prompting/context technique you practiced in Chapter 6 is what made the prompt and context package in Section 2 possible at all, rather than something you had to invent from scratch.

Activity 6 asks you to state both connections concretely, in your own words, against the specific choices you made in this chapter.

Activity 1: Scope the Capstone Change

Goal: Define the one concrete, appropriately bounded change that every later activity in this capstone builds on.

Steps:

  1. Review the reference project as it stands after Chapter 1 through Chapter 6: the initial change, the Chapter 2 plan decision, the pull request the Chapter 3 workflow produced, your recorded Chapter 5 MCP outcome, and the context/prompting practice from Chapter 6 — including the context inventory and composed prompt Chapter 6's closing activity produced for "the project's next real change," if you have one.
  2. Pick one change to make to the reference project. If Chapter 6's artifact still describes a real, appropriately bounded next step, use it directly as your starting point rather than scoping from scratch; if it no longer fits (the project has moved on, or the artifact's change is too small or too large for this capstone), scope a fresh change instead and say so.
  3. Bound it deliberately: small enough to carry through implementation, review, and validation in one sitting, but touching more than one concern, so the review and MCP-tooling activities later in this chapter have something real to work with. A trivial one-line fix and a sprawling redesign both defeat the exercise — the first gives later activities nothing to do, the second will not finish.
  4. Write a short scope statement (a few sentences) describing the change and its intended outcome, noting whether it reuses Chapter 6's artifact or is freshly scoped.
  5. Name the interaction surface you intend to use — Agent mode or the cloud agent — with a one-line rationale for why it's available to you. If you're choosing Agent mode, ground this in your Chapter 1 IDE record — which surfaces your chosen IDE actually supports. If you're choosing the cloud agent, ground this in the Copilot plan your account is actually on now — your most recent plan record, still the one from Chapter 2 Activity 3 unless Chapter 4's eligibility check recorded a switch — and, if your live plan is Business or Enterprise, the administrator-gated eligibility you confirmed (or the access blocker you recorded) in Chapter 3. This is a recap of decisions you already made, not a new eligibility lookup.

Expected outputs:

  • A written change-scope statement for the reference project.
  • A named interaction/agent-surface choice with a one-line eligibility rationale tied to your Chapter 1 IDE record (Agent mode) or your live plan record and Chapter 3 admin check (cloud agent).

Hints:

  • Keep the change small enough to finish end-to-end within the exercise; oversized scope is the most common way this activity stalls.
  • This is a recap of already-established eligibility facts — your Chapter 1 IDE record for Agent mode, your live plan record and the Chapter 3 admin check for the cloud agent — not a re-derivation of billing or eligibility facts.

Checkpoint: your scope statement names one concrete change, and your surface choice correctly ties its eligibility to your Chapter 1 IDE record if you chose Agent mode, or to your live plan record and Chapter 3 admin-gated eligibility check if you chose the cloud agent.

Activity 2: Assemble Context and a Prompting/Validation Plan

Goal: Prepare the change you scoped in Activity 1 for implementation.

Steps:

  1. Assemble context. Reuse the context-supply habits you practiced in Chapter 6 — open or highlight the relevant files, invoke the appropriate chat participant, keep the chat thread focused — rather than reinventing how to supply context. If you're carrying forward Chapter 6's context inventory, update it for the change you actually scoped instead of starting over.
  2. Draft the prompt(s) you intend to send to the surface you named in Activity 1. If you're starting from Chapter 6's composed prompt, revise it to match this change; otherwise draft fresh. Apply prior prompt-composition technique visibly: use progressive specificity, supply an example if one helps, decompose the change into steps if it has more than one part, and remove ambiguous referents ("this function," "that file") in favor of concrete names.
  3. State your validation plan before implementing. In one or two sentences, name which tests, which linter, and/or which CI job will be used to judge the result. This follows GitHub's own documented guidance that suggestions should be paired with linting/code-scanning rather than accepted uncritically — stating it now, rather than after seeing Copilot's output, keeps you from quietly relaxing the bar to fit whatever you get.

Expected outputs:

  • Assembled context notes for the change.
  • Draft prompt text for the chosen implementation surface.
  • A one-to-two-sentence named validation-check plan.

Hints:

  • State the validation plan before implementing, not after, so it isn't rationalized to fit whatever Copilot produces.

Checkpoint: your draft prompt shows at least one concrete prior technique (e.g., decomposition, or a named context-supply mechanism), and your validation-check plan is written down before you implement anything.

Activity 3: Implement the Change via Agent Mode or the Cloud Agent, MCP-Assisted

Goal: Implement (or delegate) the scoped change and finish with an open pull request, while correctly observing and attributing MCP tool-approval behavior to the surface you used.

Steps:

  1. Implement the change using interactive Agent mode, or delegate it to the cloud agent — whichever you named in Activity 1 — following the context and prompt you prepared in Activity 2.
  2. Check your recorded Chapter 5 MCP outcome — it determines whether there's a server to invoke here and on which surface.
    • If Chapter 5 attached MCP — whether you exercised it on both the interactive and an unattended surface (Chapter 5's first state), or only on the interactive surface (Chapter 5's second state — the cloud agent recorded as blocked in Chapter 3, and code review not available to you, recorded on Chapter 4's Path B) — the server remains available to you now on whichever surface you're actually using. If you're carrying forward Chapter 5's second state, note that your observation here stands on its own: you have no unattended-surface run from Chapter 5 to contrast it against, since neither unattended surface was available to you.
    • If Chapter 5 recorded MCP access as blocked entirely (Chapter 5's third state), there is no MCP tooling to invoke here at all — implement the change without it, note "MCP unavailable — Chapter 5 access blocker carried forward" in your record, and skip steps 3–4 below.
  3. If the implementation causes Copilot to invoke the MCP server, record what actually happened: did Copilot ask for approval before the tool call, or did it act autonomously, with no approval prompt?
  4. Explain what you observed by naming the surface you were on, not as a single universal rule. Current first-party documentation establishes that repository-level MCP configured for the cloud agent or Copilot code review is used autonomously, while interactive IDE Agent-mode sessions still request approval by default — so an interactive session that asked for approval, or an autonomous cloud-agent/code-review run that didn't, are both the expected, correct behavior for their respective surface.
  5. Finish with a pull request, regardless of surface — Activity 4 reviews a pull request, not a local branch, so this activity is not finished until one exists:
    • If you used interactive Agent mode, your work may currently sit only on a local branch. Commit your changes, push the branch, and open a pull request against the reference project before moving on.
    • If you delegated to the cloud agent, it already opened a pull request as part of its workflow — reuse that existing pull request as-is; do not open a second one.

Expected outputs:

  • An implemented change (branch or pull request) on the reference project.
  • A short note recording the observed MCP tool-approval behavior and its surface-dependent explanation, consistent with your recorded Chapter 5 MCP state — or, if that state recorded MCP as blocked entirely, a note recording that instead.

Hints:

  • Interactive IDE Agent-mode sessions should still prompt for approval by default; repository-level cloud-agent or code-review MCP use should not.

Checkpoint: a pull request exists containing this change regardless of which surface you used, and your note names the specific surface and matches the documented surface-dependent approval model — or, per your recorded Chapter 5 MCP state, plainly records that no MCP server was available to observe — rather than describing one universal approval rule.

Activity 4: Review with Copilot Code Review and Scoped Custom Instructions

Goal: Validate the Activity 3 pull request using Copilot code review and your scoped custom instructions — or, if code review is not available to you (recorded on Chapter 4's Path B), the same manual-review fallback Chapter 4 established.

Steps:

  1. Confirm the code-review availability you recorded in Chapter 4 still holds for your live Copilot plan — your most recent plan record, still the one from Chapter 2 Activity 3 unless Chapter 4's own eligibility check recorded a switch. Code review is documented as generally available for Pro, Pro+, Business, and Enterprise as of the dated 2026-03-05 architecture announcement; this course's evidence does not establish its status on other plans. If your live plan is Free, Student, or Max, check your live Copilot settings directly rather than assuming either way. If code review is not available to you (recorded on Chapter 4's Path B), use Chapter 4's manual-review fallback unchanged.
  2. If code review is available, run it on the pull request containing the Activity 3 change — whether that's the pull request you opened yourself after a local Agent mode branch, or the one the cloud agent already produced. Either way, act on that pull request; do not review a local branch directly. If you're on the Path B manual-review fallback, perform your manual review pass against that same pull request instead.
  3. Apply the repository's review-scoped custom instructions — reuse ones you composed earlier in the course, or compose them now following the same guidance: clear, concise, short imperative bullets rather than narrative prose, iterated against real review comments rather than written once and left alone.
  4. Copilot code review's comments — or, on the Path B manual-review fallback, your manual-review observations — are non-blocking suggestions, not requirements. Go through every one and either address it or explicitly dismiss it, recording a one-line rationale for your decision either way, before treating the pull request as reviewed.

Expected outputs:

  • A reviewed pull request — the one containing the Activity 3 change — where every Copilot code review comment (or, on the Path B manual-review fallback, every manual-review observation) carries an explicit accept/dismiss rationale.

Hints:

  • Copilot code review feedback is non-blocking comment-only feedback — use judgment about what to act on rather than treating every comment as mandatory.

Checkpoint: code review is confirmed available on your live plan, or code review is not available to you (recorded on Chapter 4's Path B) and you completed the manual-review fallback instead; either way, no comment or observation is left without a stated rationale.

Activity 5: Validate with the Reference Project's Own Engineering Checks

Goal: Confirm the reviewed change actually works, using the project's own checks rather than Copilot's review output.

Steps:

  1. Run the reference project's existing test suite and linter — locally or via CI — against the reviewed change from Activity 4. Fix anything they surface.
  2. Check the result against the validation plan you stated in Activity 2: did the change pass the specific checks you named there? A clean Copilot code review pass is not sufficient evidence of correctness on its own; the project's own tests, linting, and CI are the deciding signal.

Expected outputs:

  • A passing test/lint/CI run tied to the change.
  • A one-line confirmation of whether the outcome matches the plan you named in Activity 2.

Hints:

  • A clean Copilot code review is not sufficient evidence of correctness; the project's own checks are the deciding signal.

Checkpoint: you judge the change complete only once the project's own checks pass — not merely once Copilot's review is clean.

Activity 6: Synthesis Reflection

Goal: Tie the capstone back to the specific decisions and techniques that shaped it, without introducing anything new.

Steps:

  1. Write a short reflection — a paragraph is enough — that names three things concretely:
    • (a) The Chapter 2 plan decision. Name both the provisional Copilot plan you recommended in Chapter 2 Activity 3 for the hypothetical team, and the live plan your own account is actually on now — your most recent plan record, which is still the one from Chapter 2 Activity 3 unless Chapter 4's eligibility check recorded a switch that superseded it. State how that live plan — not the provisional recommendation — concretely constrained or enabled cloud-agent eligibility specifically (for example, plan-based eligibility for the cloud agent, or — if you're on Business/Enterprise — the admin-gated policy you confirmed in Chapter 3); if you used Agent mode instead, note that its availability came from your Chapter 1 IDE record, not from your plan.
    • (b) A Chapter 6 habit. Which specific prompting or context-supply habit from Chapter 6 did you actually reuse in Activity 2 — not "I used good prompting," but the specific technique (e.g., decomposing the task, or naming a specific context-supply mechanism)?
    • (c) The supervision pattern. State the plan → implement → review → validate pattern this capstone just walked you through, in your own words.
  2. This is a recap exercise, not new research — point back to decisions and techniques you already made or learned earlier in the course.

Expected outputs:

  • A short written synthesis reflection covering the plan decision, the prompting/context habit, and the four-stage supervision pattern.

Hints:

  • This is a recap, not new research — point back to decisions and techniques already made or learned earlier in the course rather than introducing new claims.

Checkpoint: your reflection names both your provisional Chapter 2 recommendation and your current live plan, correctly identifies the live plan record as what constrained or enabled cloud-agent eligibility (not Agent mode), names your specific Chapter 6 habit, and states the four-stage pattern — not a generic restatement of "I used Copilot well."

Reference Project Continuity — Chapter 8

Starting state. By the time you reach this chapter, the shared reference project already carries: a first Copilot-assisted change (Chapter 1); a chosen Copilot plan (Chapter 2); a pull request produced by the Chapter 3 workflow, implemented on whichever surface that workflow actually used, and reviewed in Chapter 4 — through Copilot code review directly, or through that chapter's manual-review fallback if code review was not available to you there (recorded on Chapter 4's Path B); and assembled context/prompting practice, including a context inventory and composed prompt for the project's next change (Chapter 6). It also carries one of Chapter 5's three recorded MCP outcomes:

  • Attached and observed — an MCP server attached and exercised on both the interactive and an unattended surface, with its approval-behavior contrast observed.
  • Attached and reasoned — an MCP server attached only on the interactive surface, with the cloud agent recorded as blocked in Chapter 3 and code review not available to you (recorded on Chapter 4's Path B), and the approval contrast reasoned rather than observed.
  • Blocked — if Chapter 5's organization-policy check wasn't satisfied, a recorded MCP access-blocked state with no server attached.

Check your own Chapter 4 and Chapter 5 notes for which states apply before starting this chapter's activities.

What this chapter adds. Chapter 8 runs one final, learner-scoped, realistic end-to-end change through the full workflow in sequence:

  • Activity 1 scopes the exact change every later activity in this chapter builds on, optionally starting from the context inventory and prompt Chapter 6 already produced if that artifact still fits.
  • Activity 2 produces the context notes, draft prompt, and validation-check plan used to implement it.
  • Activity 3 implements or delegates the change and, regardless of which surface was used, finishes with a pull request containing it — opened by the learner after a local Agent mode branch, or reused directly from the cloud agent — plus a note correctly attributing the MCP tool-approval behavior to your recorded Chapter 5 MCP state.
  • Activity 4 closes the review loop on that same pull request — first confirming Copilot code review is actually available on the learner's live plan (recapping Chapter 4's own eligibility check and its manual-review fallback when code review isn't available), then addressing or dismissing every Copilot code review comment or manual-review observation with a rationale.
  • Activity 5 serves as the final validation gate: the change is judged complete only once the project's own tests/linting/CI pass, confirmed against the plan stated in Activity 2.
  • Activity 6 produces the concluding synthesis artifact for the reference project's course-long thread, tying the Chapter 2 plan decision — both the provisional team recommendation and the live plan that actually determined cloud-agent eligibility — (and, where applicable, the Chapter 3 admin-gated eligibility) and the Chapter 6 prompting/context habit back into this one exercise.

Ending state. The reference project carries one additional, reviewed, and engineering-check-validated change — with implementation and review converged onto a single pull request regardless of implementation surface, MCP availability, or code-review availability — plus a learner-authored synthesis reflection tying the course's plan, prompting, agent, review, and MCP decisions together into a single supervised, validated agentic workflow: the final state of the reference project for this course.

Sources