Weekly Azure Roundup - Durable Agents, Guardrails, and Tracing

by TechHub

This week's Azure roundup focuses on what it takes to run AI agents reliably in production: durable execution, clear guardrails, and better day-2 visibility. Highlights include a durable pattern for MCP Tasks on App Service, built-in OpenTelemetry tracing for Functions Agents, and an approval-gated operations assistant architecture that keeps humans in control of write actions. We also cover Kubernetes isolation with Kars, broader model choice through Azure AI Foundry (including Fireworks AI GA), and practical guidance on evaluation and red teaming with Foundry and PyRIT.

This Week's Overview

Agentic apps and AI operations on Azure

This week had a clear theme: making AI agents more practical to run in production by improving durability, guardrails, and day-2 visibility. Building on last week's “Path to Production for Agents” thread (tooling, delegated auth, and GA observability), the updates here fill in more concrete patterns for durable execution, approval-gated change, and trace-level insight across App Service, Functions, and Kubernetes.

Durable MCP Tasks on Azure App Service

If you are building with Model Context Protocol (MCP) Tasks on Azure App Service, the key guidance is to stop treating a task like an in-memory workflow tied to a single instance. The recommended pattern separates task state (Azure Table Storage) from execution (Azure Service Bus), so tasks can survive restarts, scale-out, and reconnects while maintaining a single source of truth for progress and decisions.

Practically, this enables long-running flows like human approvals, cancellations, and retries without risking duplicate work when an App Service instance rotates. The guide also leans on managed identity for storage and messaging access so the same approach works in production without shipping connection secrets.

“Zero Ops” with Azure SRE Agent (agents operate, humans govern)

The “Zero Ops” operating model described this week formalizes how to let agents do investigation and remediation while keeping humans in control of outcomes, which lines up with last week's emphasis on governable agent operations (approval gates, least privilege, and auditable actions). The post frames it as scoping what the agent is allowed to touch, ingesting the right operational context, then packaging repeatable capabilities as artifacts (skills and custom agents) that can be triggered safely.

The most actionable part is the layered control model: managed identity for auth, Azure RBAC for permissions, plus policies, hooks, and evaluation (eval) gates to constrain tool access and verify behavior. If you are pushing toward higher autonomy, this provides a blueprint for adding guardrails before you hand an agent write access to production systems (and for keeping a review trail when it acts via Infrastructure as Code).

Built-in OpenTelemetry for Azure Functions Agents

Azure Functions Agents now include built-in OpenTelemetry tracing that emits structured agent-run traces into Application Insights without requiring you to write custom telemetry, building on last week's GA momentum for agent observability in Azure Monitor. That matters most when an agent fans out across tools and models, because you can inspect a single session trace end-to-end instead of stitching logs together manually.

A notable example in the post is making Azure AI Foundry Model Router decisions visible per prompt inside the trace. For teams debugging cost, latency, or unexpected tool usage, having model-selection and agent-step timing show up in the same distributed trace makes it much easier to pinpoint where behavior diverges from expectations.

Markdown for Agents in Azure App Service (public preview)

Azure App Service (Windows) added a public preview feature called “Markdown for Agents” that can convert HTML responses to Markdown when clients request it, extending last week's theme of making agent integrations more production-friendly by reducing parsing friction and token overhead. The idea is straightforward: Markdown often reduces token overhead and improves downstream LLM parsing compared to scraping HTML.

Enablement can be done via Azure REST API, ARM/Bicep, or az rest, and clients can request Markdown using the HTTP Accept: text/markdown header. If you run agent-facing endpoints (status pages, docs-like responses, or operational summaries), this is a low-effort way to make outputs more agent-friendly without changing your application rendering stack.

Running multi-agent workloads safely on Kubernetes with Kars

Kars was introduced as an open-source Kubernetes reference stack aimed at running multi-agent workloads with stronger isolation and governance, a natural continuation of last week's AKS governance thread around Kubernetes-native policy enforcement. Its core design choice is “pod as trust boundary”, with an in-pod router enforcing identity, egress policy, content safety, token budgets, and tamper-evident audit logging, targeting deployments from local clusters through AKS.

For platform teams, this is a concrete set of controls you can map to cluster policy: enforce network egress via Kubernetes NetworkPolicy, keep per-agent token budgets, and produce an audit trail that is harder to tamper with than app logs. It also ties into Azure identity (Microsoft Entra ID) and MCP integration, which helps when your agents need controlled access to enterprise tools.

End-to-end agent platform: Foundry Agent Service GA (build, run, distribute)

Microsoft's agent platform story continued with a GA-focused walkthrough using the FibreOps reference implementation, picking up from last week's run of Foundry and Agent Framework building blocks (canvas design, delegated auth, harness runtime, and monitoring). The post walks through: build with the Microsoft Agent Framework and GitHub Copilot SDK, run hosted agents in Microsoft Foundry Agent Service, then distribute them into Teams and Microsoft 365 Copilot. The post also calls out platform pieces like Agent Optimizer, Routines, Foundry IQ, and OpenTelemetry support, which collectively cover packaging, operation, and telemetry in one stack.

If you are deciding whether to host agents yourself or use a managed runtime, the key takeaway is the “build-to-distribute” path: you can develop agents with standard SDKs, deploy them as hosted services, and then make them available where users already work. That distribution story matters as much as model choice when adoption depends on running agents inside collaboration tools with enterprise identity and governance.

Approval-gated operations assistant reference architecture

A practical reference implementation showed how to build an operations assistant that does not directly execute write actions until an authenticated user approves them, echoing last week's focus on production guardrails like approvals and auditable change paths. The design uses Azure OpenAI plus Azure AI Search for runbook-grounded responses (RAG), then introduces a pending-action flow so the assistant can propose changes but only apply them after confirmation.

For production ops scenarios, the important details are the identity boundary (Microsoft Entra ID), the use of managed identity for downstream resource access, and the emphasis on idempotency so “approve” does not translate into repeated changes. This fits well with the broader governance theme: agents can accelerate investigation and preparation, but execution should be explicitly authorized and auditable.

AI red teaming: choosing Foundry vs PyRIT

On the security side for AI apps, a comparison this week clarified where Microsoft Foundry's managed evaluation and red teaming features are enough, and when you should reach for PyRIT, continuing last week's “from prototype to production” emphasis by putting testing rigor alongside tooling and observability. The dividing line is mostly about control: Foundry and Azure OpenAI evaluation works well for managed workflows and standard testing, while PyRIT becomes useful when you need custom endpoints and bespoke orchestration for agent or application attack paths.

If you are building RAG systems or tool-using agents, this helps frame your testing plan around likely failure modes like prompt injection and retrieval manipulation. Use managed eval where it fits, but plan for PyRIT-style custom harnessing when you need to simulate your exact toolchain and threat model.

Expanding model choice on Azure AI Foundry (Fireworks AI GA for startups)

Microsoft also pushed model optionality with the general availability of Fireworks AI on Azure AI Foundry, which complements last week's expansion of model options (including first-party MAI and the Mistral partnership) by showing a concrete deployment blueprint. The architecture is Azure-native and aimed at startups, focusing on deploying and scaling open-model inference with governance, billing, and observability in Azure, calling out services like Azure Container Apps and Azure API Management.

For builders, this is mainly about keeping “choice of model” and “operational control” together: you can run open models while still integrating with Azure controls for identity, routing, and monitoring. It is a useful reference if you need to standardize how teams deploy inference endpoints without hand-building platform plumbing each time.

Modernization workflows: Copilot + Azure (Gartner Magic Quadrant mention)

Microsoft highlighted being named a Leader in Gartner's 2026 Magic Quadrant for AI-augmented code modernization tools, positioning GitHub Copilot modernization plus Azure as an agentic workflow that fits the same “humans govern” production posture discussed in last week's agent governance guidance. The described flow centers on assessing legacy apps, upgrading dependencies, and migrating workloads with developer review, automated testing, and security checks rather than “one-click” rewrites.

The practical angle is the framing of modernization as a pipeline: use tooling (including a Modernize CLI) to generate and validate change sets, then keep humans in the loop to review PRs and test results before rollout. If you are planning upgrades or migrations, this reinforces that agentic assistance is most useful when it plugs into existing SDLC controls.

Using the “four IQs” with MCP endpoints in Python agents

Pamela Fox shared a resource pack around “Web IQ, Work IQ, Fabric IQ, and Foundry IQ”, focusing on how to integrate these context sources via MCP endpoints into Python agents built with the Microsoft Agent Framework, building on last week's MCP momentum (Toolboxes delegated auth and APIM fronting MCP servers). The material connects the dots from retrieval (for example, Azure AI Search and OneLake) to deployment on Foundry Agent Service.

If you are building multi-source agentic retrieval, the main benefit is having a repeatable pattern for adding new context providers without tightly coupling your agent logic to each backend. MCP acts as the contract, which can keep your agent code cleaner while you iterate on data sources and governance.