This is part 2 of my series on how to roadmap autonomous operations. Start at the beginning.
Most IT operations teams spend the majority of their capacity on reactive, repetitive work, and that model has hard structural limits: resolution time bound by human availability, cost that grows linearly with volume, and your best engineers consumed by toil. In Part 1 of this series, we introduced Autonomous Operations (AutOps) as the answer: an operation that detects, diagnoses, and resolves known scenarios on its own, continuously certifies new ones, and frees human capacity for higher-value work. And we made the case that the hard part isn’t the technology, it’s the roadmap.
Part 1 covered the strategic half of that roadmap: measuring success with the business metrics you already trust (Step 0), mapping the five triggers that define your automation scope (Step 1), baselining your operation so targets become a fundable plan (Step 2), decomposing MTTR to find that the fix is usually the smallest slice (Step 3), and defining the certification cycle - Assisted → Supervised → Autonomous - through which every scenario earns full autonomy (Step 4).
The principle underneath all of it: autonomy is a curve, not a switch. Part 2 is about climbing that curve in production: how each automated action executes, the hard limits that keep autonomy safe, the change-enablement and ChatOps layer that makes it auditable, and the domain-by-domain sequence for rolling it out. We pick up where Part 1 left off, at Step 5.
Step 5: Decide How Each Action Executes
Once you've decided to act, route the execution by complexity:
- Simple, API-level actions (restart a service, scale a resource, clear a queue, open or close a ticket) run as native workflows in your orchestration platform.
- Complex, host, or multi-server actions are handed off to your configuration-management automation, such as calling existing playbooks through its API. This protects the runbook investment you may already have.
- New, uncertified scenarios route through the assisted path: an AI agent investigates the off-catalog incident, proposes a diagnosis and fix, a human approves, and the action runs, which then enters the certification cycle.
Keep one platform as the single point of orchestration, governance, and audit, even when it delegates execution elsewhere. Centralized control without sacrificing execution capability is the goal.
Step 6: Set Guardrails and Permanent Exclusions
Autonomy needs hard limits that are enforced by the platform, not just written in a policy doc. Two kinds:
Guardrails are explicit rules for what the automation may not do, configured directly in your orchestration layer.
Permanent exclusions are actions that always require human validation, regardless of how mature the automation becomes. Common examples:
- Changes to core production systems in regulated or business-critical domains
- Massive or irreversible actions such as bulk data deletion, shutting down entire sites, or anything that's a one-way door
- Any action with regulatory compliance implications
Implement these as platform-enforced controls. A guardrail you have to remember to follow isn't a guardrail.
Step 7: Build in Change Enablement and ChatOps
This is the enabler that most AutOps plans forget about, and it's load-bearing. Every automated remediation is a change to production. At scale, autonomous changes need change records, risk assessment, and an audit trail, which should be non-negotiable in any regulated environment.
ChatOps is the bridge. When an incident fires, your ITSM platform declares it, spins up a war room in your chat tool, automatically pulls in the right responders, drives approvals and change records from the conversation, and logs the entire timeline. Remember from Step 3 in Part 1 that coordination is usually the largest slice of MTTR. ChatOps attacks it directly while making every action auditable by default.
There's also an organizational change dimension. The capacity you free up only materializes if people trust the automation and get redeployed and reskilled, rather than quietly continuing to do the work by hand because they don't trust the bot. Establish adoption as a formal workstream with a clear owner to ensure it isn't overlooked.
Step 8: Sequence the Rollout by Domain
Don't boil the ocean. Roll out domain by domain, proving results in each before scaling to the next. A reliable sequence:
- Start with your pioneer domain. Wherever you already have the most automation traction and the best telemetry. Consolidate and formally certify what's working, and use it to quantify benefits with real numbers.
- Replicate in your highest-volume domain next. High volume plus repetitive, standardized actions is where the proven model pays off fastest, and where good ticket history and telemetry already exist.
- Extend to shared corporate services and infrastructure, the internal platforms that support everything else.
- Save the hardest, most regulated domain for last. Bring it in only once your scenarios, methodology, and governance are mature and proven. Where data sensitivity is a concern, make data separation an explicit architectural principle rather than a later patch.
Within each domain, prioritize what to automate first by four criteria: volume of occurrences, current human effort, risk of the action, and availability of telemetry and historical data.
The Organizing Model: A Maturity Curve With a Foundation
Tie it all together with a single picture. Your operation climbs four stages - Reactive → Assisted → Supervised → Autonomous - and different domains sit at different points on the curve at any given time. This is normal. Rather than an immediate switch, move each domain up the curve as it earns the right.
Running underneath every stage are three foundations that set how fast you climb:
- Measure - baseline incidents, MTTR, and cost, so every phase is funded on evidence, not estimates.
- Change-enable and ChatOps - because every automated fix is a change that must be fast and auditable.
- Adopt and redeploy - because freed capacity is only real if people actually move to higher-value work.
The Bottom Line
The narrative is simple: demonstrate first, consolidate second. Light up the sources that don't depend on slow external systems and generate results in your first quarter. Certify what already works, baseline what you don't yet know, and prove the model in one domain before scaling. Convert your directional targets into formal commitments only once you have data to back them up.
Autonomous operations aren't a product you buy or a switch you flip. It's a curve you climb deliberately. One certified scenario at a time, on a foundation of measurement, governance, and trust. Build the foundation, and the autonomy follows.
Looking for more support? Reach out to our team.
