Zero Ticket IT and Agentic AI: The End of the Ticket-Centric Model?

The ticket has been the atomic unit of IT service management for as long as most of us have been doing this. We measure it, route it, escalate it, breach it, close it, and reopen it when we close it too soon. So when a concept called "Zero Ticket IT" starts trending, and agentic AI is positioned as the mechanism to deliver it, I pay attention. The recognition of Resolve as a Major Contender in Everest Group's 2026 ITSM Platform PEAK Matrix on 10 June 2026 has given this conversation a focal point, and the community debate around applying agentic AI to major incident response has given it teeth. My intention here is to separate the genuinely significant shift from the marketing froth, because there is a respectable amount of both.

1. What "Zero Ticket IT" Actually Means

Removing the ticket, not removing the work

The phrase is unfortunate, because it implies the absence of something rather than the presence of something better. Zero Ticket IT does not mean issues stop happening. It means the conventional ticket handling workflow, with its queues and human triage and status fields, is no longer the primary vehicle for resolution.

• The ticket becomes an artefact, not an event — Where work is detected and resolved autonomously, the record is generated as evidence after the fact rather than as the trigger for action.
• The operating assumption inverts — Traditional ITSM assumes a human raises an issue and a human resolves it. Zero Ticket IT assumes a system detects an issue and a system resolves it, with humans handling the exceptions.
• Self-service is not the same thing — A well-designed portal still produces a ticket. The distinction here is that the resolution path never required one.

In my opinion the terminology will age badly, but the underlying idea is sound. We have spent twenty years optimising the handling of tickets when the more valuable question was always how to avoid generating them in the first place.

2. From Siloed Automation to Agentic Orchestration

Why this is different from the automation you already have

Most organisations already automate. Password resets, account provisioning, scripted remediations. The difference with agentic AI is the move from deterministic, single-purpose automation to autonomous, outcome-driven agents that can reason across a chain of steps without a pre-defined runbook for every permutation.

• Deterministic automation does what you told it — It executes a known sequence and stops when it hits something unexpected. This is reliable and limited in equal measure.
• Agentic AI pursues an outcome — It is given a goal, has access to tools and context, and decides the sequence itself, adapting when conditions change.
• Orchestration is the layer that matters — Resolve's positioning as an intelligent layer over existing tooling is the pragmatic version of this. You are not ripping out ServiceNow or your monitoring stack. You are placing an agentic layer above them.

My experience has been that the "rip and replace" pitch fails in enterprise environments every single time, so the orchestration-over-existing-tooling model is the one I would back. It respects the investment already made and reduces the political surface area of adoption, which is frequently the harder problem than the technical one.

3. Agentic AI in Major Incident Response

The hardest test, and the most revealing

The community debate has gravitated towards major incidents, and rightly so. If agentic AI can hold up under a P1, it can hold up anywhere. If it cannot, we learn exactly where the boundaries sit.

• Detection and correlation are the obvious wins — Pulling together signals from disparate monitoring tools and forming a coherent picture faster than a human bridge call ever could. This is genuinely valuable and reasonably low risk.
• Autonomous remediation is where nerves fray — Granting an agent the authority to restart services, reroute traffic or roll back deployments during a live incident is a different proposition entirely, and the blast radius of a wrong decision is considerable.
• The communication burden is underrated — A meaningful proportion of major incident effort is keeping stakeholders informed. Agentic drafting of status updates, with human approval, is a sensible early use case that nobody seems excited about because it is not glamorous.

I am always conscious that major incidents are precisely the moment when trust in automation is lowest and scrutiny is highest. In my opinion the right model is human-in-the-loop for any action with material blast radius, and full autonomy reserved for diagnosis, correlation and the dull mechanical work. Anyone selling you autonomous P1 remediation with no human gate is selling you a future incident review.

4. What This Does to ITIL and the Operating Model

Practices do not disappear, they relocate

There is a temptation to declare ITIL obsolete every time something new arrives. This is lazy and usually wrong. ITIL 4 is a set of practices and a value system, not a mandate to handle everything as a ticket.

• Incident management as a practice survives — The capability to restore service still matters. What changes is who, or what, executes it and how the record is created.
• Change enablement becomes more important, not less — If agents are taking autonomous action, the governance around what they are permitted to do is a change concern. Your guardrails are your change policy.
• The RACI needs rewriting — When an agent is Responsible for resolution, who is Accountable? That question does not have a comfortable answer yet, and pretending otherwise is unwise.

My preference is to treat the agentic layer as a new type of actor within existing practices rather than as a replacement for the practices themselves. ITIL 4's guiding principles, particularly "start where you are" and "keep it simple and practical", remain entirely applicable. The framework was never the problem. The dogmatic, ticket-for-everything interpretation of it was.

5. The Metrics Problem Nobody Wants to Discuss

You cannot measure what you have stopped recording

Here is the awkward part. A great deal of ITSM measurement is built on ticket volume, mean time to resolve, first contact resolution and similar. If you remove the ticket, you remove the data those metrics depend on.

• Volume metrics become misleading — A falling ticket count could mean improved service or it could mean your agentic layer is silently resolving things you can no longer see. Without instrumentation you cannot tell the difference.
• XLAs become more relevant than SLAs — Experience-level agreements, focused on outcomes and perceived value rather than ticket timestamps, are far better suited to a world where the ticket is no longer the unit of work.
• You must instrument the agents themselves — If an agent resolves something autonomously, that action needs to be logged, auditable and measurable, or you have traded a visible queue for an invisible one.

In my opinion this is the area most organisations will underinvest in, because it is unglamorous and nobody gets promoted for building good observability. The result will be a wave of "we don't get tickets any more" claims that translate, on inspection, to "we stopped looking".

6. Where to Start

Practical advice over hype

If you want to engage with this seriously rather than performatively, there is a sensible order of operations.

• Map your highest-volume, lowest-risk repetitive work first — This is where agentic resolution earns trust cheaply. Prove the model on the boring stuff before going near a P1.
• Define your guardrails as change policy from day one — Decide explicitly what an agent may do autonomously and what requires a human gate, and treat that boundary as a governed artefact.
• Instrument before you automate — Build the logging and observability that lets you measure agentic actions before you let agents take them, not after.
• Pilot the orchestration layer over what you already own — Resist the urge to replace your platform. The intelligent-layer approach lets you realise value without a multi-year migration programme.
• Rewrite your RACI honestly — Work out who is accountable when an agent acts, before an incident review forces you to.

My experience has been that the organisations who succeed with new capability are the ones who treat it as an evolution of their operating model rather than a revolution against it. Zero Ticket IT, stripped of its slightly breathless branding, is a genuine and overdue shift. The ticket-centric model was always a means to an end, and we forgot that somewhere along the way. Agentic AI is a useful reminder.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Estimated reading time: 8 minutes