Ivanti shipped an autonomous service desk agent in April. It creates incidents, submits requests, and searches knowledge bases without an analyst touching them. As we covered at the time, Grand Bank CIO Robert Hanson said his team had been spending the bulk of their time on repetitive requests before the deployment:
“Spending the bulk of our time handling repetitive requests. As we move toward implementing these capabilities, we expect to automate routine tasks and enable our team to focus more proactively on higher-value initiatives.”
Ivanti CEO Dennis Kozak argued the status quo is unsustainable:
“Organizations need systems that can not only detect issues, but also have the capability to decide and act securely and at scale. While many other solutions offer visibility, they still require constant human intervention.”
There is research to support that. McKinsey’s Reimagining tech infrastructure for (and with) agentic AI report cites a multinational that automated up to 80% of roughly 450,000 annual tickets after moving to agent-led resolution, redeployed half its service team, and recorded a customer satisfaction score of 4.8 out of 5. But before deploying anything, the organisation rebuilt its workflows and customer journeys to support agent-led resolution. The agents worked because the estate was redesigned for them first.
Most Estates Haven’t Been Redesigned for Anything
McKinsey’s survey puts 62% of organisations in the piloting stage. No more than 10% are scaling agents in any given business function. The report calls it a “plumbing problem”: infrastructure built for ticket-based, human-led workflows cannot support agents that need to cross systems, execute actions via APIs, and operate under governance controls.
Red Hat CEO Matt Hicks, speaking at Red Hat Summit on 13 May, described what that looks like in practice:
“We’re in a back-to-basics mode where you have to learn how to patch your systems. One year ago, you might have argued the risk was okay.”
For UC teams, the integration problem is concrete. A call quality incident in a Teams or Cisco environment typically involves network telemetry, device health, carrier status, and ITSM records simultaneously. An agent that cannot move reliably across all of those hands the ticket back to a human. That is the outcome the deployment was supposed to prevent.
Monitoring the Agents Is a Separate Problem Most Organisations Haven’t Solved
Buying an agent does not mean you can see what it is doing. Standard uptime monitoring records that a service is running. It does not record what an agent decided, which systems it changed, or why.
Gartner VP Analyst Padraig Byrne, speaking at the Gartner IT Infrastructure, Operations and Cloud Strategies Conference in Sydney, identified the gap:
“AI is everywhere, but most organizations are still figuring out how to monitor and trust these systems. That visibility gap makes scaling risky. Unlike traditional software, AI’s decision making is often hidden, making it hard to explain or trust, yet errors can cause substantial financial loss, reputational damage and regulatory scrutiny.”
Gartner forecasts 40% of organisations deploying AI will have dedicated observability tooling by 2028. The majority won’t for at least the next two years.
The Financial Pressure Is Only Going One Way
McKinsey projects IT infrastructure costs will increase two to three times by 2030 as AI workloads grow, against budgets expected to stay flat. Agents reducing operating costs is the only route through that squeeze, and it requires them to work reliably at scale. On an unprepared estate, the opposite happens. Inference costs accumulate without visibility. Agents working from stale or inaccurate configuration data generate errors that produce tickets rather than close them.
McKinsey identifies four prerequisites: a CMDB accurate enough for agents to act on; actions exposed through APIs with policy checks built in; a governance model defining what agents can and cannot do; and active monitoring of inference costs. For most UC and ITSM teams, those four things are not a checklist. They are a programme of work, and it needs to happen before the procurement decision, not after it.
