Cisco shipped AgenticOps last week. Microsoft, AWS, and Google are right behind them.
The conversation in every enterprise IT forum right now: can AI agents actually do this? Can they reason well enough? Can they troubleshoot accurately? Will they break something?
That's not the interesting question.
The interesting question is whether the infrastructure those agents would operate against is in good enough shape to support autonomous action at all.
The prerequisite nobody is discussing
Here's the pattern that keeps showing up: organizations evaluating autonomous operations deployments are spending most of their evaluation time on the agent layer — model quality, reasoning capability, human oversight workflows. Almost no evaluation time goes into what I'd call Autonomous Operations Readiness: the set of infrastructure conditions that have to exist before any agent can act safely.
Those conditions aren't new. They're the same ones a skilled human operator needs:
- Authoritative state — one source of truth for configuration, not three that sometimes agree
- Dependency awareness — a complete enough map to know what breaks if you touch X
- Recovery sequencing — a defined order for bringing systems back, not "figure it out when we get there"
- Authority boundary — a clear definition of what this operator is allowed to change, and what requires escalation
- Escalation boundary — the formal threshold at which the system stops acting autonomously and hands off to a human Every one of those requirements applies to human operators too. Most enterprise environments have gaps in at least three of them.
The part that gets glossed over in vendor demos
Every AgenticOps demo shows an agent that runs until the problem is resolved. Clean loop: detect, diagnose, remediate, validate, done.
Real operations environments need something different: an agent that runs until uncertainty exceeds a defined threshold, then escalates. The escalation boundary isn't a failure mode. It's the control mechanism. It's where "autonomous" ends and "supervised" begins.
Without a defined escalation boundary, you don't have an autonomous operations system. You have an automated system without a circuit breaker.
What actually happens when the prerequisites are missing
Think about the last time your environment had a contested change window — where the CMDB said one thing, what was actually deployed said another, and a third engineer had a different recollection of what was done six months ago. Human operators in that situation hesitate. They ask questions. They delay action until the picture is clearer. That hesitation is expensive. It's also the mechanism that prevents a misdiagnosed condition from becoming a multi-system outage.
Autonomous systems don't hesitate. They continue executing against the state they have.
When that state is incomplete — when dependency maps have gaps, when authoritative state sources are contested, when observability signals from different layers disagree — the failure that follows isn't just wrong. It's wrong at machine speed, across a wider blast radius, before the oversight layer has time to engage.
The risk most evaluation teams focus on: what if the AI makes a bad decision?
The risk worth more attention: what if the infrastructure doesn't know enough for any decision to be safe?
⚠ Worth checking: In your environment right now — does monitoring say healthy while the application layer reports degraded while the network says normal? A human operator can recognize that the signals conflict and escalate. An autonomous system without a defined escalation boundary will act on whichever signal its policy treats as authoritative.
Why every vendor ends up at the same layer
This is the part that makes sense once you see it: Cisco, AWS, Google, Microsoft, ServiceNow — they're all building toward the same architectural layer. Observability, policy, identity, automation infrastructure. Not because they copied each other. Because the prerequisite is identical regardless of which agent runs on top.
An autonomous remediation workflow that receives a "workload degraded" signal needs to know: who owns this workload (identity state), what policy governs isolation actions (policy state), what depends on this workload (dependency state), and what the current operational status of the environment is (operational state). Without all four simultaneously, any action the agent takes is a guess — a high-confidence guess, executed without hesitation.
That's why every vendor converges on the control plane layer. Autonomous systems can't construct operational state from scratch at runtime. It has to pre-exist.
Before you evaluate the agent, evaluate the environment
Before asking whether AI agents are ready for infrastructure operations, ask whether your infrastructure is ready for autonomous operators.
How much of your environment currently has:
- A single authoritative state source that wins conflicts
- Dependency documentation complete enough to query programmatically
- Defined recovery sequencing that doesn't require tribal knowledge
- Clear authority boundaries that an agent could be given without ambiguity
- A formal escalation threshold — the exact uncertainty level at which the system stops and asks for help Most honest answers land somewhere between "partially" and "not really."
That's not an argument against autonomous operations. It's an argument for where to start.
For the full architectural treatment — Framework #118, control plane substrate discussion, cross-pillar governance connection — the complete version is at rack2cloud.com:
Autonomous Operations Require Infrastructure Most Enterprises Don't Have
Originally published at rack2cloud.com
Top comments (0)