Weekly GitHub Copilot Roundup: Shared Agents, MCP Tools, Governance

by TechHub

This week's GitHub Copilot updates focus on making agent work more collaborative, tool-aware, and governable. Shared agent sessions are now in public preview for Microsoft Teams and Slack, keeping conversations tied to secure sandboxes and pull requests so teams can review what changed and why. MCP momentum continued with hosted connector setup, practical tool servers (Playwright and SQL), and a portable Agent Plugins 1.0 packaging story that supports repeatable workflows across clients. Alongside new managed settings for JetBrains and more hands-on guidance for tokens and budgets, the thread running through the week is clear: scale Copilot usage by pairing better workflows with stronger controls.

This Week's Overview

Copilot goes social: shared agent sessions in Teams and Slack

Building on last week's push to make agent work more visible and auditable (canvases, session visibility, and comment-triggered automations), collaboration around Copilot's coding agent moved out of the editor and into chat this week, with public previews for both Microsoft Teams and Slack. In both integrations, you can invoke the agent with @GitHub, run work in a secure cloud sandbox, and have the agent open pull requests back to your repo so the conversation and the code stay connected.

For Teams, GitHub added a dedicated “code channel” concept to track progress and keep agent work visible to the whole team, along with billing controls for AI credits and sandbox usage. There is also an optional governance switch that requires an extra approval step for Copilot-attributed pull requests, which matters if your org wants stronger separation between “human-authored” and “agent-authored” changes in review workflows.

Slack gets a similar shared-session model, including Slack “Code” channels for focused, collaborative agent work that covers issue triage, investigating CI failures, and turning a thread into a PR. Admin controls and plan availability are called out explicitly, so teams can decide whether to pilot this broadly or keep it to a smaller group while they validate policy, audit expectations, and spend controls.

MCP and tooling: making agents useful without custom glue

Following last week's run of MCP interoperability work (hosted endpoints, SDK maturity, and portable plugin packaging), a cluster of updates and tutorials this week centered on making Copilot agents “tool-aware” through the Model Context Protocol (MCP), and on reducing the friction of wiring those tools into real projects. The common thread is pushing agent workflows past chat-only assistance and into repeatable, governed operations like browser automation, database access, and enterprise-managed tool catalogs.

MCP Connectors canvas: hosted tools without manual endpoint wiring

Microsoft introduced the MCP Connectors canvas extension (preview) for the GitHub Copilot app, aimed at removing the usual hand configuration of MCP endpoints and authentication headers. Instead of treating MCP servers as one-off integrations, it lets you connect hosted MCP servers from an Azure Connector Namespace and rely on a user-scoped MCP configuration that follows you across the Copilot app and Copilot CLI.

Security and governance details are part of the pitch: the post calls out behaviors like secret rotation and access policies, which are often the blockers when teams want to let agents touch real systems. For developers, the practical impact is faster setup for “real tools” (not just prompt templates) and a clearer admin story for scaling agent usage beyond a single workstation.

Extending Copilot with MCP servers (Playwright, SQL, Cosmos DB)

Several walk-throughs showed what “tools” look like in practice once MCP is in the loop, extending last week's theme that MCP is becoming the standard integration surface rather than a one-off adapter layer. One tutorial demonstrates installing the Playwright MCP server and using it to automate a browser session (including switching from Chrome to Microsoft Edge), which is a good example of tool calling where the agent can operate a deterministic interface and produce auditable steps.

A separate end-to-end testing example connects Playwright MCP to Copilot in VS Code to run browser tests against a Spring Boot app, then reviews the tool calls used during validation. That “review the tool calls” step is the important developer habit here: it turns agent actions into something you can reason about the same way you would a script or CI log.

On the data side, Microsoft highlighted a SQL MCP Server built on Data API Builder (DAB) that provides a governed way for AI tools to query SQL Server, Azure SQL, and Fabric SQL Database without granting direct raw SQL access. Azure Cosmos DB also added developer tooling that brings Copilot into the VS Code Query Editor with schema sampling and consent-based query execution, plus Cosmos DB-specific agent skills and optional MCP support (including local testing with the Cosmos DB Emulator).

Agent Plugins 1.0: a portable packaging format for skills and MCP

Building on last week's Agent Plugins 1.0 coverage (and the broader portability story around MCP), Agent Plugins 1.0 proposes a single portable package layout that can carry both Agent Skills and MCP server definitions in a form consumable by VS Code, Copilot CLI, and other conformant clients. The format keeps Copilot-only customizations separated in a namespaced folder, which is useful if you want to share agent capabilities across tools without committing to a single vendor surface.

For teams, the immediate implication is standardization: instead of re-implementing the same skill or MCP definition for each client, you can version a plugin alongside your repo or internal tooling. The guide highlights components like SKILL.md and touches on enterprise managed settings, which matters when you're trying to move from personal experiments to repeatable, auditable workflows.

Enterprise governance expands (JetBrains) and cost controls stay in focus

Building on last week's governance push (managed settings, MCP allow/deny lists, and third-party usage reporting), Copilot's agent features are increasingly tied to governance, and this week included both new admin controls and more hands-on guidance for managing token spend under usage-based billing. The theme is that “agentic” workflows are only sustainable when organizations can control permissions, tool access, and cost allocation without relying on individual developer settings.

Enterprise managed settings for Copilot in JetBrains

GitHub Copilot for JetBrains added enterprise managed settings, giving administrators centralized control over plugins and marketplaces, MCP server access, and OpenTelemetry configuration. It also lets orgs restrict agent permission modes like Bypass Approvals and Autopilot, which are exactly the knobs teams ask for when agent sessions can create PRs or interact with systems via tools.

For JetBrains-heavy orgs, this reduces the “policy gap” between IDE choice and security posture. It also signals that Copilot's admin model is converging across clients, so rollouts can be governed consistently even when teams mix VS Code, Visual Studio, and JetBrains.

Token usage, AI credits, and budgeting workflows

Continuing last week's throughline that model choice, reasoning depth, and AI Credits are tightly linked, two pieces focused directly on cost and efficiency: one explains how Copilot Chat uses context and tokens, then demonstrates /context, /init, and /compact to keep sessions focused and reduce token usage. It also calls out copilot-instructions.md as a way to steer sessions without repeatedly re-sending the same background information.

Another guide shares practical VS Code tactics for lowering token usage under usage-based billing, including model selection, compressing tool output, and cache-friendly workflows. On the governance side, an end-to-end billing walkthrough ties together seat assignment, cost centers, included AI credit caps, cost-center budgets, and user-level budgets (ULB), which is the kind of structure teams need if they're trying to keep spend predictable while still letting developers experiment.

Copilot app workflows: sessions, modes, canvases, parallel agents, and remote control

Following last week's emphasis on making agent sessions easier to operate and review (from better session visibility to comment-driven triggers), several guides this week clarified how the GitHub Copilot app is evolving into a place where you manage work, run agents, and keep multi-step efforts visible across time. The through-line is moving from one-off chat interactions to structured workflows: persistent sessions, explicit modes, shared canvases, and task tracking.

Settings, sessions, and modes (Interactive, Plan, Autopilot)

A configuration walkthrough breaks down how to set up the Copilot app across accounts, tool permissions, agent instructions, sessions, and model selection. It also explains how Interactive, Plan, and Autopilot modes fit together during feature work in a repo, giving developers a mental model for when to brainstorm, when to produce a concrete plan, and when to let the agent execute within guardrails.

If you're standardizing team behavior, the details around agent instructions and sessions matter because they shape consistency across runs. The mention of Git worktrees in this context also hints at where Copilot app workflows are headed: isolated execution environments where multiple efforts can run without stepping on each other.

Canvases and “visible” agent work

Building on last week's “make agent work reviewable” direction (effort levels, approvals, and clearer session state), GitHub's canvases pitch a durable surface for agentic workflows so plans, decisions, progress, and approvals do not disappear into chat history. The guide connects this to patterns like /create-canvas and illustrates why upfront AI credit costs can be worth it for repeated workflows (for example, modernization studios and other multi-step processes where you want a reusable plan and review checkpoints).

For developers, the practical takeaway is to treat canvases like living docs: capture the plan, record decisions, and make review and approval explicit. That can reduce rework when a session spans multiple days or passes between team members.

Parallel agents with git worktrees, plus remote control from GitHub Mobile

A beginner tutorial shows how to run multiple agent sessions in parallel by isolating each one in its own git worktree and tracking in-flight tasks on a centralized board. This is a concrete answer to a common pain point: agents can be productive, but not if you have to serialize everything through one branch and one chat thread.

Another feature demo adds a mobility twist: you can pair GitHub Mobile to an active Copilot session using a QR code and the /remote on command, then answer clarifying questions from your phone. The idea is not coding on mobile, but keeping the agent unblocked when you are away from your workstation, then returning to completed changes in the editor canvas.

Managing work inside the Copilot app

The “My work” pane walkthrough positions the Copilot app as a lightweight work hub, with built-in and custom views over issues and pull requests and the ability to start agent sessions directly from selected work items. If your team is trying to connect “what should we do next” with “start an agent run on it,” this UI-level integration matters more than another set of prompting tips.

The main implication is fewer context switches: pick the issue, start the session, and keep the thread anchored to the artifact that will eventually be reviewed and merged. That is a different workflow than treating Copilot as a generic chat window that you occasionally paste code into.

Modernization and IDE workflows: .NET upgrades and VS Code debugging

Building on last week's “Copilot beyond the editor” storyline (modernization workflows, CLI harness patterns, and more reviewable agent execution), Copilot-enabled modernization and day-to-day IDE workflows both got practical examples this week, showing how the tooling is being used for concrete, engineering-heavy tasks. The focus here is less on “what is Copilot” and more on how it fits into debugging and migration work where correctness and checkpoints matter.

Guided .NET modernization to .NET 10 in Visual Studio

Microsoft showcased a Copilot-assisted modernization flow in Visual Studio that upgrades a .NET Framework sample app to .NET 10 using guided checkpoints for assessment, planning, and step-by-step execution. The demo includes typical migration work like ASP.NET Core migration and moving from Entity Framework 6 to EF Core, which are the areas where teams often get stuck on compatibility and dependency edges.

A companion talk on modernizing .NET applications frames the same idea for larger solutions: using Visual Studio 2026, .NET, and Copilot to plan upgrades, handle compatibility issues, and manage multi-project dependency upgrades. Together, these examples push Copilot toward being a structured assistant for modernization rather than a code completion tool, especially when you need an audit trail of decisions and incremental progress.

Using Copilot to generate VS Code debug configuration from project context

VS Code highlighted a fast workflow where Copilot reads package.json, infers how a script should run, and generates a launch.json configuration so you can debug that script with the built-in debugger. This is a small but practical pattern: instead of searching docs for the right debugger settings, you ask Copilot to translate “how I run this script” into a reproducible debug config.

For teams, the value is consistency and speed, especially in repos with multiple scripts and ad-hoc run commands. Once launch.json exists, it becomes part of the project knowledge and can be shared across developers without repeating the same setup steps.

Building with Copilot: portfolio series, Bootstrap updates, CLI and SDK patterns

Following last week's “Copilot as a platform” framing (SDKs, harness patterns, and reusable workflows), a run of beginner-friendly and builder-focused content landed this week, spanning web portfolios, terminal-first workflows, and using the Copilot SDK to embed agent behavior into your own apps. The common theme is learning Copilot by shipping something tangible, then iterating with better context, better tools, and clearer guardrails.

Portfolio website series (GitHub Pages, prompting, context, MCP)

Microsoft Developer announced a 10-part beginner series that teaches Copilot by building a portfolio website, publishing it with GitHub Pages, and improving it over time. The trailer explicitly calls out prompting, context management, MCP servers, and agent skills, which suggests the series will move beyond “generate HTML” into repeatable workflows and tool-aware iteration.

Two tutorials already show that arc: one generates a portfolio site from a resume, then iterates on HTML/CSS/JavaScript to add a resume preview, custom colors, and dark/light mode. Another modernizes the site with Bootstrap 5, covering responsive layout updates, accessibility improvements, animated cards, skill badges, hover effects, and a sticky footer, which is a useful reminder that Copilot can help with the unglamorous polish work that often blocks a “good enough to publish” result.

Terminal-first development with Copilot CLI, plus the Copilot SDK for app builders

A Fast Focus session demonstrates a terminal-native workflow with GitHub Copilot CLI: start from a vague idea, turn it into a plan, make code changes, then do a review step without leaving the command line. The emphasis on slash commands and file references for grounding is a practical pointer for keeping CLI-based agent work tied to repo reality instead of drifting into generic advice.

For developers building their own AI-enabled tools, another session walks through the GitHub Copilot SDK, including wiring the app to tools and discussing failure modes and guardrails. A separate integration demo shows the Copilot SDK connected to the .NET Microsoft Agent Framework and Ollama running locally, which is a useful pattern if you want a hybrid approach where some model execution stays on developer-controlled hardware while still using SDK-style orchestration.

Reusable workflows with agent skills and plugins

Building on last week's Agent Plugins 1.0 momentum (and the broader push toward portable, versioned agent capabilities), one tutorial focuses on packaging a repeated blog publishing routine into reusable Copilot agent skills, including using personas for review and extending workflows via plugins and marketplaces. The practical point is that when a workflow repeats, the right unit of reuse is not a prompt snippet but a skill with a known set of steps, inputs, and expected outputs.

Combined with the Agent Plugins 1.0 conversation elsewhere in the section, the direction is clear: define skills once, share them across teams and clients, and treat agent workflows as assets you can version. This is especially relevant if you are trying to bring Copilot into operational routines like content publishing, release notes, or internal documentation where consistency matters.

Other GitHub Copilot News

VS Code Live included a walkthrough of recent Visual Studio Code and GitHub Copilot features, useful if you want a single “what changed recently” demo rather than individual feature clips.

Student onboarding content continues to fill in the basics, including how to enroll in GitHub Education and use the Student Developer Pack to get started with Copilot, then generate a simple “Hello World” website and open it in VS Code.

A separate session looks at using Copilot to build deterministic migration tools (for example, moving between package versions or switching libraries), which is a helpful framing when you need repeatable transformations rather than one-off edits.