AI Agents in Tech Support Act on Their Own and Break the Ticket Model

Since the late 1980s, when the first request-tracking systems and the first version of ITIL appeared, support teams have counted their work in tickets. A request comes in, gets assigned to someone, gets closed, and the time is measured. Almost four decades later, that model is cracking: AI agents already perform actions across several systems at once, unlocking accounts, granting access, and restarting services. If no one picks up a request, the question is what to measure support by. Habr AI examines exactly that. Below are the essentials of its analysis and our own conclusions.

Why the ticket stayed the main unit for so long

The ticket combined three roles: a task queue, an event log, and a basis for reporting. SLAs, staff workload, response time, and resolution time are all tied to the card and to a specific person. The whole structure rests on the assumption that between a request and an action there is an assignee who spends time and attention. Time was treated as the main resource.

With an agent, that assumption no longer holds. It does not wait in a queue, switch between tasks, or go to lunch. Unlocking an account takes seconds, and a single action can touch the user directory, the access system, and monitoring at the same time.

What remains of the request

The first thing to break is speed metrics. Response time drops toward zero, and average resolution time falls sharply. These numbers cannot tell you whether the problem was actually solved or the user simply stopped writing. A good outcome and a silent failure look the same in the report.

The second change concerns the card itself. If an agent acts autonomously, the ticket is often created and closed automatically, or not created at all. It stops being a working tool and becomes a trace: a record of who did what, on what grounds, and with what permissions. The value moves from the queue to the action log.

The third concerns accountability. Granted access creates a real attack surface, and a restarted service can interrupt someone else's work. A "done" comment in the card is too thin a source for such a case.

What to measure support by

The announcement gives no direct list, but the problem it describes points to a set of indicators that make sense to put alongside the classic ones:

• the share of requests the agent closed without human involvement, and the share of repeat requests among them;
• the share of agent actions that a human rolled back or corrected;
• time to resolution from the user's point of view, not by the card's status;
• the number of escalations to humans and their causes;
• the cost of handling one request, including model calls and time spent on review;
• audit completeness: for every action, the initiator, the grounds, the permissions used, and the result are recorded.

Repeat requests are the most honest indicator here. If the user came back with the same problem, the quick closure was worth nothing.

Where to start in practice

Start with permissions. The agent needs the minimum access required, not an administrator account "for convenience." Split actions by risk: a password reset or an unlock differs from granting privileged rights, and the latter needs human confirmation.

Next, revisit your reporting. For automated requests, it is better to replace response-time SLAs with quality indicators: repeats, rollbacks, satisfaction. The ticket does not need to be thrown out. It is worth keeping as a single audit record, even if no human ever took part in it.

Finally, leave exceptions and error analysis to people. The support specialist's job shifts from processing a queue to configuring and checking agents, and it will have to be evaluated differently than by the number of closed requests.