Autonomous endpoint management: what “autonomous” should mean on a laptop, and what it must not

Picture the conversation that happens in most enterprises the first time somebody proposes putting an AI agent on every employee's laptop. The service desk lead is interested, because the device queue is the one that never clears. The security architect is not, because the proposal amounts to software that can run commands on twenty thousand machines on the strength of a language model's judgment. Both of them are right, and the meeting usually ends with the word "autonomous" doing a great deal of work that nobody in the room has defined.

I have sat in that meeting many times this year, on the vendor side, and the word is the problem. "Autonomous endpoint management" has become the label for a whole category (self-healing devices, automated remediation, agents that fix things before anyone complains), and the label hides two very different capabilities that deserve very different levels of trust. One is the ability to work out what is wrong with a machine without a human steering every step. The other is the ability to change that machine without a human approving every change.

The first is where almost all of the value sits, and the second is where almost all of the risk sits. A buyer who treats them as a single feature will either refuse both or accept both, when the sensible position is to want the first badly and to ration the second carefully.

So this piece defines the term properly: what autonomy on an endpoint should mean, what it must not mean, and how we built Rapport, Rezolve.ai's agentic endpoint product, so the two kinds of autonomy can be switched on separately.

Why investigation is the autonomy worth paying for

Start with where the hours go. Fixify's 2026 benchmark, drawn from 50,000 tickets across more than thirty organizations, puts the median time to close a hardware ticket at just over 80 hours, the slowest category a desk handles apart from onboarding. HappySignals' 2023 benchmark, built on 1.86 million end-user responses, found that 41 percent of incidents are reassigned at least once and that each reassignment costs the employee roughly another hour and forty-six minutes. Device tickets are slow and expensive not because the faults are hard but because the ticket is passed along: first line to desktop support, desktop support to a remote session, remote session to a swap. At no point in that chain does anybody sit down and work out what is actually wrong with the machine.

That is the job an autonomous agent should be doing, and it needs no permission to change anything. Working out why a laptop stutters means reading the event log, measuring disk latency, checking memory pressure, looking at crash history and GPU driver resets and then, the part scripts cannot do, deciding what to look at next based on what came back. In one investigation on a machine in our own pilot, Rapport ruled out memory, crashes, GPU resets, hardware errors and disk latency one check at a time, all clean. Then it ran a filesystem integrity query that nobody runs on a stutter complaint and found the NTFS volume flagged dirty, with Windows asking for a full disk check at every boot for a month. Every one of those checks was read-only. The investigation was fully autonomous in the sense that matters (the agent chose the path), and it altered nothing.

I would go further. An agent that investigates well but cannot act is still worth deploying, whereas an agent that acts freely but investigates poorly is a liability you will switch off in month three. Investigation autonomy is what shortens the 80 hours; action autonomy only shortens the last twenty minutes. It is the same distinction that separates an AI copilot from an AI agent: what matters is what the system decides on its own, and under what limits.

What must stay with a person

The second kind of autonomy, changing the machine, is where the security architect's objection is legitimate, and a vendor who waves it away does not deserve the deal. The question to put to any product in this category is simple: when the model decides a command should run, what stands between that decision and the command running?

Our answer in Rapport is that the model has no permissions at all. The reasoning happens in the cloud, through a gateway that passes conversation context and bounded tool results and keeps provider keys server-side. What sits on the device is a native agent, and that agent classifies every command locally before anything executes.

Read-only checks run where your policy allows them to. Anything that changes the machine or needs elevation (a registry edit, a service restart, a driver reinstall) waits for approval from a person. Destructive and disallowed commands are refused outright, every time, regardless of how the model phrased the request. A model asking is not permission; the agent on the device decides, against rules you set.

Approval itself is a workflow rather than a prompt. Per-incident approval is the default, and nobody can approve their own request. When a rule queues a script to run automatically, that script needs a second admin who wrote neither the detection, the script nor the rule. It is the same separation of duties your change management process already applies to production servers, applied to laptops.

How do you audit a machine that reasons?

Every session is recorded as it happens (each turn of the conversation, each tool result, each approval step, in order), so your technician, or your auditor six months later, can read exactly what the agent checked, what came back and why it concluded what it did. That matters more than any accuracy figure a vendor could quote you, and the example I keep returning to is from that same stutter investigation. Having found the dirty volume, Rapport added, without being asked: "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 noted that it could not run the repair itself, because the fix needed a reboot and somebody at the machine, and wrote the instruction for a human instead.

An autonomous agent that marks the difference between what it proved and what it inferred is one your senior engineers will actually read. One that states every finding with the same confidence gets believed twice, caught out once and ignored thereafter. For the broader framework, see what agent governance looks like when it is built in.

What the network team will ask

The footprint is deliberately small (see deployment and prerequisites). The agent talks outbound on HTTPS port 443 only, with no inbound port, no firewall exception and nothing for you to host. Only an authenticated user in that device's tenant can start a session, on a connection verified by multi-factor authentication, and the precise list of what leaves the device is published rather than described in a sales call.

And there is an off switch. Execution can be disabled entirely for a tenant, a cohort or a device, and the investigation still runs. A client whose security team will not allow command execution at all still gets the diagnosis, which, as argued above, is the part they are buying.

In what order should you switch it on?

Our recommendation, and the way every deployment we have run so far has gone, is technicians first.

Rapport sits in the ticket, and the technician describes the problem in plain language, with no remote session booked and no employee interrupted, then reads back the reasoning. For the first weeks, execution is either off or held behind approval on every action, and the technicians learn what the agent is good at and where it overreaches. Only after that does the second phase make sense: employees asking their own device directly, through whatever conversational front door you already run, and resolving the ordinary majority of problems without a ticket at all.

That sequence is also what makes the self-service claim credible to the people who have to approve it. Nobody is being asked to trust an AI with their fleet on day one; they are being asked to let it look, show its working and earn the right to act.

Where this leaves the meeting

Go back to the room with the service desk lead and the security architect, and give them the two definitions. Autonomy of investigation means the agent decides what to check and finds faults nobody wrote a script for. It is the capability that attacks the 80-hour median, and it can be granted with no change to the machine. Autonomy of action means the agent changes the machine. That is a separate privilege, granted command by command against your policy, with a second pair of eyes on anything a rule runs on its own and a full record of everything that happened.

Buy the first on day one, and extend the second only as fast as the session record earns it. That is what autonomous endpoint management ought to mean, and it is the standard we built Rapport to meet.