Most CIOs I speak with will tell you they've already deployed AI in their service desk.

Press a little and the picture gets murkier. What most of them deployed was a bot. Sometimes a good one. It answers password questions, surfaces a knowledge article, routes keywords, and produces a deflection number that looks respectable on a QBR slide. It got called AI because that's what the category was called that year. And then it stopped because bots were designed to intercept the cheapest ticket in the queue, and the cheapest ticket in your queue was never the problem.

The problem is everything that happens after the ticket is created. The CAB meeting where nine people vote on a change nobody has a dependency map for. The Problem record that never gets opened because the Problem Manager is doing incident work. The duplicate ticket fog that swallows the first twenty minutes of every P1 bridge. The outage update that goes out fluent, reassuring, and wrong.

None of that is a deflection problem. All of it is an execution problem, and execution is where AI has been conspicuously absent.

Today Rezolve.ai is shipping 50 production-ready agents into the Agent Marketplace, spanning 12 categories across the full ITSM and IT asset lifecycle. They are goal-driven, not script-driven. They come pre-equipped with the tools they need, with approval gates built in. And every one of them imports into your tenant with a single click.

This post is not a feature list. It's an argument about what changes when AI finally has hands, memory, and most importantly, sight across more than one system at a time.

The catalog at a glance

Fifty is a lot to hold in your head. Here is the shape of it before we go deep.

The Rezolve.ai Agent Marketplace: 50 agents across 12 categories.

Read the middle column and you'll notice something. These are not automation categories. They are ITIL practice areas. The catalog was organized around how IT actually works, not around what happened to be easy to automate.

The architectural bet: one agent, many systems

Here is what your incident triage has never been able to do, no matter how good your bot was.

A user reports “Outlook is slow.” Your bot reads the text, classifies the intent, maybe checks a KB. What it cannot do at intake is resolve that specific human to that specific laptop, walk the CMDB from that laptop to the services depending on it, and set a priority based on what actually breaks if this goes unaddressed.

That requires an agent holding ticketing context and asset context in the same reasoning loop. Not a ticketing bot firing a webhook at an asset system. Not an asset tool with a chat wrapper. One agent, reading both, reasoning across both, writing to both and citing which system each fact came from.

Take BlastRadius Incident Triage. It reads the reporter's raw description, distills a concise summary and a sentiment read, resolves the reporter's hardware to a configuration item, then walks the CMDB dependency graph to measure the real downstream blast radius before computing a priority. Read that last clause again. Priority grounded in actual service impact rather than the reporter's mood.

Every service desk leader knows the tax they pay here. Priority in most organizations is a negotiation between how loudly the user typed and how conflict-averse the L1 is feeling. The result is a queue sorted by emotional volume. BlastRadius sorts it by consequence and that single shift, from stated urgency to computed impact, cascades through the entire catalog.

Hold onto this idea. We'll come back to it, because two systems are where it starts, not where it ends.

Incident and Major Incident: killing the fog

A major incident is not one hard problem. It is five easy problems happening simultaneously to people who have no time.

When a P1 is declared, or when an incident storm converges one shared CI, Major Incident Commander stands up the structure. It opens a single authoritative MI hub ticket, finds the scattered symptom tickets reporting the same outage, and collapses them under the hub so the war room works from one source of truth “instead of duplicate-ticket fog.” It quantifies the blast radius from the CMDB dependency graph, tracks the P1 SLA clock from live SLA data, and pages the responders and stakeholders who own the impacted and downstream services. Anyone who has run a bridge call knows the first twenty minutes are spent doing exactly this, badly, in a Teams thread.

Then the second failure mode: communications. WarRoom Comms Conductor owns the stakeholder cadence for the hub - reading the SLA breach clock, translating responders' work notes into a clear public-facing update, publishing on the committed interval, and keeping the distribution list aligned with whoever the impact currently touches. Critically, it “never invents progress, ETAs, or root cause; anything still unknown is labelled as unknown rather than smoothed over.”

That constraint is the difference between an agent you can put in front of your executive team and one you can't. The failure mode of a generative model writing an outage update is that it produces something fluent, reassuring, and wrong. This one cites the source note and timestamp behind every sentence.

Third: the question every bridge call opens with. Did a change cause this? ChangeImpact Incident Correlator establishes the affected CI, walks the relationship graph to every CI the incident touches, searches for recent changes that modified those CIs inside the relevant window, and risk-scores each suspect on temporal proximity, degree of CI overlap, and change risk class. When the evidence is strong, it links the incident to the probable-cause change and records the correlation reasoning as a comment for the CAB and the bridge - stating a confidence level rather than asserting causation. Your managers answer that question today by memory and Slack archaeology.

See how Rezolve.ai automates critical outages with Major Incident Management

And underneath the drama, the everyday lifecycle. The IT Ticket Triage & Resolution Agent is the workhorse for ticket searches, updates, status transitions, assignments, user notifications, commenting, and ticket linking. It seeks explicit confirmation from a human before making any change. Boring by design. Boring is what lets you leave it running.

Explore Rezolve.ai Modern Service Desk

Change and CAB: where velocity goes to die

Change management is where ITIL discipline and engineering velocity collide most expensively. The CAB exists because changes cause outages. The CAB is hated because it reviews thirty low-risk changes to catch one dangerous one, and it reviews all thirty without a dependency map.

CAB Co-Pilot - Approval Orchestrator fixes the input. For each change sitting in Awaiting Approval, it produces a tight, risk-ranked decision brief, resolves and pages the approver group that actually holds authority, and chases approvals that have gone stale past their wait window, so the CAB arrives at the meeting with every decision teed up and a clean audit trail behind it. The risk rank, blast radius, and required approvers are read from the change record, the CMDB affected-CI links, and any prior-incident history, and it cites the ticket fields and incidents it relied on.

Note what it refuses to do. It does not approve or reject a change on a human's behalf. It does not edit implementation plans, schedules, or change windows. And when a change lacks the data to assess risk or identify its approver group, it pages no one and flags the change for human CAB triage with the specific missing fields named. Self-declared impact stops being the input; audited evidence becomes the input. There is your Change Failure Rate, addressed at the source.

And after the window closes, Change Impact Incident Correlator, the same agent from the bridge call, closes the loop from the other side, sweeping post-change incidents for the changes that plausibly caused them. The CAB finally sees both halves of its own record.

Modernize approvals and reduce change risk with Change Management

Problem management: the discipline you fund last

Problem management is the first thing cut when the queue gets hot, and the reason the queue is hot.

Incident Constellation - Recurring-Incident Detector sweeps the recent incident population, clusters near-duplicate tickets on their shared signature - symptom text, affected service, error pattern, and category, and consolidates any cluster that crosses a defined recurrence threshold into one parent Problem record, with every contributing incident linked as evidence. Emerging systemic issues get caught and owned before they escalate into a major outage.

Its restraint is an interesting part. It will not merge tickets that share only a category but not a real signature. It will not create a second Problem when an open parent already covers the cluster. It will not assert an RCA conclusion it cannot support from the linked evidence. And when a signature is too ambiguous to cluster confidently, it states the gap plainly and routes to a human rather than force-filing. That's not a chatbot. That's an analyst with discipline.

The CMDB question you have been avoiding

Ask a CIO about their CMDB and watch the body language. Everyone knows it's stale. Everyone knows impact analysis and change risk depends on it. Nobody has the appetite for another eighteen-month remediation project.

The CMDB agents attack this as a continuous hygiene problem rather than a project.

Incident-to-CMDB Auto-Linker runs at the moment an incident is created or updated, resolving the real configuration item behind the ticket, the specific laptop, server, application, or service the user is actually complaining about, binding the incident to that CI, and enriching the ticket with the CI's recent failure history and downstream blast radius so the triaging human or agent sees prior incidents and dependency impact the instant the ticket lands. It attaches a CI only when ticket data and CMDB lookups agree on the match, cites that evidence in an audit comment on every link it creates, and treats ambiguity as a reason to escalate rather than guess. Every ticket becomes a CMDB maintenance event. The graph heals as a byproduct of work you were already doing.

Service Map Cartographer offers an accurate, machine-built service topology instead of months of manual mapping workshops. Starting from a single business-service CI, it walks the relationships already recorded in the CMDB to confirm the known graph, then infers missing edges from real operational signal like assets shared by the same users, components that co-occur on the same incidents - and persists only the strongest inferences back as typed, proposed CI relationships. It never invents a dependency; it constrains every new link to a relationship type the CMDB defines, and it records the basis for each link in an audit comment so a human can trace and reverse it.

Your CMDB stops being a compliance artifact and starts being an operational instrument. That's the unlock.

Learn Why Teams Choose Rezolve.ai Over ServiceNow CMDB

The front door and the workbench

Two more agents show the pattern from opposite ends of the desk.

On the employee side, Deflect - KB-First Self-Service Resolver resolves the issue inside the conversation, in Microsoft Teams, the portal, or Slack. It grounds itself in the matching knowledge-base article and a concrete diagnostic guide, walks the employee through the cited fix, and confirms whether it worked - deflecting only on the employee's explicit confirmation, never declaring an issue solved on its own judgment. A ticket is the last resort, and when one is finally needed, it arrives pre-filled with the diagnosis, the steps already tried, the linked article, and the conversation trail, so L1 starts with context instead of zero. There is your real earned deflection number, and not a gamed one.

On the practitioner side, Operations Assistant is the ITSM copilot for incident, problem, change, and configuration work. It operates across the connected ticketing platform and the asset/CMDB system in one reasoning loop, giving service-desk agents, problem managers, and change managers evidence-backed analysis and safe, approval-gated actions. When routing or escalation is in scope, it finds the best-suited specialist by searching agents' documented skills in the directory and proposes the assignment for the operator to approve. Routing by documented skill, instead of by whoever answered last time.

See how Rezolve.ai's production-ready AI agents automate incident management, change management, CMDB, asset management, and service desk operations across enterprise systems—all with evidence-backed decisions and built-in governance.

🎥 Watch the Rezolve.ai AI Agent Marketplace in Action

Two systems today. Every system tomorrow

Now come back to the architectural bet, because this is the part that should shape how you think about the next three years.

Every capability in this catalog that feels like magic is really the same trick: an agent that can hold two systems in one reasoning loop and act on what it finds when they're read together.

Priority from blast radius is ticketing joined to CMDB. A probable-cause change is CI overlap joined to a change window. A proposed dependency edge is shared users joined to co-occurring incidents. A Problem record is incident signatures joined to a recurrence threshold. In every case, neither system alone contains the answer. Neither system alone even contains the question. The insight lives in the join, and the join has historically lived in a human's head, or in a quarterly spreadsheet exercise nobody has time for.

Ticketing and asset management are simply where we started, because they are the two systems whose separation costs IT the most. But nothing about the architecture is specific to two.

Extend the same reasoning loop to your identity provider, and offboarding becomes a genuinely closed loop - with seat reclaimed, device recovered, access revoked, all in one audited transaction with one evidence trail. Extend it to endpoint management, and device replacement stops waiting for tickets and starts reading telemetry. Extend it to observability, and a latency spike gets correlated to the change that caused it and the CI that propagated it, before a single user files anything. Extend it to HR and finance systems, and provisioning sources entitlement from the requisition rather than from a manager's guess.

This is why we built the agent tooling layer on the Model Context Protocol rather than on a proprietary connector format. MCP is becoming the way enterprise systems expose capability to agents. An agent equipped through an open protocol can be handed over a new system's tools without being rewritten. The Ticketing and Asset Management tool surface these 50 agents draw on is the first instance of that pattern, not the boundary of it.

The strategic point for a CIO is this. The value of an agent platform does not scale with the number of agents. It scales with the number of systems any one agent can reason across at once. Because that's where the joins are, and the joins are where the answers are.

Most of your stack is a set of well-run silos with good APIs and no shared reasoning. Fixing that is a bigger prize than deflection ever was.

The design decision that should matter most to you

Read enough of these agent definitions and one phrase recurs like a metronome: evidence-driven and conservative on writes.

It appears in incident triage, in change approval, in recurring-incident detection, in CMDB linking, in service mapping, in major-incident comms. The specific commitments vary, but the shape is identical: read from tools, never from memory. Cite the ticket ID, the work note, the timestamp, and the CI relationship. State uncertainty rather than guessing. Act only past a real threshold. Never invent a dependency edge, a root cause, or a relationship type the tools did not return.

This is the crux of enterprise AI adoption in ITSM, and most vendors have it backwards. The bottleneck was never model capability. It was whether a CIO would let a probabilistic system write production records - bind CIs, consolidate incidents, page approvers, publish stakeholder updates, without a human in the loop.

The answer is not “trust the model.” The answer is architectural: bound the agent's authority, force every write to be justified by tool-returned evidence, cite that evidence in an audit comment, put approval gates on consequential actions, and design each agent so its conservative failure mode is doing nothing and telling a human why. CAB Co-Pilot, faced with a change it cannot assess, pages no one and flags it for human triage with the specific missing fields named. WarRoom Comms Conductor labels anything still unknown as unknown rather than smoothing it over. Service Map Cartographer records the basis for every proposed link in an audit comment a human can trace and reverse.

You cannot bolt that on afterward. It has to be how the agents were conceived. And it is the precondition for the cross-system future above because an agent reasoning across five systems without an evidence discipline is not an operating system but a liability.

Why this could only come from inside the domain

A general-purpose agent platform can be pointed at ITSM. It will produce plausible agents. It will not produce Incident Constellation's refusal to merge tickets that share a category but not a real signature, because you only write that rule after watching a careless consolidation bury a genuine outage. It will not produce WarRoom Comms Conductor's insistence that anything unknown is labelled unknown, because you only write that constraint after watching a fluent, reassuring, wrong update go out to an executive bridge. It will not produce Incident-to-CMDB Auto-Linker's demand that ticket data and CMDB lookups agree before a CI is attached, because you only require two matching signals after you have cleaned up a graph poisoned by confident mis-links.

Fifty agents. Twelve categories mapped to real ITIL practice areas, not to a generic automation taxonomy. Approval gates where consequences are irreversible. Citations where claims are made.

And when the catalog doesn't cover your situation, Create with AI lets you describe the outcome you want and ships an equipped agent in minutes. New agents are being added continuously across automation, security, FinOps, and beyond.

Optimize software spend with Rezolve.ai FinOps

What Monday looks like

You don't need a transformation program. That's the point of one-click import.

Start where the evidence is cheapest to verify. Import Incident-to-CMDB Auto-Linker and watch your asset graph heal from ticket flow. Import Blast Radius Incident Triage and compare its computed priorities against your L1s' for two weeks. Import CAB Co-Pilot and walk into Thursday's CAB with a risk-ranked decision brief on every change in the queue. Import Incident Constellation and find out, possibly for the first time, how many of last quarter's incidents were the same problem wearing different ticket numbers.

Then decide how far you want to go.

The service desk was never the destination. It was the front door to an estate running on tribal knowledge, stale CMDBs, unsorted queues, and dependency maps that live in people's heads. Fifty agents that can read across your systems, reason over the joins, cite their evidence, and stop when they're unsure. That is a different proposition than a bot that answers password questions.

That is IT service delivery with an operating system.

Explore the full 50-agent catalog in the Rezolve.ai Agent Marketplace. Or, describe the outcome you need and build your own in minutes with Create with AI.