Rethinking AI in ITSM: the data underneath the agent

An AI agent can answer from an old article and still sound convincing. It can’t safely change access, update an incident, or trigger a workflow unless it understands what’s true now.

That’s the tension behind AI ITSM. The market often measures progress by queue coverage, ticket deflection, and faster routing. Those metrics matter, but they don’t answer the harder question: can an agent make a safe decision from live, permission-aware data?

An autonomous IT agent is only as safe as the source it is grounded in.

This matters because the hardest IT issues rarely stay inside the service desk. A recurring incident might connect to a recent product deployment, an active engineering issue, a configuration change, or a user’s current permissions. The next stage of AI service management depends less on better answers and more on trusted context, governed actions, and shared memory across systems.

TLDR: what changes when AI acts, not just answers

• AI ITSM is safe only when it uses current data and respects user permissions.
• An agent acting on yesterday's export automates the outage
• The hardest tickets cross into product/engineering
• Maturity = safe decisions, not queue coverage
• Requirement: live data + permissions in memory, plus governed write-back.

What is the AI ITSM promise everyone is selling?

AI ITSM promises a faster service desk. Employees describe a problem in plain language, and the system identifies intent, searches relevant knowledge, routes the request, and offers a resolution.

That promise is reasonable because service desks handle many repeatable requests, from password resets, account unlocks, and software access to device requests and incident updates. They also manage standard approvals and common “how do I” questions, making these workflows strong candidates for automation.

This is where ITSM automation delivers clear value. It reduces manual triage and helps teams respond consistently. It can also improve mean time to resolution, or MTTR, when the request follows a known path.

The next step is agentic AI ITSM. Instead of stopping at a suggested response, an agent can perform several steps across connected tools. It might check a user’s identity, confirm eligibility, open a request, obtain approval, call a provisioning workflow, and close the loop.

That sounds like a natural progression. Yet the risk also increases with every action. Answering from stale data may produce an unhelpful response. Acting on stale data may change the wrong account, reopen a resolved incident, bypass an approval, or make a service outage worse.

That’s why an IT self-service strategy should go beyond conversational intake. It should help employees reach resolution while giving IT leaders control over the actions an agent can take.

The market is also moving from experiments toward larger AI investments.

NVIDIA’s sixth annual State of AI in Financial Services survey, based on responses from more than 800 industry professionals, found that 65% of organizations are actively using AI, up from 45% in the previous year. In addition, 61% are using or assessing generative AI, while 42% are using or evaluating agentic AI.

Key takeaway: ITSM automation is moving from routing and recommendations toward execution, but execution requires stricter controls than answer generation.

What is the agent actually acting on?

Imagine an employee reports that a workflow stopped working after a recent deployment. A conventional agent searches an old knowledge article and finds a similar incident from several months ago. The article recommends restarting a service. The old incident suggests the same fix.

But the current situation is different. A product team has changed the workflow. Engineering has opened an issue for a related regression. The employee’s role has also changed, so the old access pattern no longer applies.

The correct answer requires more than ticket history. It requires:

• The current deployment state.
• The active engineering issue.
• The latest product configuration.
• The employee’s current role and permissions.
• Related incidents and recent changes.
• The approved remediation path.

Without that context, an agent may provide a plausible answer that no longer applies. If the agent can take action, the risk becomes operational.

This is why a unified data layer matters. It gives the agent a connected view of the work around an issue, rather than forcing it to rely on disconnected snapshots.

The problem is not limited to technical accuracy. Access boundaries matter just as much. An agent shouldn’t expose an engineering discussion to an employee who doesn’t have permission to see it. It also shouldn’t use a restricted incident to justify an action for someone outside that incident’s access group.

Why does the current context matter?

Suppose an IT agent receives a device request. It finds a policy that says the employee qualifies for a standard laptop. The policy was correct when it was published.

Since then, procurement has changed the approved device list. The employee has moved to a different region. The employee’s manager has also introduced a new approval requirement.

A static knowledge base may still return the old policy. A current agent needs to check the live policy, location, manager relationship, and approval state before acting.

The same pattern appears in incident management and change management. A runbook can be technically accurate but operationally wrong if the environment has changed. The issue is not that AI can’t understand the instructions. It’s that the instructions may no longer describe the current system. An agent acting on yesterday’s export isn’t automating IT. It’s automating the outage.

DevRev’s Enterprise-Bench provides a useful illustration of this context problem.

The benchmark compares two approaches to the same underlying frontier model: a structured-memory agent (Computer Memory, by DevRev) against a standard fetch-based approach working in isolation. The gap between them came entirely from connected data and knowledge graph architecture.

• Computer, by DevRev, achieved 94.3% accuracy compared with 63.6% for Claude Code on identical L1–L2 enterprise tasks.
• The results used 4.4 times fewer tokens per correct response.
• The result doesn’t prove that one model is always better than another. It supports a narrower point: enterprise performance can depend heavily on how the system retrieves and organizes context.

Many difficult or recurring tickets are symptoms of work outside the service desk. They may reflect a product defect, a deployment issue, a configuration change, or a process failure. That doesn’t mean every IT ticket is a product bug. It means the service desk can’t always resolve the underlying problem by looking only at the service desk.

Key takeaway: The agent’s real operating environment includes current systems, permissions, relationships, and changes. Ticket history alone isn’t enough for safe autonomy.

Is maturity about queue coverage or safe decisions?

AI ITSM maturity should be measured by safe decisions, not queue coverage:

• Can the agent identify the current state?
• Can it distinguish an answer from an action?
• Can it enforce the requester’s permissions?
• Can it request approval when needed?
• Can it reverse or correct an action?
• Can it explain which data informed the decision?
• Can it escalate with complete context?

This changes the maturity test from “how much of the queue can a bot touch?” to “can the agent make a safe decision from live, permission-aware data?”

Is agentic AI in ITSM safe?

Agentic AI in ITSM can be safe when it uses current data, enforces permissions, limits actions, and keeps humans in control of high-risk decisions.

Safety isn’t a single feature. It’s a behavior that must appear throughout the workflow.

An agent should understand relationships between people, systems, incidents, products, and engineering work. It should respect the permissions attached to those relationships. It should also make sensitive actions reversible wherever possible.

A practical model includes four controls:

1. Current context: The agent uses live information instead of relying on outdated snapshots.
2. Permission awareness: The agent respects the requester’s and operator’s access boundaries.
3. Governed actions: The agent can only invoke approved tools and workflows.
4. Traceability: The organization can review what the agent saw, decided, and changed.

This is where enterprise AI memory becomes important. Enterprise AI memory isn’t just a larger document store. It gives an agent a way to retain useful context across systems while respecting access rules.

The goal isn’t to make an agent act independently at any cost. The goal is to make the right level of autonomy possible without asking employees to become the integration layer between IT, product, and engineering.

Key takeaway: Safe agentic AI ITSM combines live context, permission enforcement, governed tools, and traceable actions. Autonomy should expand only where those controls are strong.

How does AI ITSM take safe action across systems?

AI ITSM takes safe action when the agent can connect current context to approved skills and governed write-back.

Computer, by DevRev, approaches this through a connected operating model.

• Computer Memory brings together relevant IT, product, engineering, and knowledge context.
• AirSync keeps information current across connected systems and reads and writes back to your systems through controlled workflows.

The result is more than a chatbot that searches a knowledge base. It’s an agent that can reason about the request and complete approved work.

A typical flow looks like this:

1. An employee describes a problem in natural language.
2. Computer identifies the request, affected service, and user context.
3. Computer Memory retrieves current incidents, product state, engineering work, policies, and permissions.
4. Computer invokes the approved Agent Studio Skill or workflow.
5. Safe Actions confirm whether the action needs approval.
6. The workflow updates the relevant systems.
7. The employee receives a clear status update.
8. The action and decision path remain available for review

Agent Studio helps teams define repeatable IT workflows with clear steps, permissions, and approval rules. They can support access provisioning, device requests, incident updates, onboarding and offboarding, account unlocks, standard changes, approval flows, and knowledge recommendations.

Safe Actions add controls for sensitive changes. A permission update, account change, or production-related action may need confirmation, approval, logging, and reversal. The specific control depends on the organization’s policy and the risk of the operation.

Before automating a workflow, IT leaders should identify:

• Which requests are high volume and low risk
• Which systems hold the authoritative data
• Which actions need approval
• Where permissions change frequently
• Which actions can be reversed
• When an agent must escalate to a person
• What evidence is needed for audit and compliance

That process avoids a common mistake: automating the visible ticket flow while leaving the actual resolution dependent on manual work in another system.

Key takeaway: Safe Actions comes from connecting live context to defined Skills and controlled workflows. The agent should act within clear boundaries, not improvise across the enterprise.

Can IT teams stop being the integration layer?

In many organizations, employees wait while teams move context between tools. The service desk becomes a human switchboard.

AI ITSM can improve this pattern, but only if it can see the work beyond the ticket. The agent needs to understand the relationship between the employee, incident, product area, deployment, engineering issue, policy, and action.

That doesn’t mean every team should expose everything to every agent. Permission boundaries remain essential. It means authorized agents should be able to retrieve the context they’re allowed to use and route work without forcing humans to copy and paste it between systems.

Computer focuses on an end-to-end resolution model that resolves employee requests, support access workflows, and keeps actions logged and auditable.

The outcome is not fewer tickets by itself. The better outcome is less coordination work around each ticket.

Employees get a clearer answer. IT teams spend less time chasing context. Leaders gain a more realistic view of where service work originates.

The strongest service desk doesn’t aim to remove humans from every workflow. It removes unnecessary coordination while keeping judgment where the risk requires it. An autonomous IT agent is only as safe as the source it is grounded in.

See how Computer resolves IT issues across systems safely by booking a demo with the team.