Weekly GitHub Copilot Roundup: Governance, Agents, and Models

by TechHub

This week's GitHub Copilot updates center on governance that admins can actually operate: unified policies across chat and cloud agents, clearer seat and usage billing behavior, and GA model controls that affect compliance and cost attribution. On the workflow side, the Copilot app's Customize tab is now the place to standardize MCP servers, plugins, and shared tools, while shared agent sessions in Slack and Microsoft Teams push Copilot work into auditable team spaces. Code review expands eligibility (including bot and cloud agent PRs) and adds better lifecycle tracking, and the IDE story keeps evolving with Visual Studio and VS Code adding practical model selection, effort controls, BYOM options, and even persistent agent sessions via Agent Host and AHP.

This Week's Overview

Copilot governance and billing changes admins need to plan for

GitHub announced upcoming changes to Copilot policies and billing that tighten how organizations control (and pay for) Copilot across chat and agent experiences, continuing last week's theme that Copilot administration is becoming steady-state platform governance rather than occasional settings work. The headline change is a unified Copilot Chat and cloud agent experience governed by a single policy, which should reduce “it works here but not there” surprises when teams mix IDE chat, the Copilot app, and cloud agents.

On the cost side, GitHub is updating billing behavior for Business and Enterprise seat assignment and usage, so admins should re-check how seats get allocated and when usage becomes billable. Code review gets a default behavior change too: Copilot code review will default to a new “Balanced” effort level, which is meant to standardize review depth unless you explicitly choose otherwise.

Model governance also moved forward with global model policy reaching general availability, with enforcement rolling out through September 1, which fits the model-picker churn and per-model cost attribution focus we covered last week. If you have not configured model states, unconfigured models inherit the default policy state, and GitHub clarified that open-weight and certain data-retention models are not enabled by default, which matters for compliance and data handling expectations in regulated orgs.

Copilot app and collaboration: customization, plugins, and shared agent sessions

This week connected a few threads: Copilot is getting easier to customize, and those custom agents are showing up in more places where teams already work (chat and work tracking), building on last week's push to make the Copilot app a sustained workflow surface rather than a side chat client. The common theme is making “agent + tools + context” something you can share and reuse across workflows instead of rebuilding per developer.

Customize tab GA in the Copilot app

The Copilot app's Customize tab is now generally available, consolidating MCP servers, plugins, skills, and canvases in one place, which pairs neatly with last week's GA of Agent Plugins 1.0 by giving teams a clearer “home” for standardizing shared tools. Practically, this is where teams can standardize on a known set of tools and prompts (for example, a shared MCP server for internal docs grounding) and make them discoverable without a wiki page of setup steps.

GitHub is also leaning into discovery features like featured and trending MCP servers, which hints at a marketplace-style workflow for agent capabilities. If your org cares about consistency, treat Customize as the “source of truth” and pair it with policy controls so developers can add useful tools without introducing unreviewed integrations.

Slack and Microsoft Teams shared agent sessions

Copilot added shared agent sessions in Slack and Microsoft Teams, pushing Copilot closer to a ChatOps model where the “work” is visible to more of the team, which extends last week's thread about making agent work more reviewable and less trapped inside a single developer's IDE session. Shared sessions matter because they reduce duplicated effort (one person explores, everyone sees the outcome) and create an auditable conversation trail when an agent is used to make decisions or propose changes.

If you are adopting this, plan for guardrails: decide what channels can host agent sessions, what data sources those agents can access, and whether outputs should be pasted back into issues/PRs for recordkeeping. This is especially relevant now that Copilot policies are converging across chat and cloud agents.

Azure DevOps plugin inside the Copilot app

Microsoft shipped an early-stage Azure DevOps plugin for the Copilot app that can view and manage Azure Boards work items and Azure DevOps pull requests from within Copilot, building on last week's theme of Copilot acting as the front-end for a governed toolchain via plugins and MCP-connected tools. For teams split between GitHub and Azure DevOps, this is a straightforward way to bring work tracking context into Copilot conversations without constantly switching tabs.

Because it is positioned as early-stage, expect gaps and treat it like an integration you validate with real team scenarios (triage, status checks, PR review routing). Use the documented feedback channels (comments and GitHub issues) if you hit workflow blockers, since the plugin is likely to evolve quickly based on usage patterns.

Copilot code review expands coverage across GitHub and Azure Repos

Copilot code review updates this week made it more applicable to real repositories with messy histories, large change sets, and automation-generated pull requests, following last week's emphasis on “agents propose, PRs decide” with guardrails that make automation safe to adopt broadly. The key shift is broader eligibility and better lifecycle controls, which should make it easier to standardize review automation without carving out special cases.

On GitHub, Copilot code review now supports full reviews for bot-authored pull requests and for Copilot cloud agent pull requests, and GitHub removed prior large-PR limits. Maintainers also get new “resolution reason” options when resolving Copilot review comments, which helps teams track why suggestions were accepted or dismissed (useful for training, compliance notes, or simply reducing repeat noise).

Azure DevOps users got a separate jump: Copilot Code Review for Azure Repos entered public preview with expanded enablement scopes, support for Managed DevOps Pools, custom instructions, and automatic reviews via branch policies. Microsoft also called out better cost attribution through Azure Cost Management, which matters if you need to split usage across teams or projects rather than treat reviews as an undifferentiated platform expense.

Model choice, effort controls, and BYOM land in Visual Studio and beyond

Teams are getting more levers to control which models Copilot uses and how “hard” it thinks, and those levers are showing up in the IDEs where developers spend their day, continuing last week's thread that model selection and per-model behavior is now a normal operational concern. The practical takeaway is that Copilot setup is no longer just “turn it on” - you can shape behavior per org, per scenario, and (in some cases) per model provider.

Visual Studio 2026: org-level agents, model management, and a Git agent

The Visual Studio 2026 August update adds organization-level custom agents, improved usage visibility, and model management controls that include “thinking effort” settings, which builds directly on last week's Visual Studio focus on local-model tuning knobs and hybrid setups. That combination is aimed at real enterprise rollouts: admins want visibility and guardrails, while developers want predictable behavior when switching between chat, agent mode, and review.

Visual Studio also introduced a Git agent that can review changes and commits before a pull request, effectively inserting Copilot earlier in the quality loop. Used well, this can reduce churn during PR review by catching inconsistencies (tests not updated, missing docs, style issues) before changes leave the branch.

Visual Studio 18.10 Insiders: Bring Your Own Model (BYOM) preview

Microsoft also announced a BYOM preview in Visual Studio 18.10 Insiders that lets Visual Studio Agent mode connect to Microsoft Foundry/Azure AI Foundry deployments or supported third-party providers like OpenAI, Anthropic, and Ollama, extending last week's Ollama BYOK/BYOK-provider theme from JetBrains and SDK experiments into a first-party Visual Studio workflow. Support includes custom endpoints for OpenAI and Ollama, which is important for self-hosted gateways, proxying, or local-model experimentation.

For teams evaluating model portability, BYOM changes the procurement and compliance conversation: you can use Copilot tooling while routing inference through an approved provider and endpoint. It also raises new operational questions (credential distribution, endpoint reliability, rate limits, logging, and data retention), so treat this like a platform integration, not just an IDE toggle.

VS Code: hands-on model selection UX

VS Code highlighted model management UI that lets you show, hide, and pin models, covering Copilot-provided models, local models, and bring-your-own-key (BYOK) providers, which is a practical complement to last week's “model picker gets crowded” reality and the need to keep model choice reproducible. This matters when your team wants to standardize on a small set of approved models but still allow power users to keep a local model pinned for specific tasks.

If you are rolling this out across teams, pair UX guidance (what to pin for daily work vs specialized tasks) with policy configuration (global model policy, allowed providers, and data handling constraints). Otherwise, model sprawl can show up as inconsistent results and hard-to-reproduce behavior during reviews or pair sessions.

Persistent agent sessions: VS Code Agent Host and the Agent Host Protocol (AHP)

VS Code introduced Agent Host and the open Agent Host Protocol (AHP) to make agent sessions persistent, synchronized across VS Code surfaces, and portable across local and remote clients, extending last week's IDE-agent direction where parallel worktrees made multi-session work practical but still left continuity as a missing piece. The key architectural idea is a state-first protocol model, which shifts agent work from “ephemeral chat log” toward a shared session state that different clients can render and continue.

For developers building custom tooling, AHP is the interesting part: Microsoft published libraries to help you build your own AHP clients, so you can connect alternative UIs or remote surfaces while keeping session continuity. For teams adopting Copilot agents, persistent sessions should reduce the friction of switching machines, moving from local to remote dev environments, or continuing an investigation across days without losing context.

MCP and agent plugins: expanding what Copilot can safely do with your systems

This week's MCP (Model Context Protocol) updates were less about prompts and more about wiring agents into real systems with clearer boundaries, which continues last week's focus on making MCP setup and server design safer and more repeatable. The pattern across posts and case studies is consistent: use MCP servers and plugins to give agents scoped tools (docs grounding, cost queries, work item updates) and then validate outputs via automation and review loops.

Uno Platform shared a concrete pattern for higher-trust agent work in cross-platform .NET apps by running two C# MCP servers: one for documentation grounding and one to drive a live app for verification. They combined this with tooling like Roslyn, Hot Reload, and UI automation so the agent can propose changes and then confirm behavior, which is a useful template if you are trying to move from “Copilot suggests code” to “agent changes code with checks.”

On the operations side, Azure Resource Manager's MCP server gained Azure Cost Management capabilities with default cost/pricing tools and an optional CostManagement toolset. The post includes setup steps for enabling the toolset in GitHub Copilot Chat (VS Code) and Copilot CLI, enabling scenarios like AKS cost analysis through a conversational workflow that still maps back to concrete ARM tooling.

Copilot CLI and enterprise-managed settings: small defaults with real rollout impact

Copilot CLI updates focused on day-to-day ergonomics: new defaults and session restore make the CLI feel less disposable and more like a persistent assistant you can return to, which aligns with last week's expansion of Copilot CLI support in enterprise environments (including disconnected GHES scenarios) where the terminal often becomes the most reliable surface. If your team uses Copilot in terminals for repo exploration, scaffolding, or quick refactors, session restore can reduce repeated context-building (re-explaining the repo layout, commands, and constraints).

Admins also got a practical improvement in enterprise-managed settings: you can enable automatic updates for specific plugin marketplaces by setting autoUpdate: true on extraKnownMarketplaces, while still requiring the marketplace to be allowed via strictKnownMarketplaces. This is a useful compromise if you want plugins to stay patched without opening the door to arbitrary sources, but it does mean you should monitor plugin changes as part of your standard change management process.

Other GitHub Copilot News

Maintainers are still adapting to AI-amplified contribution volume, and the OpenClaw story focused on practical levers: refresh trust and review signals, reduce supply chain risk, and keep agent capabilities safe by default, echoing last week's point that process and guardrails matter as much as the assistant itself. It is a reminder that Copilot-assisted workflows shift the shape of inbound changes, so projects may need to adjust policies (required reviews, provenance expectations, automation checks) as much as they adjust tooling.

Several sessions and interviews reinforced the longer arc behind these weekly updates. Amanda Silver's reflections on VS Code highlighted how the editor's open-source, extension-driven architecture made it possible for AI tooling to move quickly, while conference content from VSLive! emphasized Copilot's spread across the full workflow (not just code completion) alongside .NET modernization topics.

Finally, a Copilot Studio billing change goes live September 1, 2026: existing GitHub Copilot harness agents and workflows created before August 3 will start consuming Copilot Credits. The author breaks down authoring vs runtime credit consumption and points admins to the Power Platform admin center (PPAC) for usage review and cost controls, so it is worth validating budgets before the cutoff.