Scripts only fix faults somebody already thought of

Most service desks have spent the last five years automating, and the automation has worked. There is a runbook for the password reset, a script for the printer queue, a scheduled job that clears the Microsoft Teams cache, a self-service flow that re-enrolls a device in Intune, and lately an AI assistant that will write a new PowerShell script from a sentence. Ticket volume at first line is down, first-contact resolution is up, and the desk manager can show a chart that goes the right way.

And yet the oldest tickets in the queue look exactly the way they looked five years ago. "It's slow, not always, just sometimes." "It crashes for me and nobody else." "I've restarted four times." They have been reopened, reassigned, remote-sessioned and, in a good many cases, closed as "unable to replicate" so they can be opened again by the same person a month later. Fixify's 2026 benchmark puts the median time to close a hardware ticket at about 80 hours, the slowest category a desk handles apart from onboarding, and that median has not moved the way the first-line numbers have.

The reason is structural rather than a matter of effort, and it is worth spending this article on, because once you see the structure, you also see what an AI agent for IT support actually has to do differently, and most of the ones on the market do not do it.

Why does automation plateau on device tickets?

A script is an answer to a question somebody has already asked. Before the script existed, an engineer met the fault, worked out the cause, wrote down the fix, and turned the fix into something that could run without them. The script library on your desk is therefore a catalog of anticipated faults, a very good one built from years of real tickets, and everything in the catalog gets resolved quickly and cheaply. That is why your first-line numbers improved.

The difficulty is what the catalog does to the residue. Every ticket that matched a script has been removed from the queue, so what remains is, by definition, the population of tickets that did not match anything. Those tickets did not survive automation by chance; they survived it because nobody had anticipated them. Writing more scripts moves the boundary a little, but the residue is always the faults beyond the boundary, and those are the ones that eat your senior engineers' week. An AI assistant that writes scripts faster does not change this, because it still only answers a question somebody thought to ask. That is why L0 and L1 elimination is the floor rather than the goal.

Monitoring has the same shape from the other side. An experience monitoring product (the category the industry calls DEX) collects telemetry from every device, scores it and alerts you when a machine is unhealthy, which is useful because it tells you where to look. What it cannot do is tell you what is wrong with this laptop this morning, because a telemetry product answers "is something wrong" and was never built to answer "what, on this machine, right now." The two tools together leave a gap in the middle, and the gap is where the 80 hours live.

What is the difference between a script and an investigation?

Watch a good engineer with one of those residue tickets and you will not see them run a checklist. The engineer forms a theory ("a stutter that comes and goes is usually I/O, not CPU"), runs one check that would confirm or kill the theory, reads what came back, and lets the result decide the next check. They keep doing that until either the cause is found or every plausible theory has been eliminated. The sequence is not fixed in advance; the third check depends on the second result. That dependence is the whole difference between a diagnostic script and an investigation, and it is why an investigation can reach a fault that was never cataloged. It is also the practical line between an AI copilot and an AI agent.

We built Rapport at Rezolve.ai to do exactly that on the device, and the phrase that carries the weight is "decides what to look at next." The reasoning runs in the cloud through our gateway, a native agent on the device runs the permitted checks, and a person (your technician, working from the ticket in plain language) directs the whole thing, without booking a remote session and without the employee stopping work. Two cases from our own pilot show what the loop looks like in practice.

Case one: the machine that stutters

The complaint was the classic one: a desktop that locks up for a few seconds, then catches up, not often enough to reproduce on demand. Rapport began where an engineer would begin, with the usual suspects, and ruled them out one at a time. Memory pressure was normal (15 GB free of 34, zero paging). There had been one crash in seven days, and it was unrelated. There were no GPU driver resets and no hardware error events, with all disks reporting healthy and zero read or write errors. Disk latency was sub-millisecond with a queue length of zero.

Every tool we own would have reported those five clean results and closed the ticket, and that is the point at which a script stops, because a script has no next step after its last check returns clean. Rapport's next step was to ask something nobody asks on a stutter complaint: whether the filesystem itself was consistent. The NTFS volume was flagged dirty. Windows had been requesting a full disk check at every boot since the end of September, 45 times in 30 days, and could not repair the volume while running.

The mechanism, for anyone who wants it: NTFS hits inconsistent metadata, the thread doing I/O blocks, and everything waiting on that file handle freezes until it clears. It is sporadic because it depends on which files get touched. A dirty volume had been sitting in plain sight in the event log of a machine somebody had been complaining about for a month, and nobody had looked, because nobody runs a filesystem integrity query on a stutter.

Case two: the Wi-Fi that was slow on one machine only

The second was a home-office PC whose Wi-Fi was painfully slow while a Mac in the same room, on the same router, was fine, the kind of ticket that goes around the router, the ISP and the driver for weeks. Rapport's first move was to measure both machines rather than take the complaint at face value: the Mac was pulling 105 Mbps, the PC 19. Then band and channel: the Mac had joined at 5 GHz on channel 108 (Wi-Fi 6), and the PC was stuck on 2.4 GHz channel 6 (Wi-Fi 4). Then the clever step, a scan from the PC's own card: eleven access points visible, and none at all on channels 52 to 144, the DFS band shared with weather radar, which is exactly where the router's 5 GHz radio was sitting. The gap in the channel list was a fingerprint. The driver was current, so an update would have changed nothing.

The cause was the card, a 2019-era wireless adapter whose built-in region settings block those channels. Rapport switched on the card's country-detection setting, with approval, rescanned to prove the limit was in the hardware rather than the configuration, and recommended a $30 Wi-Fi 6 card instead of "restart your router." The finish is what a good engineer does and a script never would: change one thing, confirm the diagnosis, and give a buying recommendation rather than a workaround.

How do you know whether to believe it?

The fear every buyer has about an AI touching endpoints is not that it will be wrong (people are wrong) but that it will be wrong confidently and get believed. So the second thing Rapport does, after investigating, is show its working: every check it ran, what came back, and why that result points where it does, recorded turn by turn in a session your technician can read before deciding whether to act. That is explainable AI applied to a laptop.

The third thing matters even more. In the stutter case, in the same report and without being asked, Rapport wrote: "I never caught the machine mid-stutter, so this is a strong correlation, not a proven cause. My latency sample was six seconds on an idle system; it rules nothing out." It then flagged that it could not run the repair itself (no admin rights from where it sat, and the fix needed somebody at the machine for a reboot) and wrote the instruction for a human instead. A tool that overstates its confidence gets used twice and then ignored; one that marks the difference between what it proved and what it inferred is one your senior engineers will actually read. We do not claim Rapport is always right. We claim that it tells you how sure it is, which is the claim your engineers can actually work with.

What should an AI agent be allowed to do on a device?

Less than you might expect, and the limits are what make the investigation usable. The native agent on the device classifies every command before it runs. Read-only checks run on their own where your policy allows; anything that changes the machine or needs elevation waits for a named approval; destructive and disallowed commands are refused outright; and nobody, not the model and not the technician who asked, can approve their own request. The agent talks outbound over HTTPS on port 443 only, so there is no inbound port and no firewall exception to argue about. And if your security team would rather it never executed anything at all, execution can be switched off and the investigation still runs, which is where most of the value sits. For the wider principles, see what agent governance looks like when it is built in.

Where to start

Do not start by retiring a single script. Keep the catalog; it is earning its keep on the faults you have already met, across your workflows and automations alike. Instead, pull the twenty oldest open device tickets on your desk (the reopened ones, the "unable to replicate" ones) and ask whether any script you own, or any script you could write today, would have found a dirty NTFS volume or a wireless card blind to half the 5 GHz band. If the answer is no, those tickets are the residue, and the residue is what an investigating agent is for. Put Rapport on those twenty machines, with execution off if you prefer, let your technicians investigate them from the ticket, and read what it writes about its own confidence as carefully as you read what it found.