How Autonomous Are Your IT Operations, Really?

Most IT operations are not fully autonomous yet. According to Gartner, only 15% of IT leaders are considering, piloting, or deploying fully autonomous AI agents.

Many teams remain in the middle, using AI to retrieve context, automate predefined tasks, or recommend actions that people still approve.

So, how autonomous your IT operations are depends on what your systems can reliably decide and execute in production.

This blog presents a six-level maturity model to help IT leaders assess that progression, from chatbots and deterministic automation to bounded self-healing workflows, expert agents, and coordinated agent ecosystems.

What Is An Agentic AI Maturity Model For IT Operations?

An agentic AI maturity model measures how independently IT systems can make decisions and execute actions safely in production. This model consists of six levels, progressing from information retrieval to coordinated agent ecosystems: 

• Level 0 (Chatbot): Retrieves and explains operational information but takes no action.
• Level 1 (AI Assistant): Runs predefined workflows when fixed conditions are met.
• Level 2 (AI Agents): Recommends actions based on context and executes them after human approval.
• Level 3 (Advanced Agents): Runs approved, end-to-end workflows independently within defined limits.
• Level 4 (Expert Agents): Selects or drafts domain-specific playbooks for complex operational issues.
• Level 5 (Agent Ecosystems): Coordinates multiple agents across detection, investigation, remediation, and recovery.

Progress requires reliable production data, connected operational context, policy controls, validation, rollback procedures, and clear escalation paths.

How to Assess Your Organization’s Agentic AI Maturity

Assess your organization’s maturity level by examining what its systems can reliably decide and execute in production. Use the criteria below to evaluate your current capabilities and identify the controls you need for the next stage: 

To use this model, evaluate your capabilities based on what your systems can reliably do in production. Each level represents a wider range of decisions and actions that the system can safely handle without human involvement.

The first step toward autonomous IT is to choose one frequent, low-risk workflow with a clear success condition. Connect the required data, document the response, define approval and rollback rules, and measure the result in production before expanding.

Level-By-Level Breakdown: What Each Maturity Stage Looks Like In Practice

Each level below covers the same five questions: what it is, what it enables, what you need, how you measure success, and what moving up requires.

Level 0 — Chatbot / No Autonomy

Level 0 systems retrieve and summarize operational information. They help an engineer assemble context, but a person still decides what happened and what to do next.

What it enables

Engineers spend less time searching dashboards, tickets, logs, and runbooks for the facts needed to assess an incident. The system can pull relevant metrics on demand, summarize alert timelines, surface similar past incidents, and translate a vague “what should I look at?” into a specific set of queries and links. The decision-making load stays entirely with humans; what compresses is the time spent assembling context before a decision can be made.

What it looks like in practice

Queries like “show me recent errors for service X,” “what changed in the last hour,” or “what does the runbook say” return structured, sourced answers. A human still determines whether the issue is real, assesses impact and priority, selects a remediation approach, and validates recovery.

What you need

How to measure success

Reduced time assembling incident context, faster handoffs, less time spent searching across tools. MTTR is not a meaningful metric at this level — triage, decisioning, and remediation still sit with people.

Common trap

Expecting MTTR reduction from a system that only retrieves information. Minutes saved on fact-finding are real, but the work that consumes the most time during incidents remains untouched.

Moving to Level 1

The move from retrieval to execution starts with a small, well-scoped target. Think: a handful of repeatable, low-risk actions the team already follows consistently — ticket updates, notifications, routine hygiene tasks. Standardize the trigger conditions, define the exact steps, and add guardrails and audit logging. That foundation is what makes deterministic execution safe enough to trust.

Level 1 — AI Assistant / Deterministic Autonomy

Level 1 systems run predefined workflows. They act when a known condition occurs, but they do not choose between competing responses.

What it enables

Operations staff recover time by removing repetitive clicks, copy-paste work, and manual ticket updates. Repetitive clicks, copy-paste work, and inconsistent manual steps get replaced by consistent, auditable execution. The focus at this level is operational hygiene and repeatable response patterns, not incident resolution.

What it looks like in practice

Event-driven ITSM workflows open, route, update, and close tickets based on alert state changes. Scheduled tasks handle health checks, cleanup jobs, and maintenance. Predefined runbooks restart services, clear queues, or scale known-safe components when specific conditions are met.

What you need

How to measure success

Fewer manual steps per incident, reduced time on repetitive tasks, more consistent ticket quality, lower toil load on L1/L2 staff.

Common trap

Stale runbooks. The environment changes; the automation doesn’t. Predictable behavior stops being safe when the underlying assumptions no longer hold.

Moving to Level 2

Deterministic automation has a ceiling. It can only handle situations that match the script. To move beyond it, you need the system to incorporate context — related alerts, recent changes, dependency signals — and use that context to propose the next action rather than just execute a predefined one. Human approval stays in place as the safety bridge. That shift, from executing steps to recommending them, is where agents begin.

Level 2 — AI Agents / Conditional Autonomy

AI Agents that can recommend actions based on situational context and execute those actions with human approval. The human role shifts from doing the work to reviewing and approving it.

What it enables

The slowest part of incident response — figuring out what to do next — compresses significantly. The agent surfaces what matters, proposes a direction, and executes once approved, which means engineers focus on judgment and exceptions rather than assembly and coordination.

What it looks like in practice

An agent groups related alerts, checks recent deployments and dependencies, identifies a likely cause, recommends a runbook, and shows the proposed actions before execution. An operator reviews the evidence, approves the action, and receives a record of the outcome.

What you need

How to measure success

MTTR reduction, more consistent resolution paths, fewer escalations. Leading indicators include higher first-responder confidence and fewer handoff errors.

Common trap

Level 2 collapses back into manual work when change management integration is missing. If agents can recommend but approvals have no structured path, the bottleneck shifts from doing the work to navigating approvals.

Moving to Level 3

Removing human approval from the loop requires being explicit about what that approval was protecting against. The work at this transition is classification of which actions have a bounded blast radius, clear trigger conditions, defined validation steps, and a rollback path if something goes wrong. Level 3 applies only to incident classes that have met the organization’s evidence, policy, rollback, and validation requirements.

Level 3 — Advanced Agents / Mid Autonomy

Agents that execute well-defined workflows end to end without manual approval, within explicitly bounded scenarios.

What it enables

Faster recovery for common, repeatable issues without human involvement. The system handles the incidents you’ve proven it can handle safely, which reduces after-hours load and creates early evidence of self-healing capability.

What it looks like in practice

A service fails its health check, so the system restarts it, confirms recovery, and escalates if the health check still fails. A queue crosses a defined threshold, so the system checks consumer health, runs an approved recovery action, and verifies queue depth afterward. If a deployment produces a known error pattern, the system can roll it back, confirm that error rates return to baseline, and record the change.

Level 3 is the point where a known incident can move through detection, diagnosis, remediation, and recovery checks without waiting for manual execution. This is the basic closed-loop pattern behind self-healing ITOps.

What you need

How to measure success

Reduction in manual effort per incident category, fewer after-hours interventions for known issue types, higher auto-resolution rate with low rollback frequency, early signs of repeat incident reduction.

Common trap

Autonomous workflows have the potential to become a new source of incidents when observability of the automation itself is missing. You need visibility into what automation did, when, why, and whether it worked — not just visibility into the systems it touched.

Moving to Level 4

Level 3 agents run what you’ve defined for them. Level 4 requires agents that can select the right approach when the situation doesn’t fit a single predefined script — which depends on deeper domain context, specialization by environment or system type, and evaluation practices mature enough to validate that selection reliably. The capability gap is less about execution and more about judgment within a domain.

Level 4 — Expert Agents / High Autonomy

Specialized agents with deep domain awareness that can run multi-step, multi-tool workflows reliably across a defined operational scope.

What it enables

Complex incidents handled end-to-end within a domain, without a human acting as coordinator across tools. Operational knowledge that previously lived with a handful of experienced engineers becomes consistently executable at scale.

What it looks like in practice

A discovery agent classifies the incident and selects an approved playbook. If no suitable playbook exists, another agent drafts a reviewable procedure based on the incident context and system state. An engineer tests and approves the procedure before it is used for autonomous remediation.

What you need

How to measure success

Faster remediation on complex issues, consistent operational quality across teams and shifts, reduced dependence on tribal knowledge, playbook quality that improves over time rather than degrading.

Moving to Level 5

The shift to Level 5 is structural. Individual expert agents become coordinated systems: multiple agents sharing context, dividing work across domains, and feeding outcome data back into the system to improve future decisions. That requires shared policies, shared state, and organizational alignment on what cross-domain autonomy is permitted to do — which is a governance and architecture problem as much as a tooling one.

Level 5 — Agent Ecosystems / Full Autonomy

A coordinated system of specialized agents that can divide work, run parallel investigations, execute across domains, and incorporate outcome data to reduce repeat incidents.

What it enables

Complex incident handling without a human as the central coordinator. Parallel investigation compresses time-to-diagnosis. Outcome feedback creates a loop where the system improves rather than plateaus, pushing toward zero-touch resolution for incident classes that are well-understood and well-governed.

What it looks like in practice

During a service outage, one agent correlates alerts, another traces dependency impact, and a third checks recent changes. 

A remediation agent proposes or runs an approved recovery action while a coordinator maintains a shared incident state, updates ITSM, records each decision, and escalates when policy or evidence thresholds are not met. Afterward, the system creates a timeline and stores the findings for future incidents.

What you need

How to measure success

At this level, the primary metrics shift. MTTR matters less than incident avoidance — fewer repeat incidents, fewer customer-facing degradations, fewer severity-one events. The objective shifts from faster response to fewer incidents.

Key AI Capabilities By Use Case

The maturity levels describe how much agency your system has, but most teams plan work around operational problems, not abstract levels. The table below maps those problems to the capabilities that address them and the maturity range where those capabilities typically become available, so you can locate your priorities within the model rather than work through it sequentially.

Where To Go From Here

Autonomy can expand safely only when the system has connected data, controlled execution, clear permissions, and a way to verify or reverse its actions.

Start with one recurring workflow that has a clear success condition and low operational risk. Check whether the required data is connected, whether the response is documented, and whether recovery can be verified. Begin with recommendations or ticket enrichment, then expand to approved execution after the workflow performs consistently in production.

This progression is what Autonomous IT looks like in practice. Connected data informs the decision, policy sets the boundaries, the system carries out an approved action, and verification confirms whether it worked.

As maturity increases, the goal shifts from resolving incidents faster to reducing how often they happen.

FAQs