In this perspective 7 sections
AI agents can only execute reliable work when the processes, inputs and guardrails beneath them are designed to be operated.
Over the past few weeks, I attended Kaseya Connect Europe in Prague and Xurrent SPARK in Antwerp.
Two different events. Two different platforms.
But the same development was clearly visible at both.
AI is moving beyond answering questions and generating suggestions.
Agents are starting to perform work.
They will help classify requests, collect missing information, select the right procedure, trigger actions, validate results and update the service management platform.
That sounds impressive. And it is.
But while listening to the different announcements and demonstrations, I kept coming back to the same thought:
An agent can only operate as well as the operation it enters.
If your services are unclear, your request templates overlap, your documentation is outdated and every customer follows a different process, adding an agent will not magically solve that.
It may simply execute the confusion faster.
From assistance to execution
The first wave of AI in IT operations was mostly about assistance.
Summarising a ticket. Drafting a response. Finding a knowledge article. Suggesting a troubleshooting step. Helping an engineer write a script.
Useful improvements, certainly. But the engineer was still in control of the actual process.
Agents change that.
An agent can potentially receive a request, understand the intent, retrieve additional context, decide which process applies and perform part of that process.
The IT management platform is no longer just documenting what people do.
It starts participating in the work itself.
That is a significant shift.
But it is not only a technological shift.
It is also an operational one.
Because the moment a platform starts performing work, every vague process, hidden exception and unclear responsibility becomes a real risk.
Why people can hide bad processes
Many IT operations work because experienced people keep them working.
They recognise a customer from the wording of a request.
They know that a particular template is rarely used correctly.
They remember that one customer has a different agreement.
They know which colleague to call when ownership is unclear.
They understand that the documentation is incomplete, but can fill in the gaps from experience.
In practice, people continuously compensate for the weaknesses in the operating model.
That may work for a long time.
It may even feel efficient. But it is not scalable.
And it is definitely not a good foundation for autonomous execution.
An agent does not know that a badly named service actually means something else.
It does not automatically understand which historical exception still applies.
It cannot safely work with instructions that only make sense to the engineer who wrote them.
It needs structure. It needs context. It needs clear boundaries.
The operation must be explicit enough to understand.
Standardise before you automate
This sounds obvious, but many organisations still start in the wrong place.
They look at the AI feature first.
Which agent can we enable? Which tickets can it resolve? Which process can we automate? The better question is:
Which part of our operation is already predictable enough to be executed consistently?
That immediately brings you back to the basics.
Are services clearly defined?
Do similar requests use the same process?
Are the required inputs known? Is ownership clear? Can the expected outcome be validated? Are exceptions documented?
Is there an approval step when the risk increases?
Without that foundation, automation remains fragile. The same applies to AI agents.
The more freedom you give an agent, the more important it becomes that the environment around it is predictable.
Turn operational knowledge into interfaces
Over time, IT service management environments tend to collect exceptions.
A separate workflow for one customer.
Another SLA configuration for a specific agreement.
A new template because the existing one is not quite right.
A slightly different status model for another team.
Most of these changes make sense when they are introduced.
The problem appears later.
Eventually, the platform no longer represents a clear service model.
It represents years of individual decisions.
That is already hard for employees to understand.
It becomes almost impossible for an agent to navigate safely.
The solution is not to remove every difference between customers or services.
The solution is to model those differences properly.
One SLA model with clear types is often better than many separate SLA workflows.
One strong request template with structured options is often better than five nearly identical forms.
One standard process with explicit variables is often better than customer-specific logic hidden throughout the platform.
The distinction is important. Customisation creates another process.
Configuration allows the same process to behave differently based on context.
That is how you create scale without pretending that every customer is identical.
Request templates become operational interfaces.
A request template is often treated as a form.
The user enters some information. A ticket is created.
Someone reads it and decides what happens next.
But when agents become part of the process, the template becomes much more important.
It becomes the starting point for execution.
A good request template should make clear:
- which service the request belongs to;
- what the user is asking for;
- which information is required;
- which approval applies;
- which risk level is involved;
- which standard action may be performed;
- what the expected result should be;
- and when the process must be escalated.
That means templates are no longer only a service desk concern.
They are part of the operational architecture.
The better the request is structured at the beginning, the less interpretation is required later.
That helps employees today. It helps automation today.
And it creates the foundation for agents tomorrow.
A service catalogue describes how the operation works.
The same is true for the service catalogue.
Too often, a service catalogue is mainly designed as a portal navigation structure.
A place where users can find a form.
But a good service catalogue does much more.
It describes what the organisation provides.
It defines the boundaries of the service.
It connects requests, agreements, ownership, procedures and outcomes.
It creates a shared language between users, engineers, management and automation.
Agents make that shared language even more important.
Take something simple like onboarding a new employee.
A person understands that this could involve an account, licences, a laptop, access rights, groups, applications and perhaps several external suppliers.
But an agent needs those dependencies to be explicit.
It needs to know which actions belong to the standard process.
Which actions require approval.
Which actions depend on the employee type.
Which actions can be executed automatically. Which actions need a human decision.
That is when the service catalogue stops being a list of forms.
It becomes a model of the operation.
Reserve human judgement for exceptions
I do not believe the objective should be to automate everything.
Some work should remain human. Complex incidents. Architecture decisions. Security exceptions. Customer-specific trade-offs.
Changes where the impact cannot be predicted reliably.
Those situations require experience, context and judgement.
But much of the daily workload in IT operations is not like that.
It consists of recognisable patterns. The same questions. The same checks. The same standard actions. The same validation. The same updates.
People should not have to spend most of their time repeatedly interpreting work that could have been structured properly.
That is where agents can make a real difference.
Not by replacing judgement.
But by removing unnecessary interpretation from standard work.
Agents can handle patterns. People can focus on exceptions.
That is a much more useful discussion than simply asking how many tickets an agent can close.
Build guardrails into the operation
The moment an agent can perform an action, governance becomes part of the technical design.
An agent needs an identity. It needs limited permissions. Its actions need to be logged. High-impact actions may need approval. Results need to be checked. Failures need a rollback path.
There must be a clear point where the agent stops and hands the process back to a person.
And there must always be human ownership.
An autonomous action still belongs to a service.
It still belongs to a process.
Someone must remain accountable for the way that process is designed and operated.
Without those guardrails, an agent becomes another privileged actor in an already complex environment.
With them, it becomes a controlled extension of the operation.
Start by cleaning up the normal path.
The organisations that benefit most from agents will not necessarily be the first to activate them.
They will be the organisations that first make their operations understandable.
That may involve work that does not look very innovative.
Reducing duplicate request templates. Standardising service names. Removing unnecessary workflow variations. Improving classifications. Defining clear ownership. Documenting standard procedures. Making approvals explicit.
Turning exceptions into policies instead of tribal knowledge.
Separating customer-specific data from the standard process.
But that is exactly the work that creates a scalable platform.
The normal path must become clear before it can become autonomous.
Become operable before autonomous
The arrival of agents does not reduce the importance of IT service management.
It exposes whether it was ever truly designed.
Processes must become clearer. Services must become explicit. Data must become reliable. Permissions must become deliberate.
Operational knowledge can no longer remain hidden in the heads of a few experienced engineers.
Because an agent will not fix an operating model built on ambiguity.
It will expose it. It will accelerate it.
And if given enough access, it may execute that ambiguity at scale.
That is the real dividing line in agentic IT.
Not between organisations that use AI and those that do not.
But between organisations whose operations are designed to be executed and those that still depend on people continuously interpreting the gaps.
The winners will not be the companies with the most agents.
They will be the companies with the clearest services, the strongest guardrails and the least operational ambiguity.
Before AI can operate IT, IT must become operable.
And once it is?
The ITSM platform stops being the place where work is recorded.
It becomes the place where work begins.
At Clouvex, I write about the point where technology meets operational reality.
About EUC platforms that must remain manageable after implementation.
About infrastructure that needs to be operated, not merely deployed.
About the path from an initial viable solution towards a platform that is mature, scalable and valuable.
And about the architecture, standards and operational decisions required to get there.
Because whether we are discussing AI agents, Azure Virtual Desktop or the path from a necessary viable product to a minimum viable platform, the underlying question remains the same:
Are we implementing technology, or are we designing something that can continue to operate?
That is the difference between a solution that works today and a platform that is ready for what comes next.
← Back to Operations perspectives