You hire a robot builder to renovate your kitchen. It never knocks down the real wall. It builds a copy on a spare section, posts photos to a review board, and nothing becomes permanent until the site office stamps it.
That discipline — propose, don't impose — is the whole lesson. Now the actual GitHub mechanics.
An agent leaves a trail of artifacts
When a Copilot agent does a job, it doesn't hand you a result out of nowhere. It produces the same GitHub objects a human developer would, in order:
- Issue — the job, written down. You assign it by mentioning
@copilotin an issue or comment, or via the agents panel. The Issue is the intent: "fix the expired-token crash inauth.ts." - Branch — the agent works on a copy (e.g.
copilot/fix-auth-token), never directly onmain. - Commits — each step it takes is a saved checkpoint with a message.
- Pull Request — the agent opens a PR with its diff: "here's what I changed, review it."
An artifact is a recorded, openable piece of work — an Issue, branch, commit, pull request, or check result — that you can inspect later.
This is why the clearest sign you're looking at an agent (and not a chatbot) is simple: it opens a pull request from a branch it created. A chatbot only produces text in a chat box. An agent produces artifacts on GitHub that you can click, inspect, and trace back. GitHub's own docs describe the Copilot coding agent the same way — it researches the repo, drafts an implementation plan, and makes changes on a branch; then you review the diff, iterate, and open a pull request when it's ready.
GitHub plays two roles — memorize both terms
These two terms name different jobs:
GitHub permanently stores what was proposed and why. What it holds: the plan, the commits, the pull-request discussion, and the workflow evidence. Six months later you can open the PR and see the agent's full reasoning and history — the work stays inspectable after the fact. One word: visibility.
GitHub also decides what becomes permanent. The agent can propose anything, but merge is gated by required reviews, required status checks, and rulesets / branch protection. Until policy is satisfied, the change cannot reach main. One word: governance.
Two jobs in one platform: GitHub is both the record of what an agent did and the control plane that decides what's allowed to stick. Repositories and pull requests make the work visible; checks, reviews, CODEOWNERS, rulesets, branch protection, and environments make it controllable. Visible and controllable is what makes agent work safe to run.
Our summary · grounded in MS Learn — Foundations of Agentic AI (GitHub as system of record & control plane) · fetched 2026-05-30
The full control menu (unit-4 complete list)
For completeness — the six enforcement points GitHub's control plane offers. You already met most of these in Phase 0; here they are as agent guardrails:
- Pull requests — changes are proposed before merging (makes agent work reviewable).
- Required reviews — a human/agent approval gate (no unreviewed merges).
- Required status checks — CI evidence before merging (turns evaluation into enforceable policy).
- CODEOWNERS — review routing by path (right experts supervise high-impact changes). → lesson 1.5 / Domain 6
- Rulesets / branch protection — centralized branch policy. → Phase 0 lesson 0.9
- Environments — approvals for deployments/secrets. → Phase 0 lesson 0.8
Record vs control — don't mix them up
A common exam trap is blurring these two. Keep them separate:
- System of record answers "what did the agent do, and why?" → it stores.
- Control plane answers "what is allowed to become permanent?" → it gates.
The one line all of Phase A keeps proving: the agent does the work; GitHub decides what becomes permanent.
Common confusions (read these or get them wrong)
- "System of record means GitHub prevents bugs." No — it stores the trail. It makes work inspectable; it doesn't guarantee correctness.
- "The control plane auto-approves agent work." Opposite — it gates. It blocks merge until reviews/checks pass.
- "A chatbot that writes code is an agent." Only if it acts on GitHub. The test is whether it opens a PR from a branch it created, not whether it can type code.
Ticks this lesson done on the home roadmap. Saved in this browser.