There’s a lot of talk this year about AI agents that will look after your endpoints for you. Some of it is real. Plenty of it is a demo where a chatbot runs a command on one laptop and the room claps.
The interesting question isn’t whether software can work out a fix. More and more, it can. The question is what happens between “this fix looks right” and “this fix has run on 40,000 laptops”, and who’s accountable if it goes wrong.
IT teams already have an answer to that. They just don’t apply it to automation.
You already know how to do this
Any well-run IT team has change management. Before a change goes near production, someone writes down what it does, someone else reviews it, it goes to a small group first, there’s a plan to back it out, and there’s a record afterwards.
Then the same organisation lets a well-meaning engineer push a script to every device from their desk, because it’s only clearing a cache. Most of the time that’s fine. The one time it isn’t, you find out from the service desk phones.
An automation that runs by itself whenever a condition is met is a change. Arguably a bigger one than most, because it keeps running long after everyone has stopped watching it.
What it looks like in practice
It doesn’t need to be heavy. For every automation:
- One owner, one version. Someone can tell you what it does, and you know exactly which version is running where.
- A second pair of eyes. Someone other than the author approves it before it reaches real devices. That matters even more when the first draft came from a model.
- Rings. IT’s own machines first, then a pilot group of willing people, then everyone else. A few days at each step usually catches the surprises.
- A way back. Know how you’d undo it before you need to.
- A record of every run. What ran, on which device, when, and what happened. When someone asks whether anything changed on their laptop on Tuesday, you should be able to answer in a minute.
- Permissions that match the risk. The person who can build an automation isn’t automatically the person who can send it to the whole fleet.
Make the proven ones standard changes
The risk with all this is that it turns into a queue. A cache clear waiting a fortnight for the change board is how automation programmes quietly die.
ITIL already has a fix for that: standard changes. Low-risk, well understood, approved in advance. An automation that has gone through its rings with a clean record is exactly that. Approve the pattern once and let it run. Save the review effort for new automations, and for anything that touches many devices at once or can’t be easily undone.
And AI?
We think AI belongs upstream of all this, not instead of it. It’s good at noticing that something has changed across a group of devices, at ranking likely causes, and at drafting a first version of a fix. It shouldn’t get to skip review because it wrote the draft quickly.
That’s the line we hold in Nanoheal: Haya finds the problem and shows the fix. You approve what runs. In the automation builder you can describe an issue in plain language and get a suggested workflow to start from, but a person reviews and approves it before it runs, publishing is staged and versioned, and every run goes in the audit log. The trust page goes into how we handle it.