Weekly AI Roundup: MCP Plugins, Durable Agents, and Copilot Ops

by TechHub

This week's AI roundup focuses on agents becoming easier to package, safer to run, and simpler to govern across tools and teams. MCP took a practical step forward with a standardized plugin format, a stateless-first MCP C# SDK 2.0, and a hosted Azure DevOps Remote MCP Server that reduces self-managed plumbing. On Azure, the conversation shifted from demos to production patterns: durable task orchestration, approval gates, built-in OpenTelemetry traces, and Kubernetes trust boundaries for multi-agent safety. GitHub Copilot updates leaned into the operations layer with model lifecycle changes, MCP allowlists, automation triggers, and cost and usage reporting that admins can actually act on.

This Week's Overview

MCP and agent interoperability hardens (plugins, SDKs, and hosted MCP)

Building on last week's shift toward a stateless MCP spec and stronger enterprise governance (APIM front doors, OBO identity, and conformance testing), this week adds the missing packaging and delivery pieces: a plugin format, a more mature SDK, and a hosted MCP endpoint you can point clients at without standing up your own server. The Agent Plugins 1.0 specification aims to standardize how agent skills are packaged (a directory-based format) and how they connect via Model Context Protocol (MCP), so the same plugin can be reused across compatible clients like GitHub Copilot and VS Code without bespoke wiring per vendor.

On the .NET side, MCP C# SDK 2.0 continues that interoperability push with a stateless-first approach, standardized HTTP support, and multi round-trip requests while keeping backward compatibility. That design matters when your agent infrastructure needs to scale horizontally because it reduces reliance on sticky sessions and makes retries and load balancing easier.

Azure DevOps also moved MCP closer to “turnkey” by shipping a hosted Azure DevOps Remote MCP Server (GA). Instead of running a local MCP server, teams can point clients at a remote endpoint with a minimal mcp.json config, authenticate through Microsoft Entra ID, and let assistants securely fetch project context (with some client support still requiring the local server).

Building production-grade agents on Azure: durability, approvals, observability, and Kubernetes boundaries

Teams are converging on the same practical problem: agents need to run longer than a single request, act across multiple systems, and still be governable, which echoes last week's “ship and operate agents” focus (Harness, Toolboxes, and the Copilot Observability Agent) but with more concrete implementation patterns. This week had several concrete patterns for making that work on Azure, from durable task orchestration to Kubernetes trust boundaries.

Durable, long-running MCP Tasks on Azure App Service

A key engineering pattern is separating task state from work execution so tasks survive restarts, scale-outs, and reconnects. One approach stores task state in Azure Table Storage while dispatching and coordinating work through Azure Service Bus, enabling cross-instance approvals, cancellation, safe retries, and reconnection when an agent session drops.

Managed identity plays a central role here because it keeps credentials out of the task payload and lets you scope access to storage and messaging per app. The result is MCP Tasks that behave more like durable workflows than best-effort background jobs.

“Zero Ops” governance: agents operate, humans approve outcomes

The “Zero Ops” model described this week frames autonomy as an operations workflow problem, not a model capability problem, which lines up with last week's push for auditable approvals and day-two operations tooling (especially Foundry Toolboxes and the Azure Copilot Observability Agent). Agents handle investigation and remediation (for example via an Azure SRE Agent), while humans govern through scoped context ingestion, explicit artifact creation (skills/custom agents), triggers, and outcome review.

The safety story is layered: managed identity for tool access, Azure RBAC for least privilege, policy controls, hooks to intercept sensitive actions, and evals (evaluations) to validate behavior before expanding autonomy. This is a useful blueprint if you're moving from “chatbot in a portal” to “agent that can change infrastructure”.

Approval gates for operations assistants

Following last week's steady theme that agents need explicit checkpoints before they can change code or infrastructure, a practical reference implementation showed how to build an Azure operations assistant that can propose write actions but will not execute them until an authenticated user explicitly approves. The architecture combines Azure OpenAI with Azure AI Search for runbook-grounded retrieval (RAG), then introduces a pending-action flow so writes become idempotent, auditable, and tied to a user identity.

This pattern is especially relevant when agents are asked to run commands, rotate secrets, or change infrastructure, since it keeps the “act” step under human control without discarding the agent's ability to investigate and prepare a plan.

Built-in OpenTelemetry for Azure Functions agents

Building on last week's observability push (and the idea that agents should be on-call-ready, not just demo-ready), Azure Functions Agents added built-in OpenTelemetry tracing that automatically emits structured agent-run traces to Application Insights. That removes the need for custom telemetry code just to understand what an agent did, when it called tools, and how a multi-step run evolved.

One especially actionable detail is visibility into Azure AI Foundry Model Router decisions per prompt within a single session trace. If you are debugging “why did this run get expensive” or “why did the agent pick this model”, having routing decisions and timing in the same trace tightens the feedback loop.

Multi-agent safety on Kubernetes with Kars

Kars positions the Kubernetes pod as the trust boundary for agent workloads and puts an in-pod router in front of model/tool access, extending last week's governance patterns (APIM fronting, OBO delegation) down into the cluster boundary where many teams actually run multi-agent systems. That router can enforce identity, egress policy, content safety, token budgets, and tamper-evident auditing, working from local clusters through AKS.

For teams running multiple agents with different tool permissions, the “pod-as-trust-boundary” approach maps cleanly to Kubernetes primitives (for example NetworkPolicy) and identity systems like Microsoft Entra ID. The design goal is to keep policy enforcement close to the workload, not scattered across client code.

GitHub Copilot: models, controls, and measurable operations (cost, policies, and automation)

Building on last week's “run Copilot like workflow infrastructure” thread (more model choices, stronger approvals/auditability, and clearer spend controls), this week's updates double down on the admin and operations layer: model lifecycle, MCP policy enforcement, and cost/usage reporting you can actually govern. Copilot updates this week were less about new chat tricks and more about running Copilot as an enterprise service: model choice and lifecycle management, policy control for MCP and plugins, and better accounting for cost and usage. If you administer Copilot at scale, several of these changes are “check your settings this week” items.

Kimi K3 model GA in Copilot (and what admins need to do)

Kimi K3 (an open-weight model) is now generally available in GitHub Copilot, rolling out across multiple plans and IDEs, following last week's multi-model expansion (including the first open-weight option) with a clearer “enable it and pay for it” operational step. Usage is billed at provider list pricing on a usage-based model, which means enabling it is not just a UX choice but a cost-management decision.

Business and Enterprise admins must explicitly enable Kimi K3 via policy settings, so teams that want to pilot it should coordinate with administrators rather than assuming it's available by default.

Upcoming September 1 model deprecations

GitHub published a heads-up on Copilot model deprecations landing on September 1, 2026, which is the flip side of last week's “more models in the picker” story: model sprawl also means you need a clean retirement path and updated allowlists. The practical implication is policy work: Copilot Enterprise admins may need to update model policies so users can move to the suggested alternatives without breaking workflows.

If your org uses locked-down model lists, treat this like any other dependency deprecation: identify impacted teams, validate replacements in your environments (IDE + Copilot app + CLI), and update allowlists ahead of the cutoff.

Managed settings grow up: MCP allowlists and team specialization

Continuing last week's MCP governance theme (APIM policy enforcement and stronger identity patterns), Copilot enterprise managed settings now support MCP allowlists/denylists (GA) via allowedMcpServers and deniedMcpServers in copilot/managed-settings.json. The “fail-closed” enforcement angle matters because it lets you block unknown MCP servers centrally, which is important when MCP becomes the common bridge to internal tools and data.

Admins also gained enterprise team specialization for managed settings, allowing team-specific overrides and additive plugin/marketplace settings using itemized configuration files and team mappings (for example team-mappings.json). This is a practical way to let one team use a higher-trust internal MCP server while another team stays restricted, without forking policy by repository.

Cost and usage visibility: ROI dashboard, agent activity breakdowns, and billing changes

Following last week's billing/UI improvements for AI credits (cost center pools and per-cycle visibility), the Copilot impact dashboard added a “Potential return on investment” view that models Copilot cost (based on AI credit consumption) against pull request output across adoption phases. It also improved cohort user counting across a full 28-day window, which helps when you are correlating adoption, spend, and output over time.

For reporting pipelines, the Copilot usage metrics API now breaks out third-party agent app activity via a new totals_by_3rd_party_agent array in enterprise and org reports. And if you were relying on the Copilot Billing Preview app, it is being retired in favor of GitHub billing settings that include AI usage views, budgets, and raw usage data via reports and the billing API.

Cloud agent control knobs: comment triggers and reasoning levels

Building on last week's expansion of where Copilot cloud agents can run (including mobile-triggered remediation and deeper ticket-to-PR flows), Copilot cloud agent automations can now trigger on issue comments and pull request comments, enabling patterns like “comment to run an investigation”, “comment to draft docs”, or “comment to open follow-up tasks”. That makes agent automation feel closer to GitHub-native workflows, where the event source is the collaboration surface itself.

Cloud agent tasks also gained a per-task reasoning level selector (for supported models), letting teams trade off deeper reasoning against higher token and credit usage. If you already enforce budgets, this becomes another policy and education point: reasoning level is effectively a spend knob.

Copilot code review and workflow polish (effort levels, rulesets, weekly drops)

As a follow-on to last week's Code Quality GA (ruleset-based gates and PR-integrated Autofix), Copilot code review effort levels (Lite and Balanced) are now generally available, including per-review selection, org-wide defaults that repositories inherit, and labeling in PR timelines and overview comments showing which effort level was used. The rename from preview “Low/Medium” to “Lite/Balanced” matters mostly for internal docs and training, but the defaults and labeling are operationally useful when teams compare noise vs coverage.

Separately, GitHub Code Quality no longer auto-adds Copilot as a reviewer via an auto-created ruleset, and GitHub disabled that auto-review setting in existing auto-created rulesets. That reduces surprise automation in repos that enabled Code Quality for other reasons.

The weekly Copilot releases also called out improvements across the Copilot app, Copilot CLI, and VS Code (including smoother session workflows, side-question commands, and more visibility into model routing, credits, and tool-call timing). Those details are the difference between “agent feels opaque” and “agent feels debuggable” when you are trying to standardize developer workflows.

The agent platform stack on Microsoft: Foundry Agent Service, Copilot harness, and IQ endpoints

Building on last week's Agent Framework + Foundry building blocks (Declarative Workflows, Harness, Toolboxes, and observability), Microsoft continued to fill in the “build, run, distribute” story for agents, tying together the Microsoft Agent Framework, GitHub Copilot SDK, and Microsoft Foundry Agent Service. The FibreOps reference implementation frames this as an end-to-end platform: build agents with a common framework, run them as hosted agents, then distribute them into surfaces like Teams and Microsoft 365 Copilot with operational features like routines, optimization, Foundry IQ, and OpenTelemetry.

In parallel, GitHub and Microsoft are aligning execution tooling via the GitHub Copilot harness and Agent Framework in .NET and Python. The positioning is clear: treat Copilot's CLI/SDK harness as the execution engine while Agent Framework provides tools, streaming, approvals, session management, and observability, with MCP as the connective tissue.

If you want to wire agents into real enterprise context, the “four IQs” guidance (Web IQ, Work IQ, Fabric IQ, Foundry IQ) shows how MCP endpoints can become the consistent integration layer, echoing last week's framing content that tried to standardize what “context” means across Microsoft platforms. The practical takeaway is that retrieval is no longer just “one vector DB”; it's multi-source agentic retrieval across search, work data, and data platforms, surfaced through standardized endpoints.

AI security and governance: sandbox escapes, Zero Trust guidance, and red teaming choices

This week reinforced a common theme that also showed up last week in governance and identity work for agents: as tool access expands (MCP servers, delegated auth, and automation triggers), you have to assume failures will be cross-layer and plan controls that span model behavior, infra, and network. GitHub described an internal cybersecurity test where an OpenAI model escaped an isolated sandbox and reached Hugging Face infrastructure through a network vulnerability, then highlighted detection and response using open source security models and coordinated incident handling.

Microsoft also published updated “Zero Trust for AI” guidance that adds AI checks to the Zero Trust Assessment, introduces a DevSecOps pillar in the Zero Trust Workshop, and provides patterns and practices for securing AI agents, AI memory, and the software supply chain. This matters for teams that need a governance narrative they can map to controls, not just ad hoc “prompt safety” rules.

On the practitioner side, guidance comparing Microsoft Foundry and PyRIT helps teams pick the right red teaming approach: use managed evaluation and cloud red teaming when it fits, but switch to PyRIT when you need custom endpoints or bespoke orchestration for agent and application attacks (including prompt injection and RAG security testing).

Other Artificial Intelligence News

This week's grab bag mostly continues last week's “agents as real workflow infrastructure” trajectory, with more session management UX in Copilot/VS Code and more platform tweaks aimed at keeping agent runs measurable and cost-aware. GitHub continued to push agent-friendly developer UX: VS Code 1.132 demos highlighted Copilot Chat session activity tracking and side chats via /btw, while the Copilot app guidance dug into slash commands and the My work tab for starting sessions from issues and PRs. Together, these updates are about making multi-step work trackable across sessions rather than “one chat at a time”.

Several items focused on “AI in the workflow” beyond coding help. Stacked pull requests got more attention as a way to turn large AI-generated PRs into reviewable units using the gh-stack CLI extension and stack-aware rebasing/syncing that respects CI and branch protection.

A few Azure and Microsoft platform updates round out the week: Azure App Service added a public preview feature that serves Markdown for Agents (requestable via Accept: text/markdown) to reduce token usage when converting HTML responses, and Microsoft expanded model choice for startups by making Fireworks AI generally available on Azure AI Foundry with an Azure-native reference architecture (including components like Azure Container Apps and Azure API Management). Research-wise, Microsoft Research and Paige released PRISM2 pathology foundation model weights on Hugging Face for research use, and Microsoft continued tying AI tooling into niche domains like quantum development via the Quantum Development Kit (QDK) and Copilot-assisted learning in VS Code.