Gartner predicts that by 2028, 40% of I&O organisations running agentic I&O at scale in production will experience a business-critical service disruption, up from less than 1% in 2026. Most of that risk sits in the integration layer the AI acts through. The build gets budgeted; the running of the connections, and the disruption across the business when one fails, usually get nothing.
This article covers what AIOps integration is, why AI agents stall on the write path, how the four common approaches compare, and what changes when the integration layer is operated by a provider whose job is to keep it running.
Key takeaways
- AIOps tools read telemetry easily. Acting on ITSM tools, CMDBs, and partner systems needs write connections that do not come with the licence, and that is where projects stall.
- Gartner expects 60% of enterprises to deploy agentic AI for IT infrastructure operations by 2029, and predicts that 40% of I&O organisations running it at scale in production will hit a business-critical service disruption by 2028.
- When an integration under an AI agent breaks, the damage is organisational: the process stops, customers wait, and SLA penalties accrue while IT repairs the connection.
- Most IT operations are multi-party. An agent that only acts inside one organisation's tenant misses the incidents that cross customer, outsourcer, and partner boundaries, which are the expensive ones.
- A managed integration service gives AI agents governed write access with an owner and an SLA per connection, without adding integration workload to the internal team.
For the operating model behind managed integration services, the Integration Ops book covers lifecycle phases, ownership patterns, and playbook examples in depth. Download it free.
What is AIOps integration?
AIOps integration is the set of managed connections that let an AIOps platform or AI agent both read operational data from the tools that produce it and write actions back into the systems of record where IT work is tracked. Reading covers monitoring, logging, and event data. Writing covers incidents, changes, configuration items, and notifications, often into tools other organisations own.
The commercial distinction matters: reading arrives with the AIOps licence as a product feature, while writing has to be built, run, and paid for separately, usually later than planned.
Why do AIOps tools stall at the write path?
Telemetry systems are built to be read from. Monitoring platforms, log stores, and observability tools publish data by design, so ingest connectors are cheap for vendors to ship and easy to demonstrate.
Systems of record behave differently. Writing an incident into ServiceNow, updating a configuration item, or raising a ticket in a customer's Jira Service Management instance means passing through authentication, field validation, workflow rules, and change control that the AIOps vendor does not own. Each target system has its own data model and its own release calendar.
Three consequences follow from that asymmetry.
The value sits behind the writing. Correlation without action produces a better dashboard, while most AIOps business cases assume automated resolution, which is a write-path capability from end to end.
Every new target is a new project. Point-to-point connectors are quick to build and expensive to keep, and once an agent acts through them, each one is also a damage protection project waiting to start. This is the same point-to-point pattern that produced integration debt in the first place, now repeated per agent and per system.
Nobody owns the connection, but the whole organisation carries its failures. The AIOps platform has a product owner. The 20 or 30 write paths beneath it usually have an engineer with a backlog and no service level, and while one of them is down, the process it carries has stopped: tickets miss the right desk, customers wait, and SLA clocks run.
Most IT operations cross organisational boundaries
An AI agent that resolves incidents inside a single tenant handles the cheap cases. The costly incidents involve more than one company.
A typical enterprise estate now spans an infrastructure provider, a service desk provider, several application vendors, and internal teams, each with their own tooling. Service providers face the mirror image: every client arrives with a different ITSM platform. Connecting service management across organisations decides whether an agent can close an incident where the customer tracks it or only file a note about it in your own system.
Cross-company write access raises questions no AIOps platform answers on its own. Which identity does the agent use in the customer's system? What data is allowed to cross the boundary? Who is paged when the write fails? What happens when the partner upgrades their platform with no notice?
These are integration governance questions, and in practice they are the reason autonomous action stays switched off in production long after the platform goes live. While it stays off, the business case built on automated resolution stays unrealised, and the organisation keeps paying people to do the work the agent was bought to do.
What AI agents need from the integration layer
AI agents for IT operations need three things from the layer beneath them, none of which are features of the agent itself.
Reach. Authenticated, permission-scoped write access into every system where the work lands, including systems owned by customers, outsourcers, and partners.
Endurance. Connections that hold through platform releases, API version changes, tool migrations, and certificate expiry without manual repair. Most integration cost accrues in the years after go-live.
Accountability. A named owner per connection, monitored continuously, under a service level that covers the integration outcome and not only platform uptime. When an agent acts through a connection, that owner is also the person who answers for the business impact when a write goes wrong.
The same requirement list applies whether the agent lives in an AIOps platform, an ITSM suite, or a general-purpose model. For a wider view of how this plays out beyond IT operations specifically, see our analysis of what changes when AI agents enter your integration layer.
What the Gartner forecasts actually say about risk
Adoption is not in question. Gartner expects 60% of enterprises to deploy agentic AI for IT infrastructure operations by 2029, up from fewer than 10%, and forecasts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025.
The risk forecasts are more useful for planning. Gartner predicts that by 2028, 40% of I&O organisations running agentic I&O at scale in production will experience a business-critical service disruption, up from less than 1% in 2026. Separately, Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 because of escalating costs, unclear business value, and inadequate risk controls.
Read the cancellation drivers with an integration hat on and they describe a familiar situation. Cost escalates because every additional system the agent touches becomes its own connector project, and then its own damage protection project once autonomous writes begin. Business value stays unclear for as long as the agent can diagnose an incident but cannot close it in the system where the work is tracked. And risk controls stay inadequate when nobody understands what the agents are doing, at a pace no one can follow any more.
The difference between a platform you operate and a service that is operated for you becomes sharper once autonomous action is involved. A platform gives your team a better place to do the work. It does not remove the work, and an AI agent does not remove it either.
Where a managed integration service fits
A managed integration service like ONEiO takes ownership of the connections themselves. Design, build, monitoring, change, and accountability sit with the provider under a subscription with a service commitment attached.
For AI agents in IT operations, that changes the practical picture in a specific way. The agent gets any-to-any reach without a connector project per system, including into customer and partner environments where your own team has no standing access. The connections are watched continuously, so a broken write path surfaces before an autonomous workflow repeats the error at machine speed. And ownership sits outside your team, with a name and a number attached, so when an agent's action goes wrong in a customer's environment, somebody is already accountable for the connection it travelled through, and the disruption stops at one incident instead of spreading through the service.
"Unbothered. I think that's the thing, how it changed us... we use our time to do other things, to monitor other things instead of the data exchanges." That is Dmitri at the City of Espoo, describing the capacity that comes back when the integration layer stops being an internal maintenance function. That capacity is what most AI programmes are actually short of.
When this is not the right choice. If your AI operations use case lives entirely inside one platform you already own, with no cross-organisational writes and no partner systems in scope, native connectors will cover it and a managed service is unnecessary overhead. The same is true if you have a funded, staffed integration team with documented ownership and an existing service level. The case for a managed integration service starts where the estate becomes multi-party, the change rate is continuous, and the internal team is already the constraint.
Bottom line on AIOps integration
AIOps and AI agents are being sold as intelligence for IT operations, and intelligence has rarely been the binding constraint. Engineers have known which systems were failing for a long time. What has been missing is a reliable, owned, accountable way for anything to act across those systems without a person in the middle.
Only the reading arrives with the AIOps licence. The acting arrives as a programme of work whose cost, risk, and ownership decide whether the AI investment produces automated resolution or an expensive second opinion. That programme also decides who absorbs the damage when an autonomous action fails: the IT team that repairs it, and the parts of the business that stand still while they do.
The practical sequence is to settle the integration layer first: who operates it, what it is committed to, and how it changes when a partner or customer system changes. Autonomy on top of an unmanaged integration estate multiplies whatever weaknesses that estate already has.
Want to talk about how this applies to your environment? Book 30 minutes with a ONEiO integration expert.
