Weekly AI Roundup: Copilot models, MCP tooling, and agent ops

by TechHub

This week's AI roundup centers on shipping agents safely and paying for them predictably, from GitHub Copilot's expanding model lineup (and upcoming deprecations) to richer per-model token reporting for chargeback. MCP continued its shift into everyday tooling with faster VS Code setup, clearer enterprise guidance on auth and governance, and more concrete patterns for packaging and distributing tool access via Agent Plugins. On Azure and Foundry, the focus stayed operational: hosted agents as containers with tracing, sandboxed execution for risky workloads, and routing model and tool traffic through an AI gateway for consistent policy and telemetry. We also saw practical improvements in content extraction (Azure Content Understanding), RAG relevance discipline (reranking plus better vector indexing), and reliability and cost controls that treat agents like any other production service.

This Week's Overview

GitHub Copilot expands its model lineup (and tightens cost and policy controls)

Building on last week's theme of Copilot model churn driving stricter governance, Copilot shipped another wave of model choices across IDEs and Copilot surfaces, with Gemini 3.7 Flash rolling out alongside Grok 4.6, Kimi K3, and MAI-Code-1.1-Flash. These models show up via the model picker and are billed using usage-based pricing at provider list rates, which makes admin policy and chargeback visibility more important than “pick the best model” guidance.

MAI-Code-1.1-Flash is positioned as the practical upgrade path, and GitHub has already scheduled MAI-Code-1-Flash for deprecation on September 10, 2026. If your org uses Copilot Business or Enterprise, plan time to review model policies because newer models may be disabled by default, and developers will not see them in chat selectors until admins explicitly allow them.

This week also added plumbing to help teams manage both governance and cost. Agent Plugins 1.0 reached GA with a portable plugin package that bundles skills plus MCP server configuration, and GitHub's AI usage report gained per-model token breakdown (input, output, cache read/write) to explain spend at a level finance teams can actually reconcile.

MCP (Model Context Protocol) moves from concept to everyday tooling

Building on last week's MCP story (SDK/spec alignment and IDE adoption), this week reinforced MCP as the common “wiring standard” for connecting models to tools and data, and the ecosystem is starting to feel less like bespoke integrations and more like repeatable building blocks.

MCP Live and enterprise readiness (auth, governance, security)

Following last week's focus on MCP becoming more operational (governed authorization, standardized building blocks, and observability), Microsoft's MCP Live event focused on the practical path from “my agent can call tools” to “my enterprise can run this safely,” with sessions on authentication, governance, and security. The takeaway for teams building internal MCP servers is that the hard parts are identity, policy, and operational controls, not just implementing a tool schema.

Faster setup in VS Code and real examples in app code

Continuing last week's push to make MCP easier to adopt inside IDE workflows, VS Code highlighted a one-click setup for the GitHub MCP server so Copilot can use it without manual mcp.json edits or extra extensions. On the “build your own server” side, Rory Preddy demonstrated exposing Spring Boot methods as MCP tools and letting Copilot invoke those tools from VS Code to update the application, which is a concrete pattern for turning an internal service into agent-callable capabilities.

Designing database MCP servers with safety tradeoffs

Picking up on last week's security-through-guardrails thread (least privilege, explicit boundaries, and auditability for tool calls), Pamela Fox mapped out MCP server designs for databases from free-form SQL to templated tools, then got specific about guardrails like progressive schema discovery, read-only enforcement, least-privilege roles (for example in PostgreSQL), and elicitation before destructive actions. If you're building tool-calling into production data systems, this is a useful checklist for deciding where you want flexibility versus predictable, auditable operations.

Packaging MCP configuration as portable plugins

Following last week's spread of MCP connections across Copilot clients (code review, VS Code, JetBrains), Agent Plugins 1.0 is the step that makes MCP distribution more operational: plugins can bundle both “skills” and the MCP server config needed to run them across VS Code, Copilot CLI, the Copilot app, and the Copilot SDK. For enterprises, the managed settings and MCP allowlists are the key detail because they let you standardize what tools agents can access without relying on developers to hand-configure clients.

Building and operating agents on Azure and Foundry

Agent work is shifting from “demo a chat” to “ship a service,” and this week's content spent more time on deployment targets, isolation, tracing, and policy enforcement than on prompts.

Foundry Agent Service hosted agents: containers, routines, memory, and tracing

Following last week's Foundry direction toward production mechanics (hosted agents, toolboxes, and observability), Part 3 of the Foundry Agent Service series dug into the “Run in Foundry” pillar, showing Hosted Agents deployed as containers and evaluated with the Agent Optimizer. It also highlighted deterministic “Routines” (for repeatable behavior), plus Memory and Toolboxes for reusability, with OpenTelemetry and Application Insights used to trace runs end-to-end.

The practical implication is that agent systems are being treated like normal cloud services: containerized deployment, measurable evaluation, and standard observability. If you are already instrumenting distributed systems with OpenTelemetry, the same approach applies to agents, which makes debugging tool calls and multi-step workflows less opaque.

Sandboxed execution for agentic workloads in Azure Container Apps (Preview)

Azure Container Apps Sandboxes (Preview) introduced hardware-isolated microVM workspaces for agent tasks, with snapshots, restricted egress, managed identities, and VNet integration. The Templafy case study is a solid “why now” example: an agent spins up a sandbox from a Node image, clones repos, runs tools, and explores code triggered from Slack workflows without giving the agent a long-lived or overly privileged environment.

If you have agents that run untrusted code or need to operate on customer repos, isolation and egress controls become part of your threat model. Sandboxes are positioned as an Azure-native way to enforce that boundary without inventing your own ephemeral VM orchestration.

Routing all model and tool traffic through API Management AI Gateway

Building on last week's introduction of the dedicated Azure API Management AI Gateway tier as the control plane for model and MCP access, the new dedicated Azure API Management AI Gateway tier was framed around agent hosting on App Service, with a runnable Python/FastAPI sample that forces OpenAI-compatible model calls and MCP ToolServer calls through the gateway. That central choke point is where policy enforcement and correlated telemetry can live, which matters if you need consistent auth, usage limits, logging, or data-loss prevention across multiple agent services.

Serverless agents in Azure Functions for event-driven workflows

Azure Functions Serverless Agents were presented as a way to add AI to existing event-driven pipelines without rewriting triggers, with agent instructions stored in markdown and runnable from queues, Service Bus, Event Hubs, and other non-HTTP triggers. The post also calls out provider configuration (Azure AI Foundry / Azure OpenAI) and Application Insights telemetry, which makes it easier to fit agents into established operational patterns.

Reliability, governance, and cost controls for agentic systems

As more teams push agents into real workflows, the weekly theme is less “can it code” and more “can we trust it, observe it, and pay for it.”

.NET model routing and failover in Microsoft.Extensions.AI 10.9.0 (experimental)

Microsoft.Extensions.AI 10.9.0 added experimental primitives for routing and failover: RoutingChatClient, SemanticRoutingChatClient, FailoverChatClient, and OrderedFailoverChatClient. The routing story includes content-based selection (using embeddings for semantic routing), plus patterns like sticky routing and latency-aware choice, which are useful when you have multiple providers or models with different costs and strengths.

Failover behavior is called out as meaningfully different for streaming versus non-streaming responses, since you cannot safely “retry” a stream without risking partial duplicates or broken UX. If you're designing agent backends in .NET, these clients are a starting point for resilience patterns that you would otherwise hand-roll in each service.

Runtime policy enforcement with Agent Framework Harness + Agent Governance Toolkit

This continues last week's shift toward explicit tool boundaries and auditable access by showing how to govern tool calls at execution time by combining Microsoft Agent Framework Harness with the Agent Governance Toolkit (AGT). The example uses YAML allow/deny rules for a file-access agent and emits audit events, which is the sort of control you need when agents can call internal tools that have real side effects.

Measuring reliability with SLIs/SLOs and an SRE agent

The Reliability Starter Kit wired Azure Monitor SLIs/SLOs, Azure Monitor health models, and an Azure SRE Agent into an end-to-end deployment with OpenTelemetry, managed Prometheus, plus scripted validation steps. For teams moving from chatbot demos to production services, this is a concrete blueprint for the “define reliability targets, measure them, and automate response” loop.

FinOps for agents: optimizing tokens, workflows, and governance

Building on last week's layered spend controls (GitHub budgets plus runtime enforcement via gateways), Tina Schuchman kicked off a series on AI FinOps for agents, focusing on what drives token spend and how Foundry can support runtime request optimization, workflow optimization over time, and ongoing spend governance using Azure tooling. A separate FinOps guide reinforced the operational playbook: instrument token and request drivers, route to the cheapest acceptable model, and use batching, caching, autoscaling, and guardrails so cost stays predictable as volume grows.

If you're using Copilot usage-based billing or running high-volume agent backends, the “measure first” work is no longer optional. The new per-model token breakdowns in GitHub's usage reporting fit directly into this mindset because they help teams identify whether spend is driven by long prompts, large outputs, or cache misses.

Azure Content Understanding: refreshed APIs, CU 2.0 preview, and GPT-5-series grounding improvements

Azure Content Understanding (CU) shipped August 2026 updates that split into a refreshed CU 1.0 GA API and a CU 2.0 public preview, with GPT-5 series support as a headline. Updates include lower token usage, improved grounding and confidence scoring, new synchronous Read/Layout APIs, semantic chunking, and an “agentic mode” for workflows that need iterative extraction and validation.

A separate guide went deeper on selecting the right GPT-5 series model across document, video, speech, and image workloads, and it highlighted new grounding and confidence methods that aim to reduce hallucinated extractions. For teams building ingestion pipelines (contracts, invoices, call transcripts, screenshots), these changes point toward more accountable extraction: better confidence signals, clearer model selection tradeoffs, and options to run synchronously when you need predictable latency.

RAG pipeline mechanics and vector indexing: retrieval is not the end of relevance

Teams building retrieval-augmented generation (RAG) apps got two practical angles this week: better indexing primitives and better ranking discipline. The RAG guide emphasized that vector search is only the first stage (candidate generation), and that rank fusion (RRF) and learned reranking often decide what the model actually “reads,” with concrete mapping to Azure AI Search semantic ranker, Cohere Rerank v4.0 Fast, and reranking options across Azure SQL, PostgreSQL Flexible Server, and Cosmos DB.

On the database side, Microsoft SQL updates highlighted improvements to vector indexing such as iterative filtering and TOP WITH APPROXIMATE, plus a demo of creating a vector index with notes relevant to Azure SQL Database Hyperscale. Put together, the story is that relevance and latency both depend on the full chain: index design and filtering reduce candidate cost, while reranking improves final quality.

Copilot and agent workflows inside GitHub: packaging, orchestration, and “AI-first” contributor reality

This extends last week's “GitHub as the operational surface for agents” story (skills, MCP connections, and reusable workflows) by showing how teams are increasingly treating GitHub as the control plane for agent work, where agent tasks turn into pull requests and branch protection provides deterministic guardrails. Guidance this week connected that idea to concrete tooling: Agent Apps and Marketplace integrations that run from issues and PRs (dependency risk, feature flags, deployment risk), plus tips for splitting large agent-generated changes into stacked PRs using the gh-stack skill.

On the maintainer side, the “AI-first contributors” guidance focused on making repos agent-readable and enforceable, using instruction files, PR templates, required CI checks, and CLA workflows to keep quality predictable when a growing share of contributions is machine-generated. That pairs well with the .NET “instructions hygiene” advice: keep instruction files high-signal (validation commands, hard constraints, non-obvious repo facts) and remove vague prompt folklore that doesn't translate into reliable behavior.

Other Artificial Intelligence News

Building on last week's steady expansion of Copilot clients (app, JetBrains, VS Code) and the growing need to observe usage and reliability, GitHub continued improving the “agent surface area” across tools and deployment models, from better web chat controls (minimize/resume conversations plus token spend indicators) to JetBrains enhancements like Copilot Memory across chat sessions and Ollama BYOK. VS Code Insiders also pushed agent host flexibility by enabling Codex sessions with OpenAI/ChatGPT (or other providers) without requiring a Copilot sign-in, and community content unpacked how the Agents Window uses Git worktrees for parallel agent sessions.

On the platform side, GitHub's July 2026 availability report documented eight incidents across Actions, APIs, and auth, and it noted ongoing work to shift more production traffic onto Azure for capacity and regional resilience. Microsoft also published a practical Azure Monitor/ServiceNow integration pattern for keeping Monitor issues and ServiceNow ITOM/ITSM incidents synchronized, and Teams guidance covered interaction patterns (emoji reactions, threaded replies, quoted replies) so agents can participate in collaboration without spamming channels.