Back to the build site from Phase 0 — the house you've been putting up.
One morning a new worker shows up on the crew. Nobody's seen them before. Do you let them frame a wall?
The wrong move is to react to who they are. One foreman shrugs: "New kid, probably useless — I'm redoing everything they touch." The other waves them through: "Fancy nail gun, must know what they're doing — ship it." Both foremen are wrong, in opposite directions. One wastes the worker; the other invites a collapsed wall.
The right foreman doesn't care who the worker is. They care whether the work passes. Same building code. Same inspections. Same sign-off. If the wall is plumb and to code, it stays. If not, it's rejected — not because a stranger built it, but because it failed the standard everyone is held to.
An AI agent is that new worker. The contributor model is the right foreman's rule: judge the work by the standard, not the author by their novelty.
The idea, in plain English
When an agent finishes a task in GitHub, it doesn't hand you a mysterious black box. It hands you a pull request — the same PR a human would open (lesson 0.4). The contributor model says: treat that PR like any other contribution. Evaluate the work by the standards of the workflow, not by the novelty of the author.
That one sentence kills the two classic mistakes:
- Excessive suspicion — rejecting a change because "AI wrote it." You throw away good work over a label.
- Excessive trust — accepting a change because "automation produced it, it must be fine." You merge a bad change because a robot looked confident.
Treat an agent's output as a contribution, not a special category. A PR is a PR: it must answer the same five questions whether a human or an agent opened it — does it solve the problem, is the scope appropriate and explained, do required checks pass, are the right owners reviewing, does it align with standards/architecture/policy?
This is not a new, AI-specific rulebook. As the module puts it: "This is not a special standard for AI. It's the standard of a healthy engineering workflow applied consistently." The agent is held to the bar your team already has — no lower, no higher.
The six-point review rubric (memorize this)
When you actually review an agent PR, the module gives a concrete six-point rubric. Memorize the six words:
| # | Check | What you're asking |
|---|---|---|
| 1 | Intent | Is there a clear goal and a visible plan? (PLAN.md — the file that states the goal + plan, lesson A0.2) |
| 2 | Scope | Do the changed files match the plan — no more, no less? |
| 3 | Evidence | Do required checks pass? Are logs/artifacts available? |
| 4 | Ownership | Did CODEOWNERS review sensitive areas (when configured)? |
| 5 | Policy | Complies with rulesets / branch rules / environments (when configured)? |
| 6 | Fallback | For high-risk changes, is rollback or escalation clear? |
The same six checks describe a good agent contribution in five words the exam likes: Understandable (clear goal + plan), Bounded (scoped changeset, least privilege), Reviewable (right owners + evidence), Policy-compliant (rulesets/branch rules/environments respected), Reconstructable (audit trail supports post-hoc analysis).
A dependency-fix agent is scoped to implementation only:
- Detects a vulnerable dependency (from a security alert or an issue).
- Creates a branch.
- Updates the dependency and lockfile.
- Opens a PR with a structured plan and the expected success signals.
There the agent's job is done — validation and the merge decision belong to checks, reviews, and policy, not the agent. Now you run the rubric. And if that PR also quietly edits config files, you don't ask only "does it compile" — you ask whether the extra changes are justified, whether checks cover the new risk, whether the right owners reviewed, and whether it aligns with policy.
Why it works: system of record + control plane
The contributor model only holds because GitHub gives you somewhere to do the judging. GitHub plays two roles at once:
- System of record — it stores every artifact work is proposed and evaluated through: repos, branches, commits, PRs, issues, workflow runs, review history. These make agent behavior inspectable after the fact.
- Control plane — when configured by policy, GitHub enforces what a contribution can do: required checks, required reviews, CODEOWNERS, rulesets/branch protection, environments.
Pull requests aren't just collaboration tools — they're enforcement mechanisms. Agents propose work; humans (plus automated gates) decide what's accepted. An agent never pushes straight to a protected branch.
The end-to-end safe pattern, condensed (study guide, verified against the official docs):
task defined → branch → commit → open PR → checks run → CodeQL (a tool that scans code for security bugs) / secret-scan (an automatic check for leaked passwords/keys) / dep-review (a check on new third-party code for known risks) / tests give evidence → humans inspect → branch protection gates merge → audit log preserves the record.
Our summary · grounded in naim149 gist (Tier-2) · verified vs MS Learn ms-d5#2, ms-f4#19 · atoms gist#9, gist#121
CODEOWNERS is the small but exam-favourite piece: it's the GitHub feature that routes reviews by changed file path — touch a sensitive folder, the right owner is pulled in automatically.
- GitHub can require explicit human approval before workflows even run on agent-generated changes — the gate fires before CI spends compute, not just at merge.
- However the agent's work starts — assigned to an issue, or launched from the Agents tab — it all converges on a pull request for review. Same governance model, one funnel.
The cert-language version
Under the contributor model, evaluate agent-generated work by the standards of the workflow, not by the novelty of the author, avoiding both excessive suspicion and excessive trust. A pull request is the unit of contribution; it must answer the same questions regardless of author and is gated by GitHub as both system of record and control plane — checks, reviews, CODEOWNERS, rulesets/branch protection, and environments. Agents propose; humans decide.
Our summary · grounded in MS Learn — Foundations of Agentic AI (units 4–6) + Designing Agent Architecture & SDLC Integration (units 5, 8–9) · fetched 2026-05-31
Common confusions (read these or lose points)
- "Agent PRs need a separate, stricter process." No. Same workflow, same bar — applied consistently. The whole point is no special category.
- "It came from an agent, so be extra suspicious." That's the excessive suspicion error — you reject good work over a label.
- "It came from automation, so it's probably fine." That's the excessive trust error — the more dangerous one.
- "The agent owns its merged change." No — agents propose, they don't own outcomes. Humans decide and own.
- "A PR is just for discussion." No — in an agent architecture the PR is the enforcement point: checks + reviews + rulesets gate the merge.
Ticks this lesson done on the home roadmap. Saved in this browser.