Weekly GitHub Copilot Roundup: Agents Everywhere, Guardrails Tighten

by TechHub

This week’s Copilot updates kept moving past the “chat + autocomplete” baseline toward agents that work across the web, IDE, CLI, and mobile, with more governance and observability as usage scales. Building on last week’s shift toward agent work inside PRs/Issues/Projects and better operability (logs, validations, admin controls, reporting), this week extends that direction in two ways: more entry points for agent work (branch-first, mobile/Slack) and tighter enterprise guardrails (runner and firewall controls, signed commits, org-wide instructions). Model availability is also changing quickly, so teams that pin models or enforce policies should plan regular housekeeping to avoid surprises.

Copilot cloud agent on GitHub.com: branch-first workflows, planning, research, and tighter org controls

After last week’s PR-native improvements (comment @copilot on an existing PR, update the current PR by default, and resolve merge conflicts with logs and validations), Copilot cloud agent (formerly the Copilot coding agent) can now work directly on a branch without automatically opening a PR. Teams can iterate privately, review the evolving diff, and open a PR only when they are ready, while still requesting auto-created PRs when that is preferred. This pairs last week’s “iterate within the same PR thread” flow with a pre-PR staging mode. The agent also added two changes aimed at reducing unexpected diffs. First, it can draft an implementation plan before coding so you can approve or adjust the approach up front. Second, “deep research” sessions let it answer broader repo-grounded questions, which can help with impact analysis and design trade-offs, especially when combined with last week’s expanded agent visibility in Issues/Projects. As more teams adopt it, GitHub added org-level controls for where the cloud agent runs and what it can reach. Platform teams can set (and optionally lock) which Actions runner executes agent tasks (GitHub-hosted, Large, or self-hosted) without managing runner choice repo-by-repo via copilot-setup-steps.yml. Org admins can also centrally manage the agent firewall (on/off, recommended allowlist, custom allowlist, and whether repos can add entries), which affects workflows that fetch dependencies, call external services, or reach internal registries. Together, these continue last week’s “automatable rollout” direction at two early control points: network egress and compute placement. Supply-chain and compliance workflows got easier as well: the cloud agent now signs every commit it creates. Agent commits show as “Verified” and work in repos that enforce “Require signed commits” via branch protection/rulesets. Combined with last week’s traceability (session logs, issue sidebar status, PR-thread invocation), commit provenance becomes part of the default setup as agents become regular commit authors.

Copilot in Visual Studio and VS Code: custom agents, agent sessions, and more IDE-native workflows

In Visual Studio, Copilot’s March update focused on making agent behavior portable and repeatable across repos, which mirrors last week’s repo-visible instructions/skills and this week’s GitHub.com plan/research work. Teams can define custom agents as *.agent.md files under *.github/agents/* and expose them in Visual Studio’s agent picker, with settings such as workspace awareness, tool access, preferred model, and MCP connections. Visual Studio also added “agent skills” as reusable instruction sets stored in the repo (shared defaults) or the user profile (personal defaults), which are auto-discovered during workflows. This fits the “configuration scales” theme and helps keep IDE and GitHub.com agents aligned per repo. Agent mode also gained a navigation tool that relies on language services rather than text search: find_symbol locates and reasons about symbols across the project. It supports C++, C#, Razor, TypeScript, and LSP-backed languages, which helps refactors avoid missed call sites or scope/type mistakes, especially as last week’s PR/issue workflows encourage larger agent changes. The update also brought Copilot into IDE performance and security loops. “Profile with Copilot” in Test Explorer runs a specific test via a Profiling Agent and analyzes CPU/instrumentation data (called out for .NET tests). During debugging, PerfTips now use live profiling, and a Profiler Agent captures elapsed time/CPU/memory signals so Copilot can suggest optimizations when you hit a slowdown. For dependency hygiene, Visual Studio can remediate vulnerable NuGet packages from Solution Explorer via “Fix with GitHub Copilot,” which turns detection into an in-IDE update loop. This continues last week’s “give the agent real signals” thread, but shifts it from external telemetry to built-in diagnostics and security findings. In VS Code, Copilot kept becoming more “session-aware,” matching last week’s traceable sessions/logs (issue sidebar status, PR-linked logs, CLI /context and /resume). VS Code 1.114 highlights centered on Copilot Chat usability, including richer media in the chat carousel, copy as Markdown, improved troubleshooting, and updates to the #codebase grounding command. VS Code 1.115 Insiders added more session state (restore agent edits with diffs and undo/redo), exposed entitlements/usage inside Sessions, and expanded session context to include the integrated browser (tracking tabs the agent used). Terminal automation also improved: background terminals can notify the agent on completion with exit codes/output, input prompts are surfaced to avoid silent stalls, and send_to_terminal supports confirmed command dispatch to background terminals. Remote workflows improved with an SSH path that installs the VS Code CLI and starts agent host mode on remote machines. Overall, last week made agents more present in GitHub collaboration surfaces, and this week makes editor/terminal work easier to resume, audit, and drive with more explicit control.

Copilot CLI and Copilot SDK: multi-agent orchestration and a reusable agent runtime

Copilot CLI added multi-agent execution via the /fleet command. /fleet breaks a goal into work items, runs sub-agents in parallel, then validates and synthesizes results into your working tree. In real repos, the details matter: each sub-agent has its own context window, they share the filesystem, and they do not coordinate directly, so prompts should specify file ownership to avoid collisions (or stage outputs in temp paths and merge). It builds on last week’s CLI focus on session controls (/model, /context, /resume) by adding an orchestration pattern that does not depend on one long context thread. GitHub also released the Copilot SDK in public preview (the same agent runtime used by Copilot cloud agent and Copilot CLI), so teams can embed agent interactions in internal apps without building orchestration from scratch. This extends last week’s Copilot SDK “IssueCrush” walkthrough into a shared runtime rather than a one-off pattern. The SDK includes tool invocation, stateful multi-turn sessions, streaming, built-in file ops, and a permissions/approval framework (including read-only tools that can bypass approvals). It supports blob attachments (images/screenshots without temp files) and OpenTelemetry tracing with W3C Trace Context propagation, extending last week’s “traceable logs” theme into standard telemetry pipelines. BYOK (OpenAI, Azure AI Foundry, Anthropic) keeps model/provider flexible while standardizing the runtime. The preview ships for Node/TypeScript, Python, Go, .NET, and Java. GitHub also published an SDK demo that adds planning flows to a Node.js app (meal plans and weekend schedules), with an emphasis on regeneration as constraints change. The takeaway is how to wire an app to SDK sessions and support iterative refinement without restarting, which lines up with this week’s “plan first” in Copilot cloud agent and last week’s repeatable session lifecycles.

MCP + Azure workflows: Copilot-assisted scaffolding, deployments, and repo-grounded research pipelines

Copilot’s “agent + tools” story showed up across Azure workflows, extending last week’s MCP thread: connect Copilot to tools, then operationalize access with versioned config, enforcement, and audit. Azure Developer CLI (azd) shipped a preview “Set up with GitHub Copilot” path in azd init, using a Copilot agent to scaffold a project and align it to azd conventions (templates, azure.yaml, service detection), with guardrails like dirty-directory checks and consent before enabling MCP server tooling. The same release added AI-assisted troubleshooting for failed commands (explain/guidance/troubleshoot/skip), with an option to apply a fix and retry from the terminal. azd’s extension SDK also added MCP utilities and a new CopilotService gRPC service so extensions can use agent capabilities (sessions/messages/usage metrics), which matches last week’s “turn playbooks into tool-driven flows” pattern. An “Azure Skills Plugin” cookbook also published many copy/paste prompts for Copilot Chat (Agent mode) and Copilot CLI to automate Azure tasks end-to-end: repo analysis and infra generation (azure-prepare), validation (azure-validate), deployment via azd (azure-deploy), plus diagnostics via KQL, RBAC/compliance checks, Entra app registrations, and AI service setup (Azure AI Search, API Management as an AI gateway, Foundry tasks). The theme is chaining skills into prepare → validate → deploy pipelines while keeping explicit per-skill calls for tighter control, similar to last week’s “standardized prompt files in CI,” expressed here as skill chains. Project Nighthawk provided a concrete pattern for repo-grounded research in VS Code: a multi-agent pipeline that searches locally cloned repos (kept current via git pull), consults Microsoft Learn via an MCP server, synthesizes a cited Markdown report, and runs a fact-checker that validates claims and flags unverified statements. For deep technical investigations, this extends last week’s “observability + verification” mindset into reviewable research artifacts, especially now that this week adds “deep research” sessions to Copilot cloud agent.

Other GitHub Copilot News

Org-level governance and reporting kept closing admin gaps, building on last week’s repo allowlisting and usage metrics flagging used_copilot_coding_agent. Organization custom instructions are now GA for Copilot Business and Enterprise, so admins can set defaults across Copilot Chat on github.com, Copilot code review, and Copilot cloud agent. Usage reporting also expanded: org reports now include per-user Copilot CLI activity (session/request counts, tokens, average tokens per request, last known CLI version) via the Copilot usage metrics REST API (apiVersion=2026-03-10). Together with last week’s agent-user metric, this helps distinguish “used Copilot” from “ran agents” from “drove terminal automation,” as entry points expand beyond IDEs.