Copilot Code Review Reads AGENTS.md Now. Good: Review Policy Belongs in the Repo, Not in Someone's Head

Copilot Code Review Reads AGENTS.md Now. Good: Review Policy Belongs in the Repo, Not in Someone's Head

GitHub Copilot code review learning to read AGENTS.md is not the flashiest AI announcement of the week. Good. The useful agent features rarely are. This one matters because it moves AI review away from generic “looks plausible” commentary and toward something software teams have needed from the start: repo-local policy, versioned with the code, visible to humans, and boring enough to audit.

The changelog is short: Copilot code review now automatically reads repository-level AGENTS.md files and uses relevant instructions from that file when generating review feedback. GitHub also made Copilot easier to request on draft pull requests via the reviewer picker and collapsed some Copilot review timeline events to reduce conversation-tab noise. The UI polish is welcome, but the real product decision is the first one. Review policy belongs in the repo, not in someone’s head and definitely not in a Slack thread from six months ago.

That sounds obvious until you look at how most AI code review fails in practice. Generic review advice is cheap. “Add tests,” “handle errors,” and “consider edge cases” are the review-comment equivalent of lint dust. Useful review comes from knowing the codebase: this package cannot add runtime dependencies; that directory is generated; database migrations require a rollback path; feature flags must use the existing wrapper; auth changes need the security checklist; snapshots are updated through one script because the other one lies. Those rules are often tribal knowledge. Copilot reading AGENTS.md gives teams a place to write them down where both humans and agents can see them.

Version-controlled review instructions beat institutional memory

The broader AGENTS.md signal is already loud. The agentsmd/agents.md repository describes the file as “a simple, open format for guiding coding agents” and has more than 22,000 stars and 1,600 forks. That is not just format enthusiasm. It is developers voting for a lowest-common-denominator instruction layer across Copilot, Claude Code, Gemini, Codex-style agents, and whatever arrives next quarter with a new mascot and the same need for build commands.

GitHub’s implementation matters because Copilot code review is already sitting in the pull request workflow. According to GitHub’s docs, Copilot review comments behave like human review comments, but Copilot always leaves a Comment review — not Approve or Request changes. Its review does not count toward required approvals and does not block merging. That boundary is correct. AI review should increase surface area and catch more issues; it should not satisfy governance by pretending to be accountable.

The obvious practitioner move is to treat AGENTS.md as a review contract, not a documentation attic. Put in the things that should actually change a review comment: build and test commands, directories that should not be edited, security-sensitive paths, dependency rules, migration conventions, generated-file warnings, required fixtures, common failure modes, and examples of what a good PR in this repo does. Leave out the company origin story. Leave out the entire architecture handbook. If a rule cannot plausibly affect Copilot’s review feedback, it probably does not belong in the review path.

This is also where teams should resist the most common agent-instruction failure mode: dumping everything into context because the model once missed something. A sprawling AGENTS.md can make review worse. Agents do not become senior engineers by ingesting a textbook before every comment. They become marginally more useful when the right constraints are small, specific, and close to the code. The file should be edited like production configuration: reviewed, diffed, kept short, and deleted from when guidance stops producing lift.

The repo is becoming the agent control plane

Copilot code review can already use repository custom instructions, path-specific .instructions.md files, agent skills under .github/skills, and configured MCP servers where relevant. GitHub’s docs also note that MCP/tool support for code review is in public preview, with GitHub MCP server and Playwright MCP server enabled by default for configured repositories. Add AGENTS.md to that stack and the pattern is clear: the repository is becoming the control plane for agent behavior.

That is a healthier model than centralizing all agent behavior in a vendor settings page. Repo-local instructions can evolve with the code. They can be reviewed by the team that owns the system. They can be branched, tested, and reverted. Most importantly, they make the agent’s operating assumptions visible. If Copilot gives strange feedback, a maintainer can inspect the instructions it was supposed to be following rather than guessing which invisible product prompt had opinions about their code.

There is a security angle here too. Review instructions are not just style preferences; they can encode blast-radius rules. “Do not suggest direct SQL string construction in this package.” “Any change under billing requires tests for proration and timezone boundaries.” “Do not recommend bypassing the internal auth middleware.” Those are the kinds of constraints a generic model may not infer from code shape alone, especially in large repositories with mixed historical patterns. A concise AGENTS.md gives the reviewer bot a fighting chance to flag the thing the team actually cares about.

The danger is instruction drift. If AGENTS.md says tests run with one command and CI uses another, Copilot will faithfully amplify stale knowledge. If the file says “avoid new dependencies” but the team routinely approves them through ADRs, the bot will create noise. If every subteam appends local lore without pruning, the agent gets conflicting policy. Treat the file like any other interface: ownership, tests where possible, and periodic cleanup. Bad instructions are worse than no instructions because they produce confident, repo-flavored wrongness.

Engineering managers should also be clear about what this feature does not do. It does not make Copilot a required reviewer. It does not replace branch protection. It does not prove a change is safe. The useful workflow is simpler: humans write repo policy into AGENTS.md; Copilot uses it for first-pass review; CI proves behavior; required human reviewers remain accountable; agent-generated fixes go through the same checks as every other change. Vibes still do not get to merge.

The forward-looking take: this is a small feature in the way .editorconfig was small. It gives teams a boring file that nudges tools toward local norms. That boring file can become infrastructure if teams keep it tight. Copilot does not need to become a senior engineer for this to be useful. It just needs to stop reviewing every repository like it has never met the codebase before.

Sources: GitHub Changelog, GitHub Docs, GitHub repository instructions docs, agentsmd/AGENTS.md