TL;DR:
- AI agents in IT operations are moving beyond alert correlation into active remediation — restarting services, scaling resources, isolating faulty nodes, and drafting incident postmortems autonomously
- The viable pattern for 2026 is “human in the loop for blast radius, agent for the routine”: agents handle known failure modes with bounded actions; humans approve anything touching production data or major infrastructure changes
- Platform-native AIOps (Datadog Bits AI, PagerDuty Copilot, Dynatrace Davis AI) is the fastest path to deployment; custom agents on top of observability APIs suit teams with non-standard stacks
IT operations has always been a target for automation. The challenge has been that operational problems are too varied for rigid rule-based systems: alert fatigue, false positives, novel failure modes, and complex dependency chains defeat playbooks that weren’t written for the specific failure in front of you. AI agents change this because they can reason about novel situations, not just match patterns.
The 2026 state of AIOps is: reliable for known failure categories, increasingly capable for diagnosis of novel failures, and still requiring human judgement for anything with significant blast radius. Understanding where those boundaries sit is what determines whether an AIOps deployment saves time or creates new incidents.
What AI Agents Can Do in IT Operations
Alert Correlation and Noise Reduction
The most mature AIOps function. Modern infrastructure generates thousands of alerts per hour; the majority are symptoms of a small number of root causes or are outright false positives. AI systems — both ML-based correlation engines and LLM-powered agents — can group related alerts, identify probable root causes from topology data, and suppress redundant notifications.
Datadog’s Bits AI and Dynatrace’s Davis AI operate at this layer natively, using topology awareness to distinguish “50 alerts from nodes that all depend on this database” from “50 independent problems.” The result is that on-call engineers receive a small number of meaningful incidents rather than a flood of correlated symptoms.
Runbook Execution
When an alert fires and the appropriate response is known, agents can execute it without human intervention. Common examples:
- Restart a failing service and confirm health checks pass
- Scale up a deployment when request queue depth exceeds threshold
- Rotate a near-expiring certificate before it causes downtime
- Clear a stuck batch job and restart the pipeline
- Adjust rate limiting when upstream API latency degrades
PagerDuty’s automation actions and Rundeck’s process automation layer have supported scripted runbook execution for years. What’s new in 2026 is agents that can select the appropriate runbook based on diagnostic context, not just trigger the one mapped to a specific alert. An agent that correlates a database slow query alert with a recent schema migration can select the “rollback migration” runbook rather than the generic “restart database” playbook.
Incident Communication and Documentation
AI agents handle the operational communication burden that historically consumes significant on-call engineer time. Drafting the initial incident notification, updating stakeholder status pages, generating timeline documentation, and producing postmortem drafts from incident logs are all tasks where LLM capability is directly applicable.
Atlassian’s AI features in Jira Service Management, PagerDuty Copilot, and FireHydrant’s AI assistant all operate in this space. The agents pull from incident timelines, system logs, and previous postmortems to produce documentation drafts that engineers review and edit rather than write from scratch.
Diagnostic Investigation
The newer capability — and the one requiring more care in deployment — is autonomous investigation of ambiguous failures. When an agent receives an alert without a clear mapped remediation, it can:
- Query metrics, logs, and traces across the observability stack
- Check recent deployment events and configuration changes
- Compare current state against historical baselines
- Generate hypotheses about root cause with confidence levels
- Propose remediation options for human review
This is where LLM agents add genuine new capability beyond ML-based correlation. The ability to reason across heterogeneous data sources — metrics in Prometheus, logs in Splunk, traces in Jaeger, deployments in ArgoCD — without requiring every data source to be pre-integrated is a meaningful step.
Architecture Patterns
Platform-Native AIOps
The fastest deployment path. Datadog Bits AI, Dynatrace Davis AI, New Relic AI, and PagerDuty Copilot are built into observability and incident management platforms that many organisations already use. Enabling AIOps features requires configuration rather than custom development.
The constraint: you’re limited to the capabilities the platform exposes. Runbook execution, alert correlation, and incident documentation are well-supported. Complex multi-system remediation that reaches outside the platform’s integrations requires custom work.
Agent Framework on Observability APIs
Teams with non-standard stacks or requirements that exceed platform capabilities build custom agents using frameworks like LangChain, LangGraph, or PydanticAI. The agent receives alert context via webhook, queries multiple observability APIs to gather diagnostic data, and invokes remediation via infrastructure APIs (Kubernetes API, cloud provider APIs, internal tooling).
This approach gives full control over remediation scope and integrates with arbitrary internal systems, but requires SRE or platform engineering time to build and maintain. The pattern works well for organisations with substantial internal tooling that pre-dates modern observability platforms.
Hybrid: Platform for Observation, Custom Agents for Remediation
A practical middle ground. Use the observability platform for correlation and alert intelligence; route enriched incident context to a custom agent that has access to broader remediation capabilities. The platform provides signal quality; the custom agent handles execution.
Defining the Automation Boundary
The most important decision in any AIOps deployment is what agents can execute autonomously versus what requires human approval.
Safe for autonomous execution (bounded, reversible):
- Service restarts with health check confirmation
- Horizontal scaling within defined resource limits
- Cache invalidation
- Feature flag toggling (roll back a feature, not enable a new one)
- Sending alert notifications and status page updates
- Generating diagnostic reports and postmortem drafts
Require human approval (high blast radius, hard to reverse):
- Database schema changes or data migrations
- Security group or firewall rule modifications
- Deletion of resources (even apparently orphaned ones)
- Changes to authentication configuration
- Production data access or modification
- DNS changes
- Anything touching billing or IAM
The practical implementation uses approval gates. Agents with access to PagerDuty automation actions, AWS Systems Manager, or Slack slash commands can propose a remediation action and wait for an on-call engineer to approve it with a single button click — dramatically faster than the engineer finding and executing the action themselves, while retaining human sign-off.
Observability Requirements for Agentic AIOps
Agents are only as good as the context they can access. For AIOps agents to be useful rather than dangerous, you need:
Structured, queryable logs: Agents querying unstructured log blobs are slower and less reliable than agents querying structured JSON logs with consistent fields. If you haven’t migrated to structured logging, AIOps agents expose why it matters.
Service topology mapping: Understanding which services depend on which others is essential for root cause reasoning. Service mesh telemetry (Istio, Linkerd) or APM service maps (Datadog, Dynatrace) provide this. Agents without topology context guess at blast radius rather than knowing it.
Deployment event tracking: Most production incidents are caused by recent changes. Agents that can see “this metric degraded 3 minutes after this deployment” have a massive diagnostic advantage over agents that can only see current state. GitOps tooling (ArgoCD, Flux) with event export to the observability stack makes this accessible.
Audit trail for agent actions: Every action an agent takes should be logged with timestamp, context, justification, and outcome. This is essential for postmortem analysis, for understanding agent behaviour, and for the trust-building process that leads organisations to expand automation scope over time.
Real-World Deployment Outcomes
Organisations that have deployed AIOps automation in production report consistent patterns:
Mean time to acknowledge drops significantly (30–60% reduction is typical) because agents immediately correlate and enrich alerts rather than requiring an engineer to manually investigate before they can understand the scope.
Mean time to resolve for known failure modes approaches zero when autonomous remediation is enabled. Service restarts that previously required an on-call engineer waking up, SSHing to a box, and running a command can complete in under 60 seconds with no human involvement.
On-call load decreases, but doesn’t disappear. Agents handle the routine; the remaining pages are genuinely novel or high-stakes situations requiring human judgment. Engineers report higher quality on-call experience when trivial incidents are automated away — though this requires good tuning to avoid suppressing alerts that should be visible.
The postmortem process improves. AI-drafted postmortems from structured incident timelines are more consistent and complete than ones written from memory hours after an incident resolves. Teams report spending less time on postmortem writing and more time on action items.
Getting Started
For teams new to AIOps automation, the practical starting sequence:
- Enable alert correlation in your existing observability platform — this delivers immediate value with no remediation risk
- Build an inventory of your 10 most common incident types and their runbooks
- Automate the lowest-risk, highest-frequency runbooks first (service restarts, scale-up actions)
- Add approval workflows for medium-risk remediations before fully automating them
- Measure MTTA and MTTR before and after each automation addition
The goal isn’t to remove humans from IT operations — it’s to remove humans from the parts of IT operations that are routine, stressful, and don’t require human judgment. What’s left after good AIOps automation is more interesting: novel problems, architectural decisions, and the postmortem work that actually improves system reliability.