Weekly AI Roundup: Copilot LTS, routed models, and agent ops

Today by TechHub

This week focused on making AI coding and agent workflows easier to govern and operate at scale, from Copilot defaulting to GPT-5.3-Codex as an LTS-style baseline to task-routed “Auto” model selection in VS Code with clearer admin enforcement. Agents kept moving deeper into day-to-day delivery, with remote control for Copilot CLI sessions, one-click fixes for failing GitHub Actions, and more auditable cloud agent configuration via REST APIs. On the platform side, Microsoft Foundry and Azure patterns emphasized shipping and running agents like real services: persistent memory, evaluation for model routing, MCP catalogs and scalable tool servers, and LLMOps controls for RAG and self-healing deployments. Security guidance reinforced the same direction, with deterministic tool-boundary enforcement (FIDES) and CI-native red teaming and intent tracking (RAMPART and Clarity) so safety stays tied to code changes.

This Week's Overview

Copilot model governance and the shift to routed, task-based selection

Building on last week's focus on Copilot model churn and the need for planned cutovers under enterprise model policies, GitHub Copilot Business and Enterprise now default to GPT-5.3-Codex, replacing GPT-4.1, and GitHub is positioning it as the first Copilot long-term support (LTS) model with a 12-month availability window. That matters for enterprise rollouts because it reduces churn in model behavior, while still tying usage to premium request multipliers as GitHub moves toward usage-based billing and the GPT-4.1 deprecation timeline.

Model choice is also getting more dynamic in day-to-day developer flows. In VS Code, Copilot “Auto” model selection now routes based on the task, using real-time capacity and model health signals, and it adds visibility into which model was used plus admin policy enforcement. On the web, GitHub is tightening the selectable model set by removing all Gemini models and some other options, while keeping OpenAI and Claude models available across plans, which may simplify governance but can surprise teams that relied on specific providers.

At the same time, GitHub is still expanding model options in specific places: Gemini 3.5 Flash is rolling out as a selectable Copilot model (with an admin policy requirement for Business and Enterprise), and Copilot cloud agent added faster, cheaper options for “simple tasks” (Claude Haiku 4.5 and GPT-5.4-mini, both listed with a 0.33x multiplier). If you manage Copilot at scale, the practical takeaway is to review org policies and cost expectations together: “what models are allowed”, “what Auto can pick”, and “how billing multipliers apply” are now part of one combined governance surface.

Copilot agents get more mobile, more automated, and more auditable

Building on last week's theme that “agent mode” is becoming workflow plumbing (with stronger admin controls and new measurement signals), agentic workflows were a recurring theme this week, and the product changes point in three directions: controlling agents from anywhere, delegating more fixes to cloud agents, and improving admin visibility into how agents are configured. The shared thread is that “Copilot as a background worker” is becoming a normal part of both coding and operations, not just an interactive chat in an IDE.

Remote control for Copilot CLI sessions (now GA)

Following last week's Copilot CLI push toward enterprise-managed plugins and more standardized tool access, remote control for GitHub Copilot CLI sessions is now generally available on GitHub Mobile and github.com, with support also introduced for VS Code and JetBrains IDEs. The workflow is straightforward: start an agent session locally, then monitor and steer it from your phone or the web, which is useful when the agent is running longer refactors, tests, or PR steps and you want to intervene without staying at your desk.

For Business and Enterprise, the important detail is that remote control is gated by settings and admin policies (including the VS Code setting github.copilot.chat.cli.remote.enabled). If you have strict data-handling rules, treat this as a new “agent access path” to review alongside normal Copilot enablement, since it changes where and how developers can interact with active sessions.

Copilot cloud agent expands from code review fixes to CI fixes

Building on last week's emphasis on reviewing and validating agent output (and using richer code review metrics as feedback), GitHub continued to push “Fix with Copilot” into more of the pull request and CI loop. Copilot code review updates renamed “Implement suggestion” to “Fix with Copilot” and added a dialog where you can choose how fixes are applied (including model selection and extra instructions), plus a “Fix batch with Copilot” action to apply multiple review comments in one handoff to the Copilot cloud agent.

On the CI side, Copilot Business and Enterprise users can now trigger one-click fixes for failing GitHub Actions jobs via a “Fix with Copilot” button. The agent investigates the failure, pushes a fix to a branch, and requests review, which shifts the workflow from “read logs and patch manually” to “review an agent-proposed change” (and makes branch protections and review policies even more central).

Admin surfaces: auditing cloud agent configuration and stable metrics downloads

Following last week's theme that governance is moving closer to the tools themselves (for example via MCP server configuration and usage metrics APIs), as Copilot becomes more autonomous, GitHub is adding more ways to inspect configuration. A new public preview REST API lets you retrieve and audit a repository's Copilot cloud agent configuration, including MCP server settings, enabled tools, GitHub Actions workflow policy, and firewall configuration. That is a concrete step toward treating agent enablement like other security-relevant repo settings (auditable and automatable).

GitHub also migrated Copilot usage metrics report download URLs from Azure Front Door-based domains to stable GitHub-owned domains, with updated allowlist guidance for github.com (GHEC) and ghe.com customers. If your reporting pipeline or proxy allowlists were pinned to older domains, this is the kind of change that can silently break scheduled exports until network rules are updated.

Building and hosting agents: Foundry, Redis memory, and agent workflow patterns

Following last week's “running agents in production” thread (durability, orchestration patterns, and landing-zone governance), this week had a clear “how to actually ship agents” angle: persistent memory patterns, practical labs, and step-by-step hosting guidance. The common challenge across these resources is moving from a demo to a deployable service with repeatable evaluation, guardrails, and operational control.

Foundry Agent Lab and hosting guidance

Microsoft published a progressive Agent Lab for Microsoft Foundry that walks from “Hello World” to a self-hosted agent using the Responses protocol, covering tool patterns (function tools vs built-in tools), RAG with vector stores, MCP/Toolbox governance, and production-style wiring. Separately, a three-part livestream series focuses on deploying and hosting Python agents on Microsoft Foundry with both Microsoft Agent Framework and LangChain/LangGraph approaches, and it explicitly includes evaluation, guardrails, and red-teaming workflows.

A second thread in this space is “measure before you scale.” There is also an open-source eval pipeline for Azure AI Foundry's model router that helps you measure quality, cost, and latency, inspect routing distribution, compare runs, and optionally submit results back into Foundry's enterprise evaluation tooling. Taken together, the guidance is pushing teams toward treating routing and evaluation as first-class concerns, not something you bolt on after incidents.

Persistent memory with Redis Agent Memory (hands-on)

This also extends last week's validation and “trust layer” discussion into a harder setup: once you add memory, the agent's correctness depends on state carried across runs, not just a single prompt. A VS Code Live session demonstrated building AI agents with persistent memory using Redis Agent Memory, with GitHub Copilot used during implementation. The practical takeaway is that memory quickly becomes an integration problem: you need patterns for what gets stored, how it is retrieved, and how it is protected from poisoning or prompt injection, not just a database connection.

This also connects to broader agent evaluation work: memory makes agents stateful, which makes reliability across runs harder. Benchmarks and test harnesses that account for state (and not just single-turn prompts) are becoming more relevant as teams adopt “memory-enabled” agents.

Agent security and governance becomes more “engineering”, less “policy document”

Building on last week's shift-left guardrails (MCP-based secret and dependency scanning, plus landing-zone governance patterns), several posts this week converged on the same idea: agent security has to live in code, CI, and runtime controls, not in one-time guidance. The focus was prompt injection resistance, deterministic enforcement, and making red-teaming and design intent part of the repo so it can evolve with the system.

FIDES brings information-flow control to Microsoft Agent Framework (GA)

FIDES adds deterministic information-flow control to the Microsoft Agent Framework to block prompt injection and data exfiltration. The model is to label content and enforce per-tool policies before execution, using configurations like SecureAgentConfig and the idea of a quarantined LLM where untrusted content cannot directly influence sensitive tool calls.

For developers, this shifts the control point from “hope the prompt is safe” to “prove the tool invocation is safe.” It is especially relevant for agents that can run scripts, query internal systems, or operate on tickets and incidents, where the tool boundary is the real blast radius.

Stop prompt injection from hijacking your agent: new security capabilities in Agent Framework (FIDES)

Open-source safety tooling: RAMPART and Clarity

In the same way last week emphasized making agent behavior testable (instead of relying on reviewer vigilance), Microsoft open-sourced RAMPART and Clarity to make agent safety a continuous practice. RAMPART brings red-teaming scenarios into CI via pytest-based tests (including cross-prompt injection scenarios), while Clarity records design intent, failure analysis, and decisions as versioned artifacts in the repository (via a .clarity-protocol).

This is a practical response to a recurring problem with agents: teams change prompts, tools, and routing frequently, and safety assumptions drift. By putting red-team tests and design decisions next to the code, you can gate merges and review safety changes with the same workflows you use for functionality.

Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow

Governance packages and SRE discipline for agents

Following last week's focus on durable, governed deployments (Agent Framework patterns plus an Azure landing zone for agent sprawl), on the .NET side, Microsoft introduced Microsoft.AgentGovernance.Extensions.ModelContextProtocol (public preview), a .NET 8+ companion package for the MCP C# SDK. The promise is a single WithGovernance(...) builder extension that adds startup tool scanning, identity-aware policy enforcement, response sanitization, and audit/metrics, which helps teams standardize governance across many MCP tools and services.

For operations, guidance is moving toward explicit “Agent SRE” practices: Safety SLIs, autonomy and error budgets, behavioral circuit breakers, chaos experiments, replay debugging, and progressive capability rollouts. The message is that autonomous behavior needs the same production rigor as any other distributed system, with metrics exported into existing observability stacks instead of living in a separate agent dashboard.

MCP and API catalogs: wiring tools, scaling servers, and building AI gateways

Building on last week's MCP push that brought Azure operations and GitHub security scanning closer to the editor, a lot of teams are converging on MCP (Model Context Protocol) as the glue between agents and tools, and this week filled in several missing pieces: discoverability (catalogs), governance (policy layers), and scalability (running MCP servers like normal web services). The unifying idea is to treat “tools” as first-class deployable assets, not ad-hoc scripts.

Azure API Center portal (GA) as a catalog for APIs and AI assets

The Azure API Center portal is now generally available, positioned as a centralized catalog not just for APIs but also for AI assets like MCP servers and skills. It includes search, testing, and Visual Studio Code integration, and it supports access control via Microsoft Entra ID (or anonymous access where appropriate).

For agent builders, this is a pragmatic step: tool sprawl is real, and a searchable catalog lowers friction for reuse and governance. It also creates a more realistic path for enterprise teams to standardize on approved MCP servers and skills rather than letting every project wire tools differently.

Azure API Center portal is now generally available

Scaling MCP servers and building a framework-agnostic AI gateway on App Service

As last week's MCP servers expanded what agents can do (ARM operations and security scanning), two App Service-focused guides showed how to operationalize MCP at the scaling and gateway layers. One explains how MCP's stateless HTTP transport enables running MCP servers behind Azure App Service's load balancer, with a FastAPI sample that scales out across multiple instances and verifies distribution using Application Insights and k6 (and discusses considerations like ARR Affinity).

Another proposes a composable “AI gateway” reference architecture: run an agent and MCP server on Azure App Service, route all Azure OpenAI traffic through Azure API Management (APIM), and use policies for auth, semantic caching, token throttling, plus Application Insights metrics for chargeback. This is a concrete pattern for teams that want centralized control over spend and access while still letting application teams build with whichever agent framework they prefer.

Integrating VS Code agents with Azure DevOps via MCP

Following last week's emphasis that MCP is pulling real operational surfaces into the same agent session developers already use, a community guide walked through integrating a VS Code Copilot agent with Azure DevOps using an Azure DevOps MCP server. The key practical detail is that VS Code's MCP configuration becomes the entry point for tool enablement, and once configured, the agent can execute Azure DevOps actions through tools rather than through custom glue code.

This pattern matters because it makes “work item and pipeline operations” part of the agent's toolset in the same way that file edits and shell commands are today. For teams that already live in Azure DevOps, MCP offers a more consistent way to expose operations to agents while keeping policy and auditing in mind.

Integrating Azure DevOps with VS Code Agent using MCP (Model Context Protocol)

RAG and production LLMOps: scaling retrieval, reducing hallucinations, and shipping self-healing systems

Building on last week's theme of treating agents as production systems (with durability, governance, and validation that works under non-determinism), RAG (retrieval-augmented generation) content this week focused less on “how RAG works” and more on the failure modes you hit in production: large corpora, latency, and hallucinations that look confident. In parallel, App Service guidance is converging on concrete LLMOps patterns (metrics, rollbacks, chaos testing, and cost controls) that make agent behavior manageable.

Scaling RAG from thousands to millions of documents

One architecture deep dive outlined why RAG systems often degrade as document counts grow from 1,000 to 1 million. The fixes are mostly structural: better chunking, hierarchical or partitioned indexing, precomputed embeddings, caching, hybrid retrieval, and compression to stabilize both quality and latency.

If you are using Azure AI Search or similar retrieval backends, the key implication is that your “index strategy” becomes part of your model performance. Past a certain scale, you need deliberate design around how content is segmented and retrieved, not just larger embedding models.

When RAG Hits the Wall: Designing Systems That Scale from 1,000 to 1 million Documents

Confidence-aware RAG to avoid confident hallucinations

This ties directly to last week's validation thread (how to test agent behavior when there is no single correct output): a second guide proposed a “confidence-aware RAG” pattern aimed at reducing confident hallucinations in enterprise assistants. The approach combines retrieval score gating, citation validation, and an LLM-based abstention judge so the system can decline to answer when evidence is weak, implemented with Azure AI Search and Azure OpenAI.

This is a practical design pattern for regulated or high-trust scenarios: the goal is not to answer every question, but to answer reliably and show citations you can verify. Teams building internal assistants should treat abstention and citation checks as core requirements, not optional polish.

Confidence-Aware RAG: Teaching Your AI Pipeline to Acknowledge Uncertainty

App Service “self-healing agent” LLMOps patterns

A deployable reference sample showed how to run a self-healing LLM agent on Azure App Service with production controls: agent-specific SLIs, OpenTelemetry metrics flowing into Application Insights (with KQL workbooks), cost circuit breakers that can downshift models, chaos testing, and automated slot-swap rollback via alerts and a Logic App. It is a clear blueprint for taking “agent reliability” seriously using mechanisms teams already use for web apps.

In the same App Service vein, a debugging guide introduced new SSH helper aliases for Python apps on App Service for Linux and used a fault-injectable FastAPI sample to diagnose common issues that show up in AI apps (Azure AI Foundry/Azure OpenAI endpoint problems, DNS, managed identity, dependencies, ports, and latency). Together, these posts emphasize that LLM apps fail like normal cloud apps first (networking, identity, dependencies), and you need solid on-call ergonomics before you tune prompts.

IDE and platform updates: Visual Studio planning, VS Code agent workflows, and Azure AI operations

Building on last week's Copilot IDE work around agent usability and enterprise constraints (plus the broader push toward observability and control), this week's tooling updates were less about “new chat features” and more about making agent work predictable: plan first, route models intelligently, and improve observability and enterprise constraints (like air-gapped environments). In Azure, AI operations shows up as model routing, telemetry querying, and platform-level updates that affect how AI apps are deployed.

Plan agent in Visual Studio: planning as a first-class step

Visual Studio introduced a new Plan agent that helps developers draft and refine an implementation plan in Copilot Chat before handing off to Agent mode to make code changes. This tries to solve a common failure mode of agentic coding: agents can make changes quickly, but they can also take the wrong path if the plan is unclear or missing constraints (architecture, testing strategy, migration steps).

For teams, the practical benefit is process alignment: you can review a plan like you review a design note, then let Agent mode execute with better guardrails. It also pairs naturally with spec-driven workflows where planning artifacts are expected outputs, not just intermediate chat messages.

Plan Before You Build: Introducing the Plan agent in Visual Studio

Visual Studio Code 1.122 added updates to agent workflows, including remote task triggering and improved source control refresh. It also expanded language model tooling with a model picker and provider actions, and improved bring-your-own-key (BYOK) support for air-gapped environments.

Those changes matter if you are standardizing model access across teams or operating under network restrictions. Better BYOK and provider actions are what make “approved models only” and “self-hosted endpoints” workable in practice, instead of forcing developers into one subscription path.

Visual Studio Code 1.122

Azure Copilot Observability Agent Chat in the portal

This continues last week's observability-and-operations framing (agents as systems you run and measure), with Azure introduced a chat experience for the Azure Copilot Observability agent in the Azure Portal that lets you ask natural-language questions and translates them into queries across relevant telemetry sources. The point is to reduce the need to hand-write KQL (Kusto Query Language) for first-pass troubleshooting, while still supporting deeper investigation once the right signals are identified.

This fits a broader trend: “observability as conversation” is becoming a front door, but the actual system of record remains logs, metrics, and traces. Teams should still treat saved queries, dashboards, and runbooks as durable artifacts even if the first interaction is chat-based.

The Azure Copilot Observability Agent Chat - Stop Writing Queries, Start Asking Questions

Azure Update (May 22, 2026): Foundry routing plus platform changes that affect AI apps

John Savill's Azure Update (22nd May 2026) included multiple changes, but the AI-relevant thread is Azure AI Foundry role/model router updates alongside broad platform updates that impact AI workloads in production. Highlights include Azure Functions Flex Consumption, App Service TLS 1.0/1.1 retirement, and a mix of networking, storage, Event Grid, and database changes.

If you are shipping AI features on Azure, this kind of weekly platform sweep is worth scanning because “AI incidents” often come from platform shifts (TLS changes, networking limits, runtime behavior), not from model behavior. Treat it as part of your operational change feed.

Azure Update 22nd May 2026

Other Artificial Intelligence News

This week's remaining items cluster around ecosystem moves (open sourcing plugins, recognition reports), security case studies, and practical how-tos for teams adopting AI in real workflows.

GitHub Copilot for Eclipse is now open source under the MIT license, making the full plugin code available for community contributions and review. For Eclipse shops, that also means faster iteration is possible on features like Next Edit Suggestions (NES), agent mode, and Model Context Protocol (MCP) support, while giving security teams more transparency into how the IDE integration works.

GitHub Copilot for Eclipse is open source

Microsoft Research released MagenticLite alongside the MagenticBrain orchestrator model and the Fara1.5 computer-use model family, focusing on agentic performance with smaller model footprints and an execution harness with human-in-the-loop controls. In parallel, Microsoft Research described Vega, a low-latency zero-knowledge proof system designed for mobile-friendly, repeated, unlinkable presentations, with implications for privacy-preserving identity verification in agent workflows.

Microsoft Threat Intelligence published a deep technical look at Kazuar's evolution into a modular P2P botnet attributed to Secret Blizzard, including operational behaviors and mitigation using Microsoft Defender controls, with Security Copilot referenced for investigation and response. A separate report detailed Fox Tempest, a malware-signing-as-a-service operation that abused Microsoft Artifact Signing to issue short-lived certificates used to distribute signed malware and ransomware, including IOCs and mitigation guidance.

For organizations rolling out AI broadly, Microsoft shared security foundation case studies from St. Luke's and ManpowerGroup, centered on unifying SecOps visibility with Defender and Sentinel and applying governance and Zero Trust practices, including SOC workflow automation with Microsoft Security Copilot. The May 2026 security roundup also included Purview DSPM GA, Purview Data Security Investigations enhancements (including OCR and custom examinations), Entra ID account recovery, and Windows 365 for Agents in public preview alongside Microsoft Agent 365.

On the implementation side, following last week's integration-modernization thread (Logic Apps Migration Agent), Azure Logic Apps added Code Interpreters, letting LLM-driven workflows generate and execute JavaScript for tasks like CSV parsing and business validations, with notes on Standard vs Consumption architecture (including Integration Account requirements for multi-tenant isolation in Consumption). There was also a practical benchmark-oriented post on reducing LLM cold starts by streaming model weights from Azure Blob Storage into GPU memory with Run:AI Model Streamer, reporting up to ~6x faster cold starts vs the default vLLM loader and showing how to use az:// URIs with vLLM and SGLang.

Finally, several resources focused on bringing agent workflows into everyday engineering practices, extending last week's message that agents need operational process (plans, review gates, metrics) as much as they need better prompts: GitHub recognition in the 2026 Gartner Magic Quadrant for Enterprise AI Coding Agents, a spec-first “Agentic-Agile” workflow using Issues/PR gates and CI/CD, and a collection of practical prompts for Copilot CLI-driven Linux operations on Azure (VM provisioning, app deployment, and observability setup with Ansible and Azure Monitor tooling). There were also community demos on modernizing legacy .NET apps with Copilot agents and using VS Code Agents with the MSSQL extension to build AI apps with vector search and OpenAPI-driven iteration.