Greetings, Cloud Marathoners!
We are back with a great event: Agentic Azure Insights. Thank you to everyone taking part in the event, and especially the organizers.
Agentic Azure Insights
A recurring community event that shares curated, practical content on building real-world Agentic AI systems on Azure. Each quarterly edition brings together community-contributed blogs, videos, demos, and open-source projects. It is created for
- Anyone wanting to share real-world lessons learned
- Practitioners building agentic systems on Azure
- Students exploring AI agent architectures
- Developers evaluating multi-agent frameworks
A Beginnerโs Guide to DevOps, Agentic Ops, and the Emerging Role of AI in Cloud Operations
Now, imagine it is 3:00 AM. Your phone goes off. You log in to your station and start an investigation.
A production application is returning HTTP 500 errors. An alert has fired, customers may be affected, and the clock is running. You open monitoring dashboards, application telemetry, deployment logs, chat history, and perhaps several other tools. Somewhere among millions of signals is the explanation for what went wrong.
Forty minutes later, you finally find it. ๐ซ
For anyone new to DevOps or Site Reliability Engineering (SRE), this scenario illustrates an important challenge. Modern cloud environments generate enormous amounts of information, but more information does not automatically mean faster answers.
Operations teams may receive hundreds or even more than a thousand alerts in a day. Engineers have dashboards for metrics, platforms for logs, distributed traces, security telemetry, deployment histories, incident-management systems, and collaboration tools. The problem is increasingly not a lack of data or tools. It is making sense of all that data quickly enough.
This is where a new idea is emerging: Agentic Operations, or Agentic Ops.
Instead of giving engineers yet another dashboard, Agentic Ops introduces AI agents that can participate in operational work: gathering evidence, correlating signals, forming hypotheses, recommending actions, and, within carefully defined boundaries, potentially performing approved actions.
Next, let’s explore what that means, why it matters, and why humans remain an essential part of the equation and solution.
1. The Starting Point: Why Modern Operations are Hard
DevOps brought development and operations closer together. Instead of treating software development, deployment, and production support as disconnected activities, DevOps encourages teams to build, deploy, observe, and continuously improve applications together.
Automation is fundamental to that approach. We automate application builds. We use CI/CD pipelines to deploy software. Infrastructure as Code helps us provision cloud resources consistently. Monitoring and observability help us understand how applications behave after deployment.
But something interesting has happened along the way.
We automated the systems, while much of the investigation remained manual.
Consider what happens after a production alert.
An engineer may first examine Azure Front Door or load-balancer telemetry (refer to a reference diagram in section #5). Next, they investigate application metrics. Then database connections. Then cache utilization. Then CPU and memory. We are not finished yet; then application logs, security events, deployment histories, and changes made earlier that day.
A diagram below describes this process in four phases: Alert, Assembly, Recall, and Reaction. An alert tells us something is wrong. Assembly requires collecting context from different systems. Recall relies on experience and institutional knowledge. Finally, the engineer reacts after deciding what probably caused the problem.
There is one more difficulty: the engineer who solved the same problem six months ago might not be on call tonight.
Well, that is what industry calls the โtribal knowledgeโ problem. Valuable operational knowledge can live or lives in people rather than in systems. And yes, Agentic Ops attempts to change this model.
2. From DevOps to Agentic Ops
Agentic Ops does not replace DevOps or SRE. Think of it as another stage in the evolution of operational automation.
Traditional automation is very good when the steps are known in advance:
If X happens, execute Y.
A deployment pipeline follows a predefined workflow. An autoscaling policy reacts to a threshold. A runbook performs a known sequence of commands.
But incidents are rarely that predictable, right?
A typical engineer investigating a system outage asks questions, such as:
- What changed?
- What systems are affected?
- Is this behavior unusual?
- Did something similar happen before?
- Are several apparently unrelated signals connected?
- Is this a security incident, capacity problem, configuration change, or bad deployment?
- What action is safe to take?
This type of work involves context and reasoning that an experienced DevOps professional knows and acquires over years of experience.
This session defines Agentic Operations as an operating model in which AI agents participate in running technology services. Rather than simply displaying another alert or recommendation, an operational agent can observe signals, establish context, form hypotheses, select approved tools, investigate, verify results, escalate uncertainty, and preserve an audit trail.
That distinction is critical for beginners. While monitoring tells you something happened, automation executes predefined instructions.
An operational agent attempts to understand what happened and determine what should happen next.
3. Meet the Azure SRE Agent
This is where Azure SRE Agent enters our discussion. Within the broader Agentic Ops model presented in the session, Azure SRE Agent focuses on the SRE and production-operations problem. It can help investigate service health, reason over Azure context, coordinate diagnostic work, recommend remediation, and, when appropriately configured and authorized, perform bounded actions.
The simplest way for us to understand the concept is:
Think of an SRE Agent as an assistant engineer that can investigate much faster than a human can manually navigate a collection of operational tools.
Instead of an engineer opening systems one at a time, the agent can reason across data from services such as Azure Monitor, Application Insights, Log Analytics, Service Health, application logs, metrics, and deployment history.
Let’s suppose that Azure Front Door begins reporting a spike in 5xx responses. A human investigator might next check the database, notice a surge in MySQL connections, look at deployment history, and discover that a new application release was deployed 30 minutes earlier.
An agent can bring these signals together as part of the same investigation. And the result should go beyond saying:
โError rate is high.โ
A useful investigation should instead help answer:
โHere is the likely root cause, here is the affected scope, here is the evidence, and here is the recommended next action.โ
That is a much more useful starting point for an engineer when investigating a system outage and is under pressure to resolve production issues.
4. From Alert to Action: How Agentic Investigation Works
This section describes an end-to-end workflow in five stages:
- Signal
- Investigate
- Conclude
- Gate
- Approve
A signal might be an alert, but the investigation does not necessarily have to wait for one. Scheduled analysis can also look for abnormal behavior.
During investigation, the agent queries available telemetry such as metrics, logs, traces, and recent deployments.
During conclusion, it attempts to develop a root-cause hypothesis, determine the affected scope, and propose an appropriate response. Then something extremely important happens.
The agent encounters governance gates.
This is where Agentic Ops becomes fundamentally different from simply giving an AI model unrestricted access to a production environment. An agent’s proposed action can be evaluated against permissions and policies. High-impact actions can require explicit human approval.
That gives organizations an important operating principle:
The agent investigates and proposes. The engineer remains accountable for the decision.
For organizations starting their Agentic Ops journey, this also means useful value can be achieved before permitting autonomous changes.
An agent with read-only access can still inspect telemetry, connect signals, detect anomalies, and accelerate investigations.
5. What Does This Look Like in the Real World?
This session uses security and production troubleshooting scenarios to show why contextual reasoning matters.
Detecting a Distributed Attack?
Imagine traffic increases dramatically against a web application in a traditional, highly available public site with the following reference architecture below.
A traditional rate-limit alert might look at individual source IP addresses. But what happens when a distributed attack comes from tens of thousands of addresses, each staying below the per-IP limit?
The example in this session illustrates exactly that problem. The agent can examine requests by source IP, hit counts by URI, Azure Front Door information, WAF signals, MySQL connections, Redis memory, and backend service health together.
One metric alone may not prove there is an attack. But consider the context:
- request volume rises dramatically;
- traffic is distributed across many source addresses;
- particular application paths become unusually hot;
- database connections approach their maximum;
- cache memory nears its ceiling;
- backend services start degrading.
Together, those signals tell a far richer story, where we might need to look at security services and consider WAF and security triage.
WAF and Security Triage
The same principle applies to Web Application Firewall (WAF) events.
Thousands of security events per hour can overwhelm a person. An agent can help rank activity, identify frequently triggered rules, surface important source patterns, and provide engineers with a more actionable starting point for investigation.
Better Alerts
Agentic Ops can also change what an โalertโ looks like. Instead of getting unhelpful alerts, such as :
HIGH: Something is wrong.
this session demonstrates an alert containing the suspected event, traffic magnitude, source distribution, affected paths, backend state, WAF status, and suggested mitigation. Importantly, the example makes clear that the agent is waiting for instruction and has not made the proposed change on its own.
This is the difference between sending an engineer another signal and giving that engineer a head start on the investigation.
6. From Reactive Firefighting to Proactive Operations
One of the biggest opportunities for Agentic Ops is not simply responding to incidents faster. It is finding trouble before it turns into an incident.
Traditional operations often begin when a threshold is crossed, or someone (maybe affected system customers) reports a problem. Agent-assisted operations can perform scheduled sweeps and look for degradation patterns that might not yet have triggered a conventional alert.
My recorded session highlights adaptive anomaly detection, scheduled analysis, and proactive identification of degradation patterns as ways teams can move from reactive firefighting toward earlier detection.
This is an important mindset change. The question is no longer only:
โHow quickly can we respond when something breaks?โ
It can increasingly become:
โCan we find the pattern before users notice that something is breaking?โ
That is a huge, potentially one of the most valuable uses of an operational agent.
7. The Reality Check: AI Agents Can Be Wrong
Well, did you know that AI agents are not infallible?
My session deliberately includes examples in which the SRE Agent produced recommendations that did not hold up when challenged or checked more carefully against authoritative information.
That is not a minor footnote. It is one of the most important lessons of Agentic Ops.
An agent can correlate information quickly and generate a convincing explanation while still reaching an incorrect conclusion. This is why operational AI should not be judged solely by how fluent or confident its answer sounds.
Engineers should ask:
- What evidence supports this recommendation?
- Can I verify it using authoritative documentation?
- Does the proposed action fit our architecture?
- What is the blast radius if the recommendation is wrong?
- Can the action be reversed?
- Does it require human approval?
Operational AI therefore needs guardrails as much as intelligence.
Our proposed governance model includes permission controls, fail-closed behavior, Azure RBAC integration, network boundaries, auditability, and human approval.
โHuman in the loopโ should not be treated as a temporary inconvenience on the path to total autonomy. For important production decisions, it can be an intentional control that combines machine speed with human accountability.
8. The Future Is a Human-Agent Partnership
So, are SRE Agents coming to replace SRE engineers?
Well, that sounds like the wrong question. A more useful question is:
What becomes possible when every engineer can begin an incident with more context than they could manually collect in the first 30 minutes?
The goal presented in the session is a human-agent partnership. The agent acts as a first responder and analyst while engineers continue to make important operational decisions. Knowledge learned through investigations can be retained rather than disappearing when experienced team members leave or simply happen not to be on call.
This could also change where engineers spend their time.
Less time manually assembling telemetry can mean more time improving architecture, eliminating recurring failure modes, enhancing resilience, automating known patterns, and designing better systems.
For teams interested in experimenting, my session recommends a deliberately conservative starting point: begin with a pilot and read-only access, connecting the agent to existing Azure observability capabilities before expanding its authority.
That creates a practical maturity path, such as:
Observe โ Investigate โ Recommend โ Human approval โ Controlled action
Rather than:
Deploy AI โ Give it production access โ Hope for the best. ๐ฑ๐ฑ๐ฑ
The Takeaway
Agentic Ops represents an interesting shift in the evolution of DevOps and SRE.
DevOps gave us practices for collaborating, automating delivery, managing infrastructure as code, and continuously improving systems. Observability gave us increasingly rich visibility into production environments.
Agentic Ops adds another layer: software that can participate in the investigation itself.
An SRE Agent can potentially gather telemetry, correlate signals, search operational context, formulate hypotheses, recommend remediation, and preserve knowledge from investigations. More importantly, it can perform that work at machine speed when an engineer is facing a complicated production incident.
But speed alone is not enough. The agent must operate inside clearly defined permissions. Its conclusions need evidence. High-risk actions need appropriate approval. Its recommendations should be verified, particularly when the consequences of being wrong are significant.
The most compelling future, therefore, is neither humans doing everything manually nor AI running production without oversight. It is humans and agents operating together.
The agent brings scale, speed, correlation, persistence, and continuous attention. And our trusted engineers bring architecture knowledge, judgment, accountability, business context, and the ability to decide when the available evidence simply is not good enough.
That combination is what makes Agentic Ops worth exploring for your organization.
๐ฅ Continue with the Recorded Presentation
This post is intended as your introduction, but Agentic Ops makes considerably more sense when you can see the investigation workflow, dashboards, security scenarios, anomaly correlation, governance controls, and real SRE Agent interactions on screen.
I invite you to watch my recorded session – โCalling SRE Agents for the Rescue,โ where I walk through these concepts visually and explore real-world Azure SRE Agent scenarios.
The recording will be posted here soon…
#Azure #AgenticAI #SRE #CloudOperations #AzureMonitor #Observability #DevOps #SRE
