Azure operations teams have spent years stitching together Azure Monitor alerts, Log Analytics queries, Application Insights traces, ITSM tickets and tribal knowledge to keep production healthy. In March 2026, Microsoft announced general availability of Azure SRE Agent, an AI agent that investigates incidents across applications, platform and infrastructure, proposes or performs remediation, and learns from every interaction. It is part of a broader industry move: AWS and Google have shipped comparable operations agents within the same twelve months.
For anyone running Azure workloads, either with an internal platform team or a managed service provider, the arrival of a generally available SRE agent raises practical questions. What can it actually do? How do you stop it from doing the wrong thing? How is it billed? And how should operating models, contracts and skills change? This article answers those questions and offers a staged adoption plan.
What Azure SRE Agent Does
Microsoft’s GA announcement describes an agent that brings deep context, root-cause analysis, incident response and proactive reliability work together. In practical terms, it covers five jobs:
- Root-cause analysis. The agent correlates logs, metrics and traces across application, platform and infrastructure layers and tests hypotheses rather than simply summarizing alerts.
- Incident response. It surfaces past resolutions, runbooks and context from earlier incidents so responders start with history instead of a blank page.
- Remediation. Within the guardrails you configure, it can propose or execute Azure operations such as restarting or scaling a service.
- Proactive reliability. It flags emerging risks, misconfigurations and trends before they become incidents.
- Reporting and analysis. A built-in code interpreter writes and runs Python to produce deliverables such as charts, Excel workbooks, PDF reports and data exports.
The GA release also added building blocks for automation: skills, subagents, Python tools and agent hooks, plus deeper ecosystem integrations through Model Context Protocol (MCP) connectors. Microsoft has highlighted GitHub integration for root-cause analysis with code context. In August 2026, Microsoft made virtual network integration generally available, allowing the agent to run inside existing network controls such as network security groups, private DNS and firewall policies, and to reach services behind private endpoints during investigation and remediation. For regulated environments that refuse to open network boundaries to a SaaS tool, that removes a major adoption blocker.
Microsoft also reports running the agent internally at large scale, citing more than 1,300 agents deployed, more than 35,000 incidents mitigated and more than 20,000 engineering hours saved. These are vendor-reported numbers about Microsoft’s own estate, but they indicate the agent has been exercised on real production operations, not only demos.
The Control Model: Run Modes, Permissions and Hooks
The most important design decision when adopting any operations agent is how much it may do on its own. Azure SRE Agent splits this into distinct controls, and understanding each of them is essential.
Run modes control approval
According to Microsoft Learn, run modes determine whether the agent asks before acting or acts and reports. Review mode proposes an action and waits for approval; Autonomous mode executes and then reports what it did. Run modes are set per response plan or scheduled task rather than globally. Notably, the documentation states that Autonomous is the default for response plans and scheduled tasks, while Review is the default for the agent-level setting, so teams must deliberately configure each response plan. Only users with the SRE Agent Administrator role can approve actions.
There is an important subtlety: Review mode applies to Azure infrastructure operations, such as Azure CLI commands and Azure Resource Manager write operations. Other actions, such as sending email, posting to Microsoft Teams or querying external systems, proceed based on the agent’s reasoning and the response plan’s instructions. To govern those, Microsoft points to agent hooks and tool access policies.
Permissions control access
Run modes govern the approval workflow; permissions govern what resources the agent can reach. The agent needs both to act. When the agent lacks permission for an action, it can request temporary access on behalf of the user through the Microsoft Entra on-behalf-of flow. Microsoft recommends starting in Review mode, observing recommendations for two to four weeks, and then switching triggers you consistently approve to Autonomous.
Treat run modes, permissions and hooks as three separate dials. Least-privilege access, Review mode for production and hooks for non-infrastructure actions together give you autonomy you can defend to an auditor.
How Pricing Works and Why It Matters
Azure SRE Agent is billed in Azure Agent Units (AAUs), which Microsoft uses to standardize agentic processing across its prebuilt agents. The pricing page describes two components. An always-on flow is a fixed baseline per agent per hour that continues from agent creation until deletion. An active flow is variable and depends on the large language model tokens the agent consumes while handling tasks such as incident investigation, with each token type metered at a fixed AAU rate depending on the configured model. Since April 15, 2026, the GA announcement notes, active-flow AAUs are calculated per million tokens.
Three practical consequences follow:
- Agent count is a cost decision. Because each agent carries an always-on baseline, creating one agent per small application can be expensive. Design agent boundaries around operational domains or teams.
- Noisy alerts become a direct cost. If every low-value alert triggers an investigation, token consumption rises with no benefit. Alert hygiene is now a FinOps lever.
- Model choice affects cost. Because token rates depend on the configured model, match model capability to task complexity where the product allows it.
What Changes for Azure Operations Teams
Response plans become the new runbooks
In the agent model, response plans define what should happen when a certain kind of incident occurs: which data to gather, which hypotheses to test, which actions are allowed and who gets notified. Writing good response plans is a craft that blends SRE experience with clear technical writing. Teams that already maintain structured runbooks have a head start.
Institutional knowledge becomes an asset you can manage
The agent builds a knowledge base from interactions and can be taught directly. That is a real opportunity for organizations that lose know-how whenever experienced engineers leave. It also introduces a new responsibility: reviewing what the agent has learned, correcting wrong conclusions and keeping sensitive information out of its memory where it does not belong.
Observability coverage gates value
An agent reasoning over Azure Monitor data is only as good as that data. Missing diagnostic settings, inconsistent resource naming, absent distributed tracing and unconnected deployment history all limit what it can conclude. Before you expect strong root-cause analysis, make sure diagnostic logs flow to Log Analytics, Application Insights covers critical services and deployments from Azure DevOps or GitHub are linked.
On-call shifts toward supervision
Engineers spend less time collecting evidence and more time validating conclusions, approving actions and improving response plans. That is a better use of skilled people, but it requires training: reviewing an agent’s reasoning critically is a different skill from debugging alone.
In practice, the skills that grow in value are Kusto Query Language fluency to verify the agent’s evidence, a solid grasp of Azure resource behavior to judge whether a proposed action is safe, and the writing discipline to turn each incident into a better response plan or skill. Teams should also agree on simple review heuristics: does the evidence actually support the conclusion, is the timeline consistent, and is the proposed action the least disruptive fix available? Building these habits early prevents the most dangerous failure mode of any AI assistant, which is people accepting a fluent but wrong explanation because it arrived quickly.
A Staged Adoption Plan
- Prepare the foundations. Standardize resource naming and tagging, enable diagnostic settings through Azure Policy, connect Application Insights to critical services and integrate deployment history. Define baseline metrics: MTTR, time to first credible hypothesis, alert volume per service and after-hours pages.
- Start with a read-only pilot. Create one agent scoped to a single operational domain, grant reader-level access and use it for investigations in non-production and for production incidents in parallel with your normal process. Compare its conclusions with your post-incident reviews.
- Enable Review mode for production response plans. Grant scoped write permissions for specific remediation actions and require approval for every infrastructure change. Use hooks or tool access policies to restrict outbound communications.
- Graduate trusted actions to Autonomous. After several weeks of consistent approvals, move low-risk, reversible actions, such as restarting a stuck worker or scaling out a stateless tier, to Autonomous in production. Keep high-impact actions in Review indefinitely.
- Industrialize. Version-control response plans and skills, review agent memory periodically, budget AAU consumption by agent and report agent performance alongside human on-call metrics.
Worked Example: Memory Pressure on a Production App Service
Consider a B2B SaaS application running on Azure App Service with Azure SQL Database and Azure Cache for Redis, monitored through Application Insights and Azure Monitor. Over a weekend, response times climb and HTTP 5xx errors appear intermittently.
An Azure Monitor alert triggers the agent’s response plan for web tier degradation. The agent gathers recent deployments from GitHub, App Service metrics, Application Insights dependency telemetry and Redis metrics. It observes that memory working set on the web instances has grown steadily since a deployment on Friday, that garbage collection pauses correlate with the 5xx spikes, and that a code change introduced an in-memory cache without eviction limits. It proposes two actions: restart the affected instances to restore service immediately, and open an issue with the suspected code change and a suggested fix.
Because the response plan runs in Review mode for production, the on-call engineer receives a proposed restart with a note about brief downtime, approves it and confirms recovery. On Monday, the development team reviews the agent’s analysis, fixes the cache configuration and adds a memory-growth alert. In the post-incident review, the team decides that restarting a single instance when memory exceeds a defined threshold is a safe action to move to Autonomous, with a notification to the channel.
The value here is not that the agent restarted a server; any script can do that. The value is that it connected the symptom to a specific change quickly and documented the reasoning so the right people could fix the cause.
Common Pitfalls and How to Avoid Them
Early adopters of operations agents on every cloud tend to stumble over the same issues. Most are organizational rather than technical.
- Leaving default run modes unexamined. Because response plans and scheduled tasks default to Autonomous, a plan copied from a non-production template can quietly act in production. Make run mode an explicit, reviewed field in every response plan.
- Granting broad contributor rights “to make it work.” Over-privileged agents turn a reasoning mistake into an outage. Scope permissions to the resource groups and actions each response plan needs, and rely on temporary on-behalf-of access for the rest.
- Ignoring non-infrastructure actions. Review mode does not cover messages to Teams, email or external systems. Without hooks or tool access policies, an agent could notify customers or open tickets in ways you did not intend.
- Feeding it noise. Triggering investigations from every warning-level alert wastes tokens and buries useful findings. Start with high-severity, well-understood alerts.
- Skipping the comparison step. Teams that never compare agent conclusions with post-incident reviews cannot tell whether the agent is getting better or simply sounding confident.
- Letting memory go unreviewed. Learned knowledge can encode wrong assumptions. Schedule periodic reviews of what the agent has learned, just as you would review runbooks.
A simple control that addresses several of these at once is an agent change board: a lightweight weekly review where the platform lead, a security representative and an application owner approve new response plans, autonomy changes and permission grants. It adds little overhead and creates a clear audit trail.
What This Means for Azure Managed Services
Agentic operations change what organizations should expect from an Azure managed service provider and how internal teams should be organized.
- From monitoring to engineering. Round-the-clock dashboard watching is exactly what agents absorb. A provider’s value moves to designing observability, writing and tuning response plans, governing agent autonomy and delivering reliability improvements.
- Agreements based on outcomes. With faster, more consistent triage, it becomes reasonable to define service levels around SLO attainment, MTTR and repeat-incident reduction instead of only response times.
- Clear ownership of the agent. Contracts should state who administers the agent, who can approve actions, who pays for AAU consumption and how agent knowledge is handed over if the relationship ends.
- Transparency. Investigation records and agent actions should be visible to the customer, not hidden behind summarized tickets.
Questions worth asking any provider include: Which run mode will each production response plan use, and why? How are permissions scoped? How are hooks configured for outbound communications? How is agent memory reviewed? And how is AAU spend reported?
Conclusion
Azure SRE Agent makes agentic operations a mainstream option for Azure workloads. Its combination of root-cause analysis, memory, extensibility through skills and MCP connectors, and configurable autonomy can significantly reduce the toil of incident response. Its governance model is thoughtful but demands deliberate configuration: run modes per response plan, least-privilege permissions, hooks for non-infrastructure actions and an AAU budget. Organizations that prepare their telemetry, start in Review mode and graduate autonomy based on evidence will get faster recovery without surrendering control. Over the next two years, expect these agents to take on more proactive reliability work, and expect the best operations teams, internal or managed, to be defined by how well they design, supervise and improve them.
How Hanoi Technology Can Help
Hanoi Technology prepares Azure environments for agentic operations, from observability and response plans to governed autonomy, as a project or managed service.