The service desk's routine work suits an agent; its authority does not. Connected to an IT service management platform, an agent can read and classify tickets, route them, answer from the knowledge base and fulfil low-risk catalogue requests. Declaring major incidents, approving changes, granting access and editing the configuration database stay with people. It must never pause service-level clocks.
What does the connection do, and who owns it?
An IT service management (ITSM) platform runs incidents, service requests, problems, changes, the knowledge base and usually the configuration management database. Service desks spend much of their time on classification, routing, repeat questions and standard requests. An agent can take much of that. It can also, if badly scoped, approve its own changes, reset credentials for the wrong person, or make the service levels look better than they are.
The head of IT service management owns the agent's permissions. The change manager owns anything touching change. Security owns access and credential requests. The ITSM platform administrator configures it.
What are the steps to connect it?
- Person, head of service management: lists capabilities by ticket type and action.
- Person, ITSM administrator: creates the agent's identity with its own assignment group, so its work is visible and reportable.
- Person, ITSM administrator: grants permissions per record type: read on tickets and knowledge, write on classification and routing fields, create on standard requests from an approved catalogue list.
- Person, security: removes access-related actions. Password resets, multi-factor resets and access grants are not fulfilled by the agent; they go to the identity team or self-service with strong verification.
- Person, change manager: excludes change approval and limits the agent to drafting change requests.
- Person, head of service management: sets held actions: priority one classification, configuration database updates, closing tickets without user confirmation.
- Agent, depth 1: runs in shadow, classifying and routing alongside analysts.
- Person, head of service management: approves the agent's depth.
- Person, ITSM administrator: tests revocation and confirms the agent's open tickets return to a human queue.
What is scoped per capability, and at what depth?
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read tickets and knowledge | Retrieves for the task | 1 | Nothing |
| Classify and route | Sets category, priority up to two, group | 3 | Priority one |
| Answer routine questions | Replies from approved knowledge articles | 3 | Article content |
| Fulfil catalogue requests | Completes approved low-risk items | 3 | Adding items to the list |
| Raise incidents from alerts | Creates and links incidents | 3 | Declaring a major incident |
| Draft a change request | Prepares the request | 2 | Approval by change authority |
| Update configuration records | Proposes the update | 2 | Applying it |
| Close tickets | Closes after user confirms | 3 | Closing without confirmation |
| Access and credential requests | Routes to the identity team | 1 | Fulfilling them |
Why should the agent never touch service-level clocks?
Service levels are measured by timers that pause in certain statuses, such as waiting for the user. An agent rewarded, even indirectly, for meeting service levels can learn to move tickets into paused statuses or close them early. Status changes that stop a clock should follow strict rules and be sampled. How targets for the agent's own work should be set is covered in how do you set service levels for an AI agent?, and the basics of the underlying commitments in what is a service level agreement?
What is recorded?
The ITSM platform keeps ticket history under the agent's identity. Each entry carries the verdict identifier from the agent's own record, which holds the sources used, the bound that decided and any approver. Incidents involving the agent itself are tagged so they can be reviewed separately. Where ITSM incidents feed your risk records, link them through the same identifiers; see how to connect an AI agent to your governance, risk and compliance platform.
Which controls make it safe?
No access fulfilment. Social engineering of the service desk is a common attack. An agent that can reset credentials is a target.
Approved catalogue list. Only listed low-risk requests are fulfilled; new items are added by a person.
Major incidents declared by people. Declaring one starts communications, escalation and, for EU financial entities under DORA, classification for possible reporting. A person decides.
User confirmation before closure. Evidence: the user's confirmation on each closed ticket.
Knowledge articles reviewed. The agent answers only from approved articles, not from old ticket notes.
What should you measure?
Misrouted tickets, reopened tickets after agent closure, catalogue requests fulfilled and failed, answers rated unhelpful, time to route, held priority-one proposals and decisions, and status changes that paused clocks. Report the agent's ticket outcomes separately from analysts', so its performance is visible.
Where does it usually go wrong?
The agent gets an analyst role. Analysts can do almost anything in the platform. Build a narrow role.
Old tickets become knowledge. The agent learns fixes from closed tickets that were wrong or one-off. Use reviewed articles.
Users cannot reach a person. Repeat contacts go back to the agent. Offer a route to an analyst on every response.
Service levels improve on paper only. Paused clocks and early closures flatter the numbers. Watch reopen rates.
Where Pryme fits
In Pryme, the ITSM agent is certified on your own past tickets, and access and credential actions fall outside the agent's role scope, so they are refused and filed. Held items wait for named analysts. The rollout approach is in deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Can the agent reset passwords if the user is verified?
Keep it with self-service tools that use strong verification, or with the identity team. The agent can guide the user to those routes. An agent holding reset rights is an attractive target for impersonation.
Should the agent create problem records?
It can propose them when it sees repeated incidents with a common cause, at depth 2. A problem manager decides whether to open one.
Can the agent run fixes on servers or devices?
That is a different connection, to infrastructure rather than to the ITSM platform, and it carries far greater risk. Treat it as a separate capability with its own approval, change control and certification cases.