Most enterprises approaching agentic AI begin with the same question: which model should we use? It's the wrong starting point. In practice, model capability is rarely what determines whether a programme succeeds or fails. What determines it is everything that sits underneath—and most enterprises haven't fully reckoned with that yet.
Agentic AI in IT operations is not a modest upgrade from what most organisations have already deployed. Predictive models surface recommendations. Generative AI helps humans draft and synthesise. Agentic systems do something categorically different—they act. They resolve incidents, reconfigure infrastructure, trigger downstream processes. Often without waiting for a human to confirm anything. That shift from recommendation to action changes the readiness equation entirely and the risks that were merely inconvenient in earlier AI deployments—patchy data, absent guardrails, disconnected workflows—become genuine operational liabilities.
We have worked with enterprises that invested heavily in model selection while underinvesting in the foundations that determine whether that capability can be deployed safely at all. The result is agentic AI that performs impressively in a sandbox and struggles badly in production. Getting this right requires thinking about readiness differently from the start.
Foundation one: Unified telemetry and data quality
If there is one thing that separates enterprises genuinely ready for autonomous IT operations from those that aren't, it is how deliberately they have built the infrastructure to collect and normalise operational data. It is the work that everything else depends on.
Agentic systems consume telemetry to understand the state of the environment and decide what to do. When that telemetry is inconsistent or siloed across teams, the agent is essentially reasoning over a distorted picture of reality. It can misinterpret signals, act on stale data, or—more dangerously—miss the early indicators of a cascading failure because the relevant logs live in a system it can't correlate against. A human operator brings contextual judgement to ambiguous inputs. An agentic system acts on what it receives.
OpenTelemetry is worth naming specifically here. As a vendor-neutral open standard for collecting and exporting metrics, events, logs and traces across heterogeneous environments, it normalises telemetry at the pipeline level without requiring a wholesale replacement of existing agents. The difference between an autonomous system reasoning over standardised, correlated telemetry versus one reasoning over best-effort normalisation of disparate formats is not marginal. It is the difference between a trustworthy foundation for autonomous action and a foundation that will eventually produce an embarrassing incident.
Foundation two: Governance and guardrails
The instinct in many organisations is to treat governance as a constraint—something that slows agentic AI down. We'd push back on that framing quite directly: governance is what makes autonomy scalable in the first place.
An agentic system without guardrails is not more capable. It is more dangerous. In IT operations, the blast radius of an incorrect autonomous action can be significant and fast-moving. A misconfigured rollback, an erroneous failover, a capacity decision that cascades across dependent services before anyone has noticed something is wrong. The question is never whether to constrain agentic systems. It is how to constrain them intelligently, so that autonomy expands as trust is earned rather than as risk accumulates quietly in the background.
In practice, this means defining clear boundaries for what a system is permitted to do without human review. Low-risk, high-frequency actions—restarting a service, acknowledging a known alert pattern—can be fully automated relatively early. High-consequence actions involving production databases or revenue-impacting systems should retain a human-in-the-loop step, at least until the system has demonstrated consistent judgement over a meaningful period of time. Not a week. Not a sprint. Time enough to encounter edge cases.
The enterprises that invest early in building this governance architecture scale their agentic operations considerably faster than those that treat it as a later-stage concern. Getting the action taxonomy right, making approval workflows explicit, ensuring there's a credible rollback mechanism before something goes wrong—that groundwork is what allows autonomy to expand without the programme losing organisational confidence. Trust, once broken by an autonomous action that goes wrong at scale, takes a long time to rebuild. We've seen programmes stall for months after a single incident that, with better guardrails, would have been caught before it propagated.
Foundation three: Workflow integration
A client we worked with last year had done almost everything right. Clean telemetry pipeline, a governance framework their CISO had actually signed off on, a model that performed well across their incident scenarios. Three months into production the programme had hit a ceiling nobody had anticipated—the agent could diagnose and remediate within its own operational domain competently, but a significant portion of incidents required action across team boundaries. Triggering a deployment rollback meant touching the CI/CD pipeline owned by a separate engineering team with its own approval gates. Scaling infrastructure meant going through a capacity workflow that had been designed around quarterly planning cycles, not autonomous real-time decisions. The agent kept arriving at the right answer and then stopping at a boundary it had no path across.
That is the workflow integration problem in concrete form. A capable agentic AI that cannot act within existing operational workflows is, in practice, an expensive recommendation engine. None of the other foundations matter at the point where the agent's decision-making consistently terminates at an organisational boundary—those friction points compound faster than most teams anticipate and the programme quietly loses its mandate.
The gap between demo and production is widest here because demos are built in controlled environments with clean APIs and simplified process flows. Production environments have workflows that were designed for human actors navigating organisational realities—approval gates, team boundaries, planning cadences that bear no relationship to the speed at which an autonomous system operates. Integrating into that reality requires API connectivity work, genuine process redesign and a candid internal conversation about whether existing workflows need to evolve to accommodate a new kind of operational actor.
Most enterprises haven't had that conversation yet. The ones that start it before they need it are significantly better positioned.
Foundation four: Model selection
There is no shortage of guidance on this. Benchmarks, leaderboards and analyst briefings treat model capability as the primary variable in AI success. It matters. It just matters considerably less than most enterprises assume and it is almost certainly not where the energy should go first.
In IT operations, the tasks that agentic systems perform are well-defined enough that several capable models can handle them adequately. The differentiator is rarely whether the model can reason well in isolation on a benchmark. It is whether the model is receiving high-quality telemetry, operating within appropriate guardrails and able to act through integrated workflows. A well-governed, well-integrated agentic system built on a capable but unremarkable model will consistently outperform a state-of-the-art model sitting on a fragmented data foundation with no guardrails and poor workflow connectivity. We have seen this play out directly and it is not close.
Model selection is also the most reversible decision in the stack. Swapping a model is relatively straightforward once the surrounding infrastructure is solid. Rebuilding a data foundation or redesigning governance architecture is not. Enterprises that lead with model selection tend to find themselves revisiting the harder questions later—usually after something has gone wrong and the post-mortem is uncomfortable.
The readiness lens that changes everything
The hardest conversation we tend to have with clients is usually the earliest one—telling them that the model they've spent three months evaluating is, genuinely, the least of their problems. That the observability layer they've been treating as a reporting convenience is actually load-bearing infrastructure. That their change management process, as currently designed, will quietly throttle any autonomy they manage to deploy.
Autonomous IT operations is not an AI project with some infrastructure considerations attached. It is an operational transformation and the AI capability is only as good as what sits underneath it—data foundations, governance architecture, workflow integration. Most enterprises have not fully established those things. Some know it and are working on it. Others find out the hard way, usually somewhere between the pilot and the first serious production incident.
The organisations that get this right aren't necessarily the ones with the largest AI budgets or the most advanced models. They're the ones that were honest early about where the gaps were—and spent their energy there first.
