Weekly GitHub Copilot Roundup: Agents in PRs, Models, Controls

by TechHub

This week's Copilot updates continued the shift from “help me write code” to “help me run the workflow,” with more agent work inside pull requests, issues, and project boards. Building on last week's focus on “agents you can operate at scale” (faster starts, configurable validations, traceable logs, and better reporting), this week's changes bring that thread into core GitHub surfaces teams already use: PR comments, issue sidebars, and Projects views. GitHub also expanded model choice (while retiring older models), and Microsoft integrations (SSMS, Azure App Service tooling, Fabric in VS Code) kept positioning Copilot as an embedded assistant where developers already work.

Copilot coding agent in pull requests, issues, and project tracking

After last week's improvements to execution quality (repo-tunable validations and commit-to-session traceability), Copilot's coding agent now fits PR workflows more naturally. You can invoke it on any existing pull request by commenting @copilot with the change you want, and it now updates the current PR by default instead of opening a stacked PR (unless you ask). That keeps common review iterations (fix failing Actions runs, address feedback, add tests) inside the same PR thread and history. It also builds on last week's “Agent-Logs-Url trailer” and clearer session logs: when more work happens in PRs, reviewers need direct links to what ran and why changes were made. Copilot can also handle a frequent review task: merge conflict resolution. You trigger it via comments (for example, “merge in main and resolve the conflicts”), and it works in an isolated cloud dev environment, validates builds, runs tests, and pushes updates back to the PR. Together, “make changes on this PR” plus “resolve conflicts on this PR” shortens the loop for teams that rebase/merge often or maintain long-running branches, especially with last week's validation tuning so “prove it passes” matches the repo's real feedback loop. GitHub also improved planning visibility so agent work is easier to track. When an agent is assigned to an issue, an agent session now appears in the issue sidebar with status (queued/working/waiting for review/completed) plus a link to logs. That signal can also show in GitHub Projects table/board views via “Show agent sessions,” letting teams scan what's in progress vs. waiting on humans. This continues last week's observability push (more actionable logs, live streaming in Raycast): as agents run longer and touch more steps, “where is it and where are the logs?” becomes part of normal workflow hygiene.

Enterprise admin controls and adoption reporting for the coding agent

As more teams enable PR- and issue-driven agents (and now see agent status in Issues/Projects), GitHub is adding admin controls for where agents can operate. In public preview, org owners can manage coding agent repository access using new REST endpoints (apiVersion 2026-03-10), setting it to: enabled for no repos, enabled for all repos, or enabled only for an allowlist (with add/remove endpoints). This matches last week's operational direction (validation “speed vs safety” controls and longer-lived defaults): the coding agent is becoming something you roll out repo-by-repo with automatable, auditable settings. Usage reporting is also more specific, extending last week's push to close reporting gaps (org-level CLI activity and resolving “Auto” into the actual model). Copilot usage metrics now include used_copilot_coding_agent at the user level, so enterprises can separate “used Copilot in an IDE / agent mode” from “triggered the coding agent” (assigning Copilot to an issue or tagging @copilot in a PR comment). For internal dashboards and adoption analysis, this reduces ambiguity and aligns with this week's PR/issue-native invocation patterns.

Model lifecycle and selection: Gemini 3.1 Pro arrives, Gemini 3 Pro exits

Copilot's model picker keeps expanding across clients, following last week's theme of model choice as an admin-governed surface (rollouts, LTS options, clearer attribution). Gemini 3.1 Pro is now in public preview as a selectable chat model across github.com, GitHub Mobile, VS Code, Visual Studio, JetBrains IDEs, Xcode, and Eclipse. For Copilot Business and Enterprise, admins must enable the Gemini 3.1 Pro policy before users see it, which helps teams standardize (or restrict) model choice centrally. At the same time, GitHub deprecated Gemini 3 Pro across Copilot experiences (Chat, inline edits, Ask/Agent/Edit modes, and completions) and points users to Gemini 3.1 Pro. This complements last week's “stable defaults” story: even with LTS models reducing churn, the wider lineup still changes, so teams should review internal docs, defaults, and enterprise policies, especially where policy enablement controls whether the replacement is selectable.

Copilot SDK and Copilot CLI: building blocks for agentic apps and terminal workflows

On the “build with Copilot” side, this week's Copilot SDK coverage moved from an intro to a full end-to-end app example. GitHub published a walkthrough for an AI-backed issue triage app (“IssueCrush”). The key architecture point is that the Copilot SDK depends on Node and manages a local Copilot CLI process via JSON-RPC, so the SDK runs server-side (Node/Express) while a React Native client uses GitHub OAuth + REST APIs to fetch issues. The tutorial emphasizes production-oriented patterns: reuse a long-lived SDK client, manage session lifecycle (start(), createSession(), sendAndWait() with timeouts, disconnect(), stop() in finally), and degrade gracefully when Copilot auth/subscription is missing (HTTP 403 with requiresCopilot, plus a metadata-based fallback summary). This echoes last week's “session forensics” mindset: bound, resume, and reason about agent work instead of treating it as chat output. For terminal workflows, GitHub also highlighted Copilot CLI slash commands: /model to switch models mid-session (useful alongside last week's model attribution and this week's Gemini changes), /context to view token usage and avoid bloated sessions, and /resume to continue a previous session. These fit last week's push for more traceable, inspectable sessions.

MCP-powered “agentic platform engineering”: Copilot beyond coding into CI/CD enforcement and AKS ops

This week's “agentic platform engineering” pattern continues last week's MCP/repo-native workflow progression: moving from “connect Copilot to tools” to “operationalize tool access with repeatable config, enforcement, and audit.” The approach starts by capturing operational knowledge in repos so Copilot can answer “how do I…?” grounded in conventions, IaC modules, and real environments (including reverse-engineering portal-built Azure into Terraform/Bicep). It then moves into enforcement by wiring Copilot-driven checks into GitHub Actions using standardized prompt files (.prompt.md under .github/prompts/) so teams can update rules without rewriting pipeline logic. This matches last week's “repo-visible instructions/skills” and “governed workflow participant” themes. The final stage connects AKS health signals to agent triage. Argo CD detects unhealthy deployments, Argo CD Notifications posts a payload via repository_dispatch, an Actions workflow creates/dedupes structured issues, and a second workflow triggers a custom Copilot agent (“Cluster Doctor”) when a cluster-doctor label is applied. “Cluster Doctor” lives in .github/agents/cluster-doctor.agent.md with a collect->verify->diagnose->triage->remediate flow and safety constraints (verify cluster identity; avoid destructive actions without authorization), and it proposes fixes as PRs with humans approving. That lines up with this week's PR-native agent updates: PR-based remediation is more useful when agents can be invoked and iterated directly in the PR thread. A key enabler is MCP: the repo includes .copilot/mcp-config.json to connect Copilot to a GitHub MCP server (issues/PRs) and an in-cluster AKS MCP server for telemetry and kubectl-based diagnostics, authenticated via Azure Workload Identity Federation. The emphasis is less “autonomous agent” and more “version operational playbooks as prompts/agents, enforce in CI, then turn GitOps signals into human-reviewed remediation PRs,” extending last week's MCP examples (Azure DevOps remote MCP, GitHub secret scanning via MCP, Fabric MCP) into end-to-end platform ops.

Copilot embedded in Microsoft tooling: SSMS GA, Azure App Service profiling fixes, and Fabric + MCP in VS Code

Copilot continued to show up as a first-class feature in Microsoft developer tools, reinforcing last week's theme that customization and tool wiring are becoming portable configuration rather than per-app prompt habits. SSMS 22.4.1 moved “GitHub Copilot in SSMS” from preview to GA, and added support for user-scoped custom instructions at %USERPROFILE%\\copilot-instructions.md so Copilot can stay consistent even for ad-hoc scripts outside a repo/solution. This complements last week's repo-visible instructions/skills: when there is no repo context (or you do not want one), user-level instructions can act as a set of defaults you control. The update also added more export formats (Excel, JSON, XML, Markdown), "Save with Encoding…", broader “group objects by schema” support beyond Fabric SQL databases, plus a new “SQL Projects (Preview)” entry and a roadmap note toward future “Agent mode.” In VS Code, the Azure App Service extension added a “Code Optimizations” workflow that converts Application Insights Profiler findings into “Fix with Copilot” prompts. Items (CPU/memory, impact %, stack traces) appear under “Code Optimizations”; the extension maps stack traces to local methods, opens the code, and seeds Copilot Chat with the recommendation, stack trace, and method source to drive concrete refactors. It targets .NET web apps on App Service, with Windows/Linux differences in profiling enablement. Conceptually it matches last week's “give the agent real signals and context” thread, but here the signals come from production profiling rather than repo scanning. On the data side, Microsoft Fabric updated its VS Code extension for workspace artifact management (browse folders, open item definitions; editing behind an “allow editing” setting), and introduced a pre-release Fabric MCP server extension for Copilot Chat. With MCP tools enabled, Copilot can interpret item definitions, work with Fabric REST APIs/docs, and run tenant/workspace operations (CRUD items, OneLake file operations, notebook creation/run) inside the editor. This continues last week's Fabric MCP storyline (local MCP GA/open source and remote MCP in preview): “Copilot acts through governed tools,” now packaged for day-to-day editor workflows.

Other GitHub Copilot News

Long-running usage data from a large OSS repo added practical “what works at scale?” guidance for coding agents. After last week's focus on operability (validation tuning, traceability, reporting), the .NET team's ten-month review of Copilot Coding Agent in dotnet/runtime provides concrete maintenance outcomes: 878 agent-authored PRs (14% of PRs) with ~68% merged rate for decided PRs. Results improved when the repo was prepared (documented build/test commands, conventions in .github/copilot-instructions.md, agent access to needed feeds). They also showed “pairing” matters: agent PRs with human commits merged far more often than fully hands-off ones, and strict expectations (like requiring benchmark evidence for performance PRs) still applied. This aligns with this week's PR-native invocation: pairing is easier when the agent works in the same PR thread reviewers already use, not in a separate stacked PR.