Copilot in Visual Studio gets org-wide agents and a thinking-effort dial

GitHub shipped its August update for Copilot in Visual Studio on August 28, and the theme running through it is control: who publishes agents, how hard the model thinks, and which models are even visible in the picker. It applies to Visual Studio 2026 and reaches every Copilot plan, from Free and Student through Pro, Pro+, Max, Business and Enterprise.

Agents published once for the whole organization

Organization and enterprise owners can now publish custom agents for use across the repositories in their organization. Visual Studio detects them on its own and shows both the description and the organization they came from in the agent picker, so a developer can tell a team agent from a local one without asking.

The requirement is a GitHub organization, which is the quiet part of this feature. An agent that lived in one repository's configuration had to be copied to spread; an agent published at the organization level arrives wherever the organization does.

A dial for how hard the model thinks

Supported models now take a thinking effort setting with three positions: Low, Medium and High. GitHub frames it as a trade between reasoning depth and token usage, with low effort for straightforward work and high effort for debugging, algorithms and architecture decisions.

Model management got the same treatment. You can pin the models you actually use, collapse the ones you do not, and open Manage models for a view that lists capabilities, context window sizes and cost, for Copilot models and custom ones together. Alongside it, View all Copilot usage in the prompt box shows your plan details, and the limit notifications now say what your options are as you approach one.

A review pass before the pull request

The Git agent will now review uncommitted changes or specific commits on request. Findings appear inline in the editor with a navigable list in Git Changes, and the Copilot Chat conversation stays open so you can ask why a finding was raised or have it addressed.

This works against GitHub and Azure DevOps repositories, which matters more than it sounds: it moves the review from the pull request, where it is public and late, to the working tree, where it is private and cheap to act on.