GitHub puts Copilot code review on an agentic architecture and broadens GA

GitHub announced on March 5, 2026 that Copilot code review now runs on an agentic tool-calling architecture and is generally available for Copilot Pro, Pro+, Business, and Enterprise. The practical change is that the review agent no longer has to look at a pull request diff in isolation. It can gather broader repository context as needed, including relevant files, directory structure, and references, before it comments.

GitHub frames that context retrieval as a quality upgrade, not just a feature expansion. In the changelog post, the company says the new architecture should improve correctness and architectural integrity, lower review noise, and make comments more actionable. That distinction matters because AI review products usually fail in one of two ways: they either miss important issues, or they produce so many shallow comments that teams stop trusting them.

• General availability covers Copilot Pro, Copilot Pro+, Copilot Business, and Copilot Enterprise.
• Agentic Copilot code review runs on GitHub Actions.
• Teams that opted out of GitHub-hosted runners need a one-time self-hosted runner setup.

GitHub published supporting operational data in a companion blog post on the same day. The company said Copilot code review usage has grown 10X since its initial launch last April and now accounts for more than one in five code reviews on GitHub. GitHub also said 71% of reviews surface actionable feedback, while 29% intentionally stay silent rather than emit low-signal comments. That suggests the team is tuning for signal over blanket coverage, which is usually the right tradeoff in production review workflows.

For engineering teams, the broader implication is that Copilot review is moving closer to an automated reviewer that can reason across a repository instead of acting like an inline lint pass with nicer wording. As AI-assisted code generation increases the volume and velocity of pull requests, repository-aware review becomes more important because maintainability problems often live in context, not in a single changed line.

The open question is whether this higher-context mode keeps false positives under control at scale. Still, GitHub’s own framing is notable: success is not “more comments,” but more trustworthy comments that help teams merge with confidence. That places the product on a more credible path than pure review-volume optimization. GitHub’s deeper discussion of the rollout is available in its companion blog post.