Weekly GitHub Copilot Roundup: Reviews, Agents, Models, Governance

by TechHub

This week's GitHub Copilot updates tightened the feedback loop from pull request review to merge, with a refreshed review experience that tracks findings across pushes and makes resolution behavior easier to understand. On the governance side, admins got new levers for model lifecycle planning (including mid-October deprecations), Auto model selection tiers, and a cleaner workflow for budget increase requests. Agent workflows continued to expand across the Copilot app, VS Code, and the CLI, with more emphasis on portable sessions, safer tool calling via MCP, and stronger measurement through new usage and engagement breakdowns. Under the hood, deep dives on the Rust runtime migration and the new Inline Suggestions model show how GitHub is making agentic changes faster to run and easier to review.

This Week's Overview

Copilot in the pull request loop: code review UX and agent-generated changes

Building on last week's shift toward treating Copilot review as part of branch protection and approval governance, GitHub Copilot code review shipped generally available improvements that make it easier to iterate on feedback across multiple pushes. The refreshed PR overview now tracks findings across review iterations, so you can see what changed, what is still open, and what was rechecked as the diff evolves.

Auto-resolution behavior got more explicit, with clear resolution reasons instead of silently clearing items, which should reduce “why did that comment disappear?” moments during fast-moving reviews. Copilot can also generate smart commit titles and descriptions for eligible batches of accepted suggestions, tightening the loop between AI-proposed changes and clean git history.

Model choice, cost controls, and upcoming model removals

This week connected three threads that teams have to manage together: which models are available, how Copilot chooses models by default, and what happens when usage hits budget limits, extending last week's message that model choice is now as much an admin and billing decision as a developer preference. If you are rolling out Copilot broadly, these changes land in the admin and governance surface area as much as in the IDE.

Mid-October model deprecations and policy-driven replacements

Following last week's deprecation announcements and guidance on avoiding surprise removals, GitHub Copilot will deprecate several selectable models on October 19, 2026, with recommended replacement models called out in the changelog. For Copilot Business and Enterprise, admins can pre-enable the alternatives using model policies in Copilot settings, which is the practical way to avoid workflow disruption when developers use the model selector in Copilot Chat.

The key operational task is to audit which teams are pinned to soon-to-be-deprecated models and switch policies early, especially if you have internal guidance that depends on specific model behavior (for example, stricter formatting or different tool-calling reliability). Treat this like any other dependency change: update documentation, validate on a representative set of repos, and ensure policy changes are communicated before the cutoff date.

Auto model selection tiers: efficiency, balance, intelligence

As anticipated from last week's focus on multi-model routing (including HydraFusion), Copilot Auto model selection now supports explicit tiers (efficiency, balance, intelligence) so users can choose how Auto trades off cost, latency, and response quality per prompt. Billing still reflects whichever model Auto selects, and GitHub notes a 10% discount for paid subscribers on Auto-billed usage, which matters if your org is nudging developers toward Auto as the default.

In practice, these tiers create a new knob for teams to standardize on per workflow: “efficiency” for quick Q&A and low-risk edits, “intelligence” for heavier refactors or multi-file reasoning, and “balance” as the default. If you manage policies centrally, this is also a lever to keep spending predictable without forcing developers to manually pick models.

Budget increase requests (GA) for usage-based billing

Building on last week's expansion of budget controls (including budget expirations for temporary overrides), Copilot budget increase requests are now generally available, allowing members to request additional AI credit budget when they hit limits. Org or enterprise billing admins can approve, adjust, or deny these requests from settings, which gives you a structured way to handle “I hit the cap mid-sprint” without ad-hoc workarounds.

This pairs naturally with Auto model selection: teams can set cost-conscious defaults, then let developers request more budget when the work justifies it (for example, large migration PRs or test-generation pushes). If you already track Copilot adoption, you can also use request volume as a signal that policies are too strict for real workloads.

Copilot agents across tools: sessions, workflows, and guided app delivery

This week had a clear theme of Copilot working as a connected agent across surfaces (Copilot app, VS Code, terminal/CLI), continuing last week's push to make agent sessions more reviewable and portable across tools. The practical shift is that “agent work” is no longer a single chat thread; it is becoming a portable unit of work that can move between environments while keeping context and diffs intact.

Copilot Day workflow: connected sessions, issue triage, and Agent Merge

Building on last week's HydraFusion coverage and VS Code agent session UX improvements, in the “Dream it, Build it, Ship it!” Copilot Day session, James Montemagno and Pierce Boggan walked through building, testing, and shipping apps using Copilot across Slack, the Copilot app, VS Code, and the terminal. The demo leaned on connected sessions, live previews, issue triage, and PR workflows that culminate in Agent Merge, framing agents as something that can carry a task from intake to merge rather than stopping at code suggestions.

The same session introduced HydraFusion as an automatic model and workflow selection system that tries to balance quality, cost, and speed. That matters if you want agentic workflows to be “always on” without forcing developers to think about model strategy for every step.

Continuing Copilot app sessions in VS Code (handoff + isolated worktrees)

After last week's guidance on running multiple Copilot app agents in parallel using separate Git worktrees, GitHub also documented how to continue an active Copilot app session inside VS Code while preserving the task plan, conversation history, and diff. The handoff uses an isolated git worktree, which keeps the agent's working copy separate and reduces the risk of tangling with whatever state is in your main checkout.

If your team is experimenting with cloud agents, this pattern is worth standardizing: let the agent produce a coherent plan and initial patch, then hand off into VS Code for interactive review, debugging, and final polishing before pushing back to the PR. The worktree detail is not cosmetic; it is what makes this workflow safe to repeat without constantly cleaning up local state.

VS Code 1.138: shareable automations, Dev Containers agent sessions, and Voice Mode awareness

Continuing last week's theme of VS Code making Copilot feel more like first-class tooling (not just chat), a VS Code 1.138 update roundup called out Copilot-related changes aimed at making agent workflows easier to reuse and more robust in real environments. Shareable automations suggest a path toward codifying “how we use Copilot here” as artifacts you can pass around, not just tribal knowledge.

Running agent sessions inside local Dev Containers is a practical upgrade for teams with non-trivial toolchains, because it puts the agent in the same containerized environment as your build/test commands. Voice Mode session awareness also improves continuity, which matters when the same task hops between chat, voice, and edits.

Guided Copilot experience for building Azure apps in VS Code (preview)

This continues last week's “agent ships” thread (for example, workflows that move from suggested changes into controlled deployments) by adding structure around the scaffolding-to-deploy path: Microsoft previewed a guided Copilot experience in VS Code that adds structured stages for scaffolding, local setup, and deployment to Azure. It ties into az and azd (Azure Developer CLI), and includes resource summaries and cost estimates, which makes the “plan → provision → deploy” path more transparent than a generic chat-driven flow.

For developers, this is a step toward Copilot acting like a task runner that understands deployment mechanics and not just code. For teams, the resource summary and cost estimate angle matters because it helps keep experimentation from turning into surprise spend, especially when Copilot is generating infrastructure as code alongside app code.

Under the hood: Copilot runtime moves to Rust (and what agentic migration looks like in practice)

Two writeups covered the same core shift: GitHub rewrote the Copilot agent runtime from TypeScript/Node.js/V8 to a 100% Rust implementation, which adds a concrete engineering case study to last week's broader focus on harnesses, orchestration, and the runtime mechanics behind agent execution. Stephen Toub's deep dive explains the incremental strategy, including interoperability during the transition (N-API plus a C ABI/FFI boundary), JSON-RPC-based interactions, and the testing approach needed to keep behavioral drift under control.

The interesting developer takeaway is not just “Rust is faster,” but how to structure a large language model (LLM)-assisted port so you can ship continuously without betting everything on a big-bang rewrite. The post calls out common regression patterns and why end-to-end testing and careful parity checks matter, especially when LLM output “compiles” but subtly changes behavior.

DevClass added concrete operational details like reported token costs (framed as $120K), release cadence, and benchmarked performance and memory gains, while emphasizing the limits of using compile success as a proxy for correctness in Rust. If you are considering agent-assisted migration, this pair of articles reads like a checklist of what you need: a staged plan, explicit interop seams, performance benchmarks, and a realistic approach to regression management.

Inline Suggestions model: one model output format for completions, NES, and edits

GitHub and the VS Code team published “Part One” of how the new Copilot Inline Suggestions model was built, focusing on unifying classic completions, Next Edit Suggestions (NES), and long-distance edits into a single modeling approach, which complements last week's theme of making multi-step agent work more reviewable by producing changes in a format that is easier to inspect and apply. The core technical move is a diff-patch output format, so the model can propose edits as patches rather than only as inserted text.

They also described the training and evaluation pipeline, including pseudo-online evaluation (POE) and a mix of supervised fine-tuning (SFT) and reinforcement learning (RL) to ship the “2-in-1” phase. For developers, the practical implication is that inline assistance should increasingly handle “edit this existing code over there” workflows without switching mental modes between completion and refactor tools.

MCP and tool governance: securing servers and tracking agent customization

As Copilot becomes more tool-driven, MCP (Model Context Protocol) keeps showing up as the integration layer that connects agents to internal systems, extending last week's MCP onboarding and “make tool use governable” thread into concrete hosting and measurement guidance. This week, the most actionable work was around how to host MCP endpoints safely and how to measure which customizations developers actually use.

Running MCP servers securely: gateway vs API Management patterns

Rob Bos laid out the security and governance risks of running MCP servers for Copilot, then compared two common hosting patterns. One is centralizing an MCP Gateway in containers or Kubernetes, the other is fronting MCP endpoints with Azure API Management and using Azure API Center as a private registry.

The analysis highlights practical gaps that teams should plan for, especially around per-user OAuth and session-aware routing, which become critical when an agent is acting on behalf of an individual developer with specific permissions. If you are deploying MCP internally, this is a reminder to treat it like any other API platform: identity, authorization boundaries, routing, auditing, and a registry/discovery story all need to be real before you scale usage.

MCP Live resources and spec updates

Following last week's run of MCP tutorials and connector setup, Pamela Fox curated recordings and resources from MCP Live, covering spec updates (including the 2026-07-28 MCP specification), building MCP servers and clients in VS Code and GitHub, and Microsoft Foundry Toolboxes for enterprise governance. There are also deep dives into MCP authorization and event-driven agent patterns, which are the parts most teams will stumble on once they go beyond toy integrations.

If you are standardizing tool calling for Copilot across an org, the value here is in comparing patterns early: how you authorize tools, how you publish and discover servers, and how you structure events and callbacks so agents do not poll blindly or overreach their permissions.

Usage metrics API adds agentic CLI customization reporting

This builds directly on last week's push toward repeatable agent runs (skills/plugins and CLI workflows) by adding visibility into what is actually being used: GitHub added new Copilot usage metrics API fields to report agentic Copilot CLI activity, including skills, custom agents, MCP servers, slash commands, and plugins. The update also clarifies how interaction counts and distinct-use counts are calculated, which matters if you are building internal dashboards and do not want misleading adoption numbers.

This makes it easier to answer practical questions like “Are people using our internal MCP tools?” and “Which custom agents are actually used after enablement?” If you are piloting agentic workflows, instrumenting these metrics early helps you separate novelty from sustained usage and identify where docs or permissions are blocking adoption.

Measuring and governing Copilot adoption: engagement breakdowns and metadata suggestions

Two admin-oriented updates focused on making Copilot usage easier to quantify and governance metadata easier to standardize, continuing last week's pattern of tightening governance around models, budgets, and agent behavior. The shared theme is reducing guesswork for platform teams that need to report “what changed” after enabling features or rolling out policies.

Impact dashboard adds feature engagement breakdowns

Copilot's impact dashboard and usage metrics REST APIs now include 28-day feature engagement breakdowns, including totals by feature. AI adoption phase reporting also improved via a rolling 28-day phase population field (users_in_phase_28d), which is a more stable signal than point-in-time snapshots.

For orgs that run enablement programs, this gives you a way to see whether adoption is happening in the features you care about (for example, code review, CLI, or chat) and not just overall “Copilot active users.” It also supports more targeted training: if feature engagement is flat, you can focus on the workflows that are not sticking.

Copilot suggests repository custom property definitions (public preview)

In a public preview, Copilot can now suggest allowed values when enterprise and organization admins create repository custom property definitions, which complements last week's focus on policy-driven controls by making the metadata those policies often depend on easier to standardize. Since custom properties often feed rulesets and governance workflows, better consistency in allowed values reduces the “near-duplicate metadata” problem (for example, “prod”, “production”, “Production”) that makes policy scoping brittle.

If you use custom properties to drive rulesets, compliance checks, or deployment gates, this feature is a small but practical quality-of-life improvement. It helps keep the taxonomy clean at the point of creation, which is cheaper than cleaning it up later across hundreds of repos.

Building and operating with Copilot agents: readiness, skills, testing, and real debugging

This week's long-form content was heavy on the “how do we make agents reliable?” question, which follows last week's emphasis on making agent execution reviewable (sessions, harness patterns, and governance) by pushing the responsibility into repo conventions, tests, and observable workflows. The common thread is that better outcomes come from constraints (instructions, tooling, tests, and observability), not from hoping the model guesses your intent.

Repo readiness for agents: checklists, scorecards, and least-privilege workflows

Hidde de Smet published a six-gate checklist and a 20-point scorecard for assessing whether a repository is ready for AI coding agents, using GitHub Copilot cloud agent as the reference. The guidance is concrete: make bootstrap repeatable, centralize shared commands, keep tests focused, enforce expectations via CI and GitHub Rulesets, and apply least-privilege controls for secrets and MCP usage.

The suggested artifacts (like AGENTS.md and .github/copilot-instructions.md) help turn “prompting style” into repo-level conventions that survive team turnover. If your agent results feel inconsistent across repos, this framing explains why: the repo is part of the agent system, and uneven tooling and instructions produce uneven outcomes.

Reusable “agent skills” for more consistent outcomes

This reinforces last week's theme of turning agent behavior into repeatable building blocks (skills/plugins and harnessed workflows) by showing what that looks like in practice: Matt Pocock shared a Copilot Day talk centered on a reusable set of “Agent Skills” to make AI coding agent results more consistent. Examples include aligning changes with documentation, generating visual pull requests, and pulling architectural review earlier so you catch design mistakes before they become large diffs.

The practical value is in treating prompts as assets: name them, reuse them, and evolve them as you learn what works for your codebase. Teams that standardize a handful of skills usually get more predictable outputs than teams that rely on ad-hoc prompting per developer.

Using Copilot to improve test coverage (Test Agent workflow)

Aaron Powell walked through improving unit test coverage in Visual Studio by first baselining coverage, then using Copilot's Test Agent to generate tests for a class and expand to the solution level. The key workflow detail is the iterative loop: measure, generate, run, and then adjust tests to match real behavior rather than accepting generated tests blindly.

For teams trying to make agent changes safer, this is one of the most direct payoffs: agents can produce a lot of code, so having a repeatable test-generation and validation routine helps keep review load manageable. It also encourages coverage improvements as a first-class step in refactors rather than an afterthought.

Debugging and performance work with AI assistance: PSScriptAnalyzer case study

Jesse Houwing documented diagnosing intermittent PSScriptAnalyzer crashes in GitHub Actions, tracing the issue to concurrent PowerShell command discovery (Get-Command) across runspaces. He used benchmarking and targeted fixes to make analysis deterministic and much faster on cold runs, with supporting evidence in PR #2206.

The Copilot angle is that AI assistance can help explore hypotheses and draft fixes, but the real work still depends on reproducible benchmarks and careful reasoning about concurrency. It is a useful template for “agent + engineer” debugging: use the model to accelerate exploration, then rely on measurement to prove the fix.

Copilot SDK and agent apps in .NET: tool calling, handoffs, and hosted agent customization

This continues last week's Copilot SDK momentum (custom tools via MCP and repeatable agent runs) by moving from introductions into concrete sample architecture and inspection workflows. The Copilot SDK story continues to mature into a practical way to build domain agents that run on the Copilot CLI runtime, call tools via MCP, and coordinate multi-agent workflows. This week's items focused on a concrete .NET sample app and on how hosted agents can be customized and inspected.

“Interview Coach” sample: Copilot SDK + Microsoft Agent Framework + MCP

Justin Yoo published a tutorial for an “Interview Coach” .NET sample that uses the GitHub Copilot SDK to run an agent-driven interview workflow with custom tool calling and MCP-backed services, plus Microsoft Agent Framework handoffs. The post gets into the parts developers actually need: scoping tools, merging run-time handoff tools, and running locally with Aspire and the Cosmos DB emulator (with an optional Azure AI Foundry path).

A companion community standup video covers the same app evolution and architecture, including a Blazor UI and MCP tools. If you are evaluating the Copilot SDK for internal assistants, this is a good reference for end-to-end structure: UI + agent runtime + tools + data store, with clear boundaries for what the agent is allowed to call.

Customizing hosted agents with Foundry Canvas and validating with Agent Inspector

Two Microsoft Developer videos demonstrated customizing a hosted agent from the Copilot Chat window using Foundry Canvas, including best-practice checks, Copilot-generated fixes, observability upgrades, and testing with Agent Inspector. A related session shows using a Foundry skill to review and refactor an existing agent (“an agent that refactors your agent”), then validating the refactor through Agent Inspector and improved telemetry.

The core developer takeaway is the workflow: define expectations, refactor with guardrails, then verify behavior with inspection and instrumentation rather than trusting the prompt. If you are building agents that will touch production systems through MCP tools, having a repeatable “inspect and observe” loop is as important as the agent logic itself.

Other GitHub Copilot News

A couple of items this week focused on cost optimization and bringing operational context into agent workflows, extending last week's HydraFusion storyline from research preview and CLI experiments into more public evaluation and cost-comparison demos. HydraFusion was presented as a way to reduce frontier-model costs by composing multiple models per request, with evaluation via Checkpoint Bench and a cost comparison demo. In a separate operations-focused post, Azure SRE Agent treated Grafana dashboards as executable context via an Azure Managed Grafana MCP endpoint, using KQL and Application Insights telemetry (including Copilot telemetry) to derive per-session diagnoses from tracing data.