Weekly Azure Roundup: Operability, Agents, and Safer Delivery

by TechHub

This week's Azure updates focus on making platforms easier to run, easier to govern, and safer to change. Plan for an action-required Azure Monitor Workspace shift to spec-compliant PromQL regex matching, and take a look at Azure Policy custom policy versioning to roll out guardrails with less risk. On the build-and-ship side, guided Copilot flows in VS Code, GA TLS improvements for Functions Flex Consumption, and Durable Functions-based dynamic workflows show a move toward repeatable delivery and long-running orchestration. The agent story gets more concrete too, with MCP hosting and tool-call governance patterns, Foundry setup and observability guidance, and Databricks pushing continuous evaluation and retention controls as standard production hygiene.

This Week's Overview

Azure Monitor and Governance Changes You Need to Plan For

Building on last week's theme of “operable and cost-aware” platforms (especially around observability costs and governance guardrails), Azure Monitor Workspace (AMW) is changing how PromQL regex matchers behave: the Prometheus Query Service is becoming spec-compliant by fully anchoring regex matches. If your dashboards or alerts rely on partial matches (common with =~ matchers that were effectively unanchored), you can see query results change, which makes this an “action required” item rather than a quiet behavior tweak.

Microsoft also outlined how to update matchers to preserve common intent patterns (for example, switching to explicit .* prefixes/suffixes where you truly want substring matching). The same post walks through moving AMW to query engine version 2.0, which is the lever that brings the spec-compliant behavior into effect.

On the governance side, Azure Policy is adding custom policy versioning in public preview. Versioning lets you keep multiple versions under one definition ID and pin assignments to major/minor versions, which makes policy rollout and rollback safer in large environments where you cannot flip every assignment at once.

Building and Shipping Azure Apps with Copilot and Functions

This week showed a clear push toward more structured “agent-assisted” Azure app delivery, from local scaffolding all the way through deployment and workflow execution. The common thread is making guided flows reproducible, observable, and safer to operate than free-form prompting.

Guided Copilot experience in VS Code for Azure app scaffolding and deployment

Following last week's focus on repeatable environment design and GitOps-style workflows (APIOps CLI and azd-driven deployment patterns), a preview “guided Copilot” experience in VS Code adds staged steps for building Azure apps, including scaffolding, local setup, and deployments using az and azd (Azure Developer CLI). The flow highlights resource summaries and cost estimates, which helps teams catch expensive defaults before they get deployed, especially when templates spin up multiple managed services.

Because it is staged, it is easier to standardize within a team (and to document) than a purely conversational workflow. If you already use azd for environment definitions and repeatable deployments, this looks like it is aiming to reduce the “tribal knowledge” gap for new repo contributors.

Azure Functions Flex Consumption: GA support for certificates and end-to-end TLS

This continues last week's hybrid-and-edge operability thread (Arc certificate management GA and “keep the evidence” observability guidance) by tightening the TLS and rotation story for serverless endpoints. Azure Functions Flex Consumption now supports site-scoped certificates and end-to-end TLS encryption in GA. The release covers multiple certificate sources (Key Vault, managed certs, and uploads) and includes infrastructure-as-code guidance, which matters if you need consistent configuration across slots/environments.

The practical win is being able to run stricter inbound/outbound TLS patterns (including mTLS where applicable) without bolting on extra edge components purely for certificate handling. The post also calls out certificate rotation considerations, which is where many teams get surprised during renewals.

Dynamic Workflows for Azure Functions hosted skills (Durable Functions)

Building on last week's agent-operability guidance (tool-call governance, audit readiness, and evidence you can trace), Dynamic Workflows for Azure Functions hosted skills show how to run AI-generated, multi-step plans using Durable Functions. The point is to let a plan keep executing beyond the original request, with durable state, timers, and parallel steps, instead of forcing everything into a single synchronous call.

If you are building “skills” that need approvals, retries, or long-running orchestration, this pattern gives you a more debuggable execution model than a monolithic agent loop. It also encourages you to treat the plan as an orchestrated workflow (with state and history) rather than only prompt text.

Securing and Operating MCP (Model Context Protocol) and Agent Tooling on Azure

This picks up directly from last week's “secure agent infrastructure” and egress-lockdown storyline by translating those guardrails into concrete MCP hosting and tool-call mediation patterns. A lot of agent architecture is now converging on MCP (Model Context Protocol) as the glue between a coding assistant (like Copilot) and enterprise tools. This week had several posts that collectively focus on the hard parts: hosting patterns, identity, authorization, and tool-call governance.

Secure MCP hosting patterns: containers/Kubernetes vs APIM fronting

Rob Bos broke down the security and governance risks of running MCP servers and compared two common patterns. One pattern centralizes an MCP Gateway running in containers or Kubernetes, and another fronts MCP endpoints with Azure API Management (APIM) while using Azure API Center as a private registry for discoverability and governance.

The write-up flags real gaps teams will hit early, especially per-user OAuth and session-aware routing, which become blockers when you need user-specific permissions and auditability. If you are piloting MCP internally, it is a useful checklist for what your platform team must solve before broad rollout.

Identity and authorization for agent tool calls: “Agent Control Loop” on Azure

This extends last week's recurring theme that agents need platform controls (not prompt trust) by formalizing tool calls as an auditable control plane with Entra ID, RBAC/Policy, and APIM as enforcement points. A separate guide proposed an “Agent Control Loop” framework that treats tool calls as a chain of handoffs with explicit controls: identity validation, retrieval permissions, tool-call authorization, execution constraints, and outcome verification. It maps cleanly to Azure building blocks like Entra ID for identity, RBAC/Policy for authorization, managed identities for workload credentials, APIM for mediation, and Azure AI Search security trimming for least-privilege retrieval.

The practical takeaway is that “the model decided to call a tool” is not an acceptable trust boundary by itself. You need to validate inputs, constrain what the tool can do, and verify results in a way that can be audited, which is where patterns like APIM policies, request signing, and per-tool authorization become central.

Bringing agents to private workloads (Azure VMware Solution) with per-workload MCP servers

After last week's “Private Endpoint is only half the story” egress and isolation reminder, this reference architecture grounds the same lesson in a concrete hybrid path for AVS. A reference architecture showed how to connect Azure AI Foundry agents to private Azure VMware Solution (AVS) workloads using per-workload MCP servers hosted on VNet-integrated Azure Container Apps. The design leans on ExpressRoute, private endpoints, and managed identity plus Key Vault so agents can access private systems in a read-only, tightly scoped way.

The emphasis on per-workload MCP servers is important: it reduces blast radius and makes it easier to apply workload-specific policies and secrets. If you need agents to read operational data from isolated environments, this pattern is a concrete starting point that does not require exposing internal endpoints publicly.

Microsoft Foundry and Agent Engineering: Setup, Harnesses, Observability, and Real Architectures

Building on last week's Foundry GA push (GPT-6 Astra in Foundry) and the “make agents governable” guidance (context engineering, egress control, and secure runtimes), several posts this week filled in the practical “agent engineering” layer: how to bootstrap a dev environment, how to build an agent harness with guardrails, and how to trace and evaluate agents so you can detect incorrect outcomes (not just uptime).

Foundry Dev Pack and building a C# agent harness

Foundry Dev Pack is positioned as a one-command setup for a Microsoft Foundry development environment, bundling terminal, VS Code, and coding-agent tooling (including Azure CLI and azd). For teams onboarding multiple developers, a repeatable setup story reduces environment drift and makes workshops and internal templates easier to maintain.

In parallel, the MafClaw live series outlines building a C# AI agent harness with the Microsoft Agent Framework, moving from a minimal IChatClient wrapper toward production needs like tool approvals, memory, safe file access, observability (OpenTelemetry), evaluations, and deployment to Microsoft Foundry. The value here is the sequencing: you can adopt the harness incrementally rather than treating “agent platform” as a single big-bang build.

Observability for agents: traces, evaluations, and Azure Monitor integrations

This follows last week's emphasis on using observability as evidence (including lower-cost log tiers) by applying the same mindset to agent correctness, not just availability. A Foundry observability deep-dive argued that agents can look healthy in traditional monitoring while still producing incorrect outcomes. The recommended approach combines Microsoft Foundry traces and evaluations with Azure Monitor (Application Insights and Log Analytics), using OpenTelemetry for tracing and KQL (Kusto Query Language) to investigate failures, drive alerts, and run continuous evaluation.

This lines up with the broader theme from Databricks posts this week (see below): you need feedback loops that score behavior over time, not just logs. For teams building tool-using agents, this is the difference between “it runs” and “it stays correct as prompts, tools, and data change.”

Applied architectures: Foundry + Fabric + D365F&O, and recruiter search compilation

Foundry IQ with D365F&O and Fabric IQ described a retail decision-support architecture where Azure AI Foundry orchestrates reasoning across Microsoft Fabric (Fabric IQ plus an ontology), Dynamics 365 Finance & Operations via an ERP MCP server, SharePoint policy documents, and Web IQ. Azure AI Search sits underneath to ground responses and route retrieval, which is the practical backbone for any multi-source “reasoning” story.

A separate architecture focused on “closing the recruiting context gap” by turning job descriptions into recruiter-reviewable Boolean searches while preserving required vs preferred intent. It used structured outputs, provenance for terminology, and an explicit approval step, plus tracing and Application Insights to detect meaning drift during evaluation.

Copilot + Foundry agent customization workflows (video demos)

Two Microsoft Developer videos demonstrated hands-on flows for building and improving hosted agents directly from the GitHub Copilot Chat window using Foundry Canvas. The demos emphasize best-practice gap checks, Copilot-suggested fixes, observability upgrades, and validating outcomes with Agent Inspector, which is a recurring theme across the Foundry content: treat agent changes like code changes that require inspection and testing.

One video framed it bluntly: use an agent to refactor an agent, then prove the refactor improved reliability through inspection and observability rather than trusting the rewrite. That is a useful pattern for teams accumulating prompt debt and tool sprawl in early agent prototypes.

Azure Databricks: Monitoring Agents and Tuning Retention Costs

This week's Databricks updates echo last week's Azure-wide theme that observability and spend controls are becoming default expectations for AI and platform work (from APIM AI Gateway budgets to cheaper logs kept as investigation evidence). Databricks content this week centered on production hygiene: continuously evaluating agent behavior, improving incident response with agents, and controlling how long system data sticks around. The thread connecting these posts is that “agent features” become operational features once they reach production.

Continuous evaluation for Genie agents (benchmarks, scoring modes, and monitoring loops)

A Databricks post argued that a data agent that never gets re-evaluated is effectively a production model with no monitoring. It breaks down Genie Agent Benchmarks, contrasting SQL-based scoring in Chat mode with an LLM-judged Agent mode, and then ties that to workflows for monitoring and improving agent behavior using Genie Code.

For teams deploying SQL or data agents, the key idea is to treat evaluation as a continuous process with repeatable scoring. That lets you detect regressions when underlying data changes, prompts drift, or tool behavior shifts.

AI-assisted incident investigation (“AI SRE”) and required guardrails

Another Databricks write-up described an internal “AI SRE” approach: run deterministic platform checks and version-controlled runbooks in parallel, then have an LLM synthesize evidence into recommendations. It also calls out the non-negotiables when agents query production observability systems, including rate limits and scoped permissions.

This is a good reminder that incident-response agents should not start from “ask the model what happened.” They work best when you first collect consistent evidence through deterministic checks, then use the model for synthesis and next-step suggestions.

Configurable retention for Databricks system tables (beta)

Databricks also introduced beta support for configurable retention on supported system tables, with a range of 30 to 3,650 days. You can set st_retention through the Databricks Account Settings API, and the post explains default behavior, grace periods when reducing retention, and an expected cost model beyond 395 days once GA arrives.

For governance and FinOps, this turns retention into an explicit policy choice rather than a fixed platform decision. The trade-off is straightforward: longer retention helps audits and investigations, but it can increase costs, so you should align retention with your compliance windows and incident-response needs.

Genie in Slack: chart images in responses (public preview)

Genie in Slack can now render chart visualizations as images in public preview instead of returning text-only output. Existing Slack app installations need to be reinstalled to grant the files:write permission, and the post includes a SQL query to audit Slack-originated Genie requests.

The operational detail matters here: updating Slack permissions is a change-management task, not just a feature toggle. If you have strict Slack app approval processes, plan for the reinstall step before users start asking why the new visualization feature does not show up.

Infrastructure Automation: Images, Scale Sets, Private DNS, and Redis Capacity

This extends last week's “platform engineering is the differentiator” thread (environment boundaries, RBAC design, and treating configuration as code) by focusing on repeatable infrastructure delivery and reducing operational unknowns. A cluster of practical infrastructure guides focused on repeatability and safety: deterministic VM images, controlled rollouts, multi-tenant DNS automation, and making “capacity hunting” scripts less fragile. These are the kinds of building blocks that reduce operational surprises over time.

One guide described an image-delivery pipeline that bakes a single deterministic VM image with Packer, publishes it to Azure Compute Gallery, then validates the published version by spinning up a temporary VM. It emphasizes publishing evidence and promoting only approved versions, which aligns well with release gates and audit needs.

A related tutorial showed how to deploy applications to Azure Virtual Machine Scale Sets (VMSS) using immutable, versioned images in Azure Compute Gallery released through Azure DevOps CI/CD. It covers rolling upgrades and rollback, plus practical security advice such as using service connections or managed identity and storing secrets in Azure Key Vault.

Automating Private Endpoint DNS across tenants with Azure Policy + Lighthouse

This builds directly on last week's warning that Private Endpoint alone does not equal secure connectivity by tackling the next failure mode teams hit at scale: name resolution and cross-tenant operations. Another post proposed a design for automating Private Endpoint DNS registration across multiple Entra tenants by combining Azure Policy DeployIfNotExists with narrowly scoped Azure Lighthouse delegation. The idea is to centralize Private DNS zones while still supporting multi-tenant operations, using managed identities and workload identity federation (OIDC) to reduce credential sprawl.

The phased approach and validation steps are useful if you have grown into multiple tenants and now need consistent Private Endpoint name resolution without manual DNS record work. The security considerations (scope minimization, identity design, and controlled delegation) are the difference between “automation” and “a new cross-tenant risk.”

Managed Redis capacity acquisition with bounded retries

A PowerShell “capacity poller” pattern was shared for Azure Managed Redis that cycles through approved region/SKU combinations with bounded retries, persists state between scheduled runs, and uses exit codes and logging for automation and troubleshooting. This addresses a real operational pain point: capacity availability can be inconsistent, and naive retry loops can run forever or create noisy failures.

If you are automating provisioning, the bounded-retry and persisted-state approach makes runs idempotent and easier to reason about. It also encourages you to explicitly encode which regions/SKUs are acceptable, rather than letting a script pick whatever happens to succeed first.

Platform Updates: OpenShift Hosted Control Planes and AI Performance Benchmarks

This continues last week's “hybrid fleets are becoming managed fleets” storyline (Azure Arc expanding what can be operated from Azure) while also reinforcing the agent-and-inference thread with more concrete performance signals. Two platform-focused updates landed this month that are worth tracking if you run Kubernetes at scale or care about inference throughput on Azure. They speak to operational ownership boundaries (for OpenShift) and what current GPU platforms can deliver (for inference).

Azure Red Hat OpenShift hosted control planes (public preview)

Azure Red Hat OpenShift (ARO) hosted control planes are now in public preview, moving the OpenShift control plane into a Microsoft-managed service while keeping worker nodes in the customer subscription. The post highlights operational benefits and Azure integrations like Entra ID, Key Vault, Azure Monitor, and Customer Lockbox, plus supported regions and preliminary pricing.

For OpenShift operators, the main implication is shifting part of the operational burden (and responsibility) to Microsoft while retaining control over the compute plane that runs workloads. It is also a change in how you think about upgrades, support boundaries, and where cluster-critical components live for compliance and network design.

Azure MLPerf Inference v6.1 results on NVIDIA GB300/GB200 NVL72

Azure published MLPerf Inference v6.1 results for DeepSeek-R1 on NVIDIA GB300/GB200 NVL72 systems, covering Interactive, Server, and Offline scenarios with 18-node and 72-node submissions. For teams planning large-scale inference, these results provide a more comparable signal than vendor-specific benchmarks because MLPerf standardizes methodology.

The details matter most when you are mapping scenario type to workload: interactive latency-sensitive paths behave differently than offline batch throughput. If you are evaluating hardware generations or cluster sizes for MoE (Mixture-of-Experts) style models, the 18-node vs 72-node submissions help illustrate scaling behavior.

Other Azure News

John Savill's weekly update (Sept 18, 2026) rounded up a wide set of changes across Azure services, including AKS, Azure Red Hat OpenShift, and Application Gateway support for HTTP/3 over QUIC, plus AVNM mesh and multiple data and desktop updates. If you track Azure service motion week-to-week, this is a useful catch-all view to sanity-check what might impact your own roadmaps.

Azure Confidential Clean Rooms highlighted multiparty analytics for advertising use cases like audience matching and campaign measurement, using Spark SQL queries executed in a Trusted Execution Environment (TEE) with verifiable governance. In parallel, there were several BizTalk posts this week that put migration planning back in focus, including a lifecycle update (mainstream to 2028, extended to 2030) and a decision matrix for choosing between coexistence, domain-by-domain migration, or replacement.

Two additional operational notes are worth bookmarking: one troubleshooting post explained how Azure API Management custom-domain validation can break during certificate renewal when APIM sits behind Front Door, Traffic Manager, or Application Gateway, and it recommends moving TLS termination to the edge plus using a Key Vault sync checklist. Another guide explored using Azure SRE Agent with Azure Managed Grafana's MCP endpoint so agents can treat dashboard panels, variables, and descriptions as executable context, with concrete KQL examples against Application Insights telemetry.