Blog Posts

Your Azure Operations Stack Has More AI Than You Think. Are You Using It?

Executive Brief

• The thesis: Azure operations AI comes in three classes: detection that stops at the alert, an AI investigation agent that advises, and an agent that can act. Before buying another AI observability platform, check whether the first two, already available in Azure, are switched on, tuned, and owned. 
• The stakes: In observability vendor Grafana Labs' 2026 survey of 1,363 practitioners and technology leaders, 30% named alert fatigue as their biggest obstacle to faster incident response, and complexity was their top concern (38%). Adding a platform is not an obvious cure for either.            
• The key evidence: Microsoft's own documentation ties results to preparation. Dynamic thresholds need three weeks of history to learn weekly patterns, and the Observability Agent's accuracy "depends on whether your application emits complete telemetry."  
• The proof so far: Early results are promising, but Microsoft published them. KPMG reports an estimated 250 engineering hours a month reclaimed with the Observability Agent; Ecolab reports daily alerts falling from 30–40 to under 10 with SRE Agent.  
• The recommendation: Audit coverage, tuning, ownership, evaluation, and cost before any procurement decision, and budget for agent charges, which include an always-on fee for SRE Agent.

Picture a CIO reviewing a proposal for an AI observability platform that promises to cut alert noise. At the same time, the monitoring stack the company already runs includes machine-learning detection nobody has tuned. The scenario is hypothetical; the pressure behind it is not. In Grafana Labs' 2026 Observability Survey, 30% of respondents named alert fatigue as their biggest obstacle to faster incident response, the most common answer.

For enterprises on Microsoft Azure, part of the answer may already be in your subscription. Azure Monitor includes anomaly detection that learns what normal looks like, and Microsoft made the Azure Copilot Observability Agent generally available in June 2026. Our reading of Microsoft's documentation is that what these capabilities deliver depends less on the features than on telemetry coverage, tuning, and ownership. That is the work to audit before signing another contract, and this article covers audits about AI built into Azure for monitoring and incident response, not Azure’s AI development services.

Before that audit, one distinction matters. Microsoft’s pages describe three kinds of AI in Azure operations; we group them into three classes that differ in what they do, where they stop, and how they are billed.

• Azure Operations AI Comes in Three Classes, and Each Stops Somewhere Different

Microsoft’s documentation describes three kinds of AI for detecting and responding to incidents. The grouping/classification is our interpretation; the boundaries of each class come from Microsoft’s own pages. Azure Monitor has two built-in layers: detection (dynamic thresholds and Smart Detection) and AI-assisted investigation (the Observability Agent, which Microsoft’s Azure Copilot provides access to). Its usage is billed separately from Monitor’s alert charges.”

Azure Monitor’s native anomaly detection (dynamic thresholds and Smart Detection) learns normal ranges and alerts on deviations. It stops at the alert and carries Azure Monitor’s usual alert-rule charges. Monitor’s Azure Copilot Observability Agent, billed by usage in Azure Agent credits,  groups related alerts into issues (preview), investigates, and suggests mitigations, but doesn’t make changes to the environment.

Adding the Azure SRE Agent, a separate service, enables starting on an alert, finding a probable root cause, and opening tickets. The agent can suggest remediation steps or, when configured, execute mitigations, with always-on plus usage charges.

 

Read through the stages. Native detection covers only the first stage. The Observability Agent stops before the human check. Only the SRE Agent performs remediation, and only when configured to.

• Why Businesses May Need Additional Service

Once configured well, one documented need goes beyond what the Observability Agent does and justifies adding the Azure SRE Agent. The other depends on how far your incidents reach beyond Azure.

• Enterprises need actions, not answers

Even in its autonomous operations (preview), the Observability Agent produces issues, not actions. It can correlate alerts, conduct autonomous triage and investigation, provide explanations and suggestions, and create Azure Monitor issues, but doesn’t make any changes to the environment, which is where the SRE Agent comes in.

The SRE Agent is a separate service with its own always-on charge and can carry out autonomous incident response, diagnosis, orchestration, and controlled operational response. The agent’s action-oriented nature allows users to carry out root-cause analysis, create custom agents & use runbooks, and execute approved or autonomous mitigations within configured guardrails. Microsoft describes the SRE agent’s remediation model as ranging from human-reviewed recommendations to fully automated responses.

• Some incidents reach beyond Azure telemetry

The Observability Agent works from Azure data the signed-in user is authorized to access; the pages we reviewed do not say how it handles systems outside Azure.

SRE Agent documentation mentions connectors for third-party monitoring tools such as Datadog, Dynatrace, Splunk, and New Relic, plus MCP servers for other systems. It acts through its own managed identity, which reaches the resource groups or subscriptions granted to it. Our reading is that if your incidents regularly cross tools Azure Monitor doesn’t cover, that reach is the case for adding it.

To test it, list the tools your last ten incidents touched and count how many sit outside Azure Monitor.

Note for CISO: An active response plan is necessary for the SRE Agent to act against relevant Azure Monitor incidents. However, agent run mode in such response plans defaults to autonomous. Microsoft suggests spending 2 to 4 weeks in Review run mode first.

• Owning these features is not the same as using them

Each capability has preconditions, and Microsoft's documentation is candid about them.

• Dynamic thresholds will not fire until they have three days and at least 30 samples of data. They use 10 days of history to learn daily patterns and need three weeks to detect weekly ones. Microsoft also says they are built for significant deviations: slow behavior changes "probably won't trigger an alert," and they cannot be used in rules that monitor multiple conditions (Microsoft Learn). 
• Smart Detection needs a minimum volume of telemetry and 24 hours of learning before Failure Anomalies can alert, and Microsoft warns that the reasons it fires or stays quiet "aren't always deterministic."  
• The Observability Agent depends on preparation too. Microsoft's best-practice guidance states that "the accuracy of the investigation depends on whether your application emits complete telemetry, preserves correlation fields, and includes sufficient service and resource context." It also notes that the agent does not collect resource logs by default; they must be enabled resource by resource.  
• For new applications, Microsoft advises OpenTelemetry-based instrumentation, and it warns that overriding standard correlation fields such as OperationId “breaks distributed tracing and investigation accuracy.”  
• Azure SRE Agent has preconditions of its own: if no resource groups are assigned when it is created, “the managed identity has no permissions ”.  

Taken together, our reading is that the gap between owning these capabilities and benefiting from them is operational. Someone must choose:

• Which metrics deserve dynamic thresholds,
• Confirm that applications send enough telemetry,
• Enable resource logs,
• Route alerts to a team that acts on them,
• Review whether the rules still fit.
• Decide which resources SRE Agent may reach

None of these are procurement decisions. That raises the obvious question: does the work pay off?

• Early results from the vendor are encouraging

The best available proof comes from Microsoft's own publications, so read it as promising rather than conclusive.

In Microsoft's announcement of the Observability agent's general availability, Narmada Krishnaswamy, Head of KPMG Audit Application Support and Operations, said that since adopting these capabilities, KPMG has reclaimed "an estimated 250 engineering hours monthly." She adds that it returns investigations and recommendations "almost immediately, compared to hours or even days previously."

Microsoft's November 2025 customer story on Ecolab reports that the company's daily alerts fell from 30–40 to under 10 on average within a couple of months. Ecolab used Azure SRE Agent, the third class above, which Microsoft now bills with an always-on charge plus usage. It adopted the SRE agent during its preview and worked closely with Microsoft to shape the product. The story gives no time-to-resolution figure. As the story describes it, Ecolab fed its Azure Monitor alerts into SRE Agent, connected it to Azure DevOps to raise tickets, and receives a daily incident report. Our reading is that this was integration and routine built on alerts it already had, not new monitoring, and that the story describes triage and ticketing, not automated fixes.

Neither case is independent, and neither tells you what a typical enterprise will see. Both show what engaged early adopters reported in Microsoft's own publications.

• The strongest objection: built-in AI may not be enough

A skeptical CTO will say these built-in tools have limits. They do.

Smart Detection is not fully predictable, and dynamic thresholds can miss slow drift. The Observability Agent suggests but does not act, and its autonomous operations remain in preview. Practitioners are wary as well: in Grafana Labs' survey, 95% said it matters that AI tools explain their reasoning, and 15% said they do not yet trust AI to act on their behalf. Our reading is that SRE Agent’s Review mode, described above, is the design answer to that wariness.

So, the audit is not an argument against buying. It is an argument about order. If it shows the built-in capabilities fall short, the enterprise buys against documented requirements instead of a general hope for less noise. The needs described above show what documented requirements look like: acting on findings and reaching tools beyond Azure Monitor. The audit also sharpens the buying conversation. Microsoft says the Observability Agent’s accuracy depends on complete telemetry. Ask any vendor pitching an AI observability platform what its accuracy depends on, and whether your telemetry meets that standard today. Then ask how it performs on your last incidents, compared with the built-in agent.

• Audit first, then decide what to add

Microsoft’s incident-management guidance advises keeping “a library of scripts and infrastructure-as-code (IaC) templates for recovery, validation, troubleshooting, and root cause analysis” (Well-Architected OE:08).

Before approving new AI observability spend, ask the team that runs Azure operations to answer five questions in writing:

• Coverage: Do critical applications send requests, dependencies, and exceptions to Application Insights with standard correlation fields left intact, and are resource logs enabled on the resources behind them?
• Tuning: Which critical metrics use dynamic thresholds, which still use static limits, and why?
• Ownership: Who receives Smart Detection and dynamic-threshold alerts, what happened to the last ten, and which fixes are recorded in the runbooks & post-incident records?
• Evaluation: Has anyone compared the agent’s findings with what engineers concluded on a few recent incidents?
• Cost: What would the agent's usage cost at a specific incident volume, including the SRE Agent’s always-on charge, and who approves that spend?

Three things could change this argument. Microsoft may revise agent pricing. Preview features, including the Observability Agent’s autonomous operations and the Smart Detection migration, may change before general availability. And independent evidence may confirm or contradict the early, vendor-published results.

Each leader can take one question into the next leadership meeting:

• CIO: “Which of these capabilities are switched on in our estate today, and who owns each one?”
• CFO: “Which of our monitoring costs pay for capabilities Azure Monitor may already include?”
• CTO: “Is our telemetry complete enough for any AI, built-in or bought, to reason over?”
• CISO: “If we add an agent that can act, which resources can it reach, in which mode, and who approves its changes?”

The AI you already have is only as useful as the telemetry you feed it and the team that owns it. Check before you buy more.

If your team needs Microsoft Azure specialists to run this audit, ITPN can help you find them.