Your new workforce won't be all human. Join the
conference to learn how to manage it.
request invite
Think about the last few tickets that have landed in your queue: Maybe a laptop blue-screened in the middle of a customer call. A disk filled up and a file wouldn’t save. Their Windows laptop quietly stopped accepting updates and nobody noticed for a month. In every one of those, the first your service desk heard about it was from a person — a person who is already frustrated, describing a symptom in whatever words they had. Then it’s up to you to reconstruct what happened, secondhand, after the damage.
Some people would call that a failed service desk. I disagree – that’s a service desk operating in the only order available to it. Reactive by architecture.
In most of these cases, the machine would have been announcing the problem for days but nobody read it, because reading a whole fleet by hand every morning isn’t a job anyone can sustain — so the signal sat unread until it turned into a ticket. But this gap is the perfect AI opportunity. It’s possible for AI to scan a Windows fleet continuously, rank devices by how close they are to failing and hand an admin a specific, evidence-backed report before the user notices anything.
A Device Ops Engineer, an AI Coworker can wake up every day at a scheduled time and bang this report out before you’re done with your first coffee so you can start your day – not with analysis but action. Learn how to build an AI Coworker.
The comparison writes itself. Philip K. Dick’s 1956 short story “The Minority Report,” and Spielberg’s 2002 film adaptation both imagine a precrime division that arrests people for murders they haven’t committed yet, on the strength of predictions from three precognitives.
But the reason the story endures is the twist in its title. When the three predictions disagree, the dissenting one is a minority report. And the institution’s instinct is to bury it — because a system that visibly disagrees with itself looks unreliable, and a system that looks unreliable loses its authority.Concealing the dissent is what lets precrime convict people it shouldn’t have.
That’s the actual lesson for anyone building predictive tooling, and it’s the opposite of the usual takeaway. The danger isn’t that prediction is imperfect. Everything is imperfect. The danger is a predictive system with a confident interface and a hidden error bar, because people stop checking it and start obeying it.
So the design question isn’t “Can it predict device failure?” It’s “Does it tell you where itmight be wrong?”
When I built this AI Coworker, I made sure to specify that it should watch the Windows fleet for devices that are deteriorating, decide which ones actually matter, and give a human a specific fix with the evidence attached, before the device fails.
The loop isfour read-only calls along with one write call:
Every answer ties to a fresh scan, never a remembered one. Describing fleet state from memory is how you confidently report a problem that was fixed last week.
Severity scores measure loudness, not consequence. A disk at one percent free that’s also logging uncorrected read errors outranks a higher-severity CPU spike, every time. One of them loses the user’s data. The other loses the user sometime. An admin with twenty spare minutes should spend them on the thing that can’t be undone.
Each fault carries ranked possible causes, and each cause carries the exact command that confirms or eliminates it. An admin forced to guess which of three causes applies will eventually guess wrong, burn an afternoon, and never trust the tool again. Give them the command that settles it.
This is where naive tooling actively misleads people, and it’s the closest thing to a real minority report in Windows diagnostics.
Some signals point at the wrong thing by design. When a .NET application throws an unhandledexception, the crash record frequently names KERNELBASE.dll as the faulting module. That’s where the exception surfaced, not where the defect lives. An admin who reads it literally goes off to investigate a core Windows library while the actual broken application sits untouched. Likewise, the “possibly related driver” that a bug check offers is a lead, not a verdict. Treat it as proof and you’ll replace a healthy driver and watch the crash come back.
When a fault is known to carry a misleading indicator, the AI Coworker says so in the same breath as the finding. Warning someone off the trap is worth more than anotherdecimal place of precision.
Every device in the output carries its unmeasured signals, and the AI Coworker reports them rather than quietly dropping them.
This is the minority report, made structural. A device that comes back healthy when almost nothing could be measured on it isn’t healthy — it’s unknown. Presenting an unknown as good news is the fastest way to lose a service desk’s trust for good. The first time someone gets a clean verdict on a machine that dies the next morning, the tool is finished, and rightly so. Stating the blind spots keeps the verdict truthful and, as a bonus, tells the fleet owner exactly where their visibility is broken.
There’s a smaller discipline that belongs beside these: don’t inflate. If the consequence is that updates start failing, say that, not that the device faces catastrophe.Overstated warnings train people to ignore you, and then they ignore the one that mattered.
The AI Coworker has no write path to any device, and it’s designed not to ask for one. No cache clearing, no service restarts, no forced patching, no isolating machines, no BitLocker changes. The only thing it writes is records in the system of record: it opens and updates requests, adds notes, and links the affected asset, because that’s how work reaches a human.
That cuts against where the excitement usually runs, so it’s worth defending. An AI Coworker with write access across a fleet of endpoints is positioned to do quiet, wide damage. One well-meaning automated remediation, applied to a hundred laptops on the strength of a misread signal, is precisely the failure that teaches an organisation to distrust every AI Coworker that comes after. Nearly all the value sits in the diagnosis with a human in the loop to judge the risk of the execution.
Two related rules matter in practice. It doesn’t invent evidence: every claim traces to something a tool call actually returned, and if it wasn’t in a response, it isn’t known. And it treats expected virtual-machine artifacts as what they are rather than as faults, because virtual COM ports and placeholder devices report problem codes on perfectly healthy VMs, and flagging those trains people to skim past the real findings.
Honestly, the part I like best isn’t the diagnosis. It’s what the morning looks like when the Device Ops Engineer is in your AI Workforce. An admin opens their report and finds three devices worth twenty minutes each, with the confirming command already attached — instead of finding out at 2pm, from someone on a customer call, that a disk filled up overnight.
With Atomicwork, IT, HR and other service teams can design, govern and deploy an AI Workforce to run their service operations autonomously. AI Coworkers come with a defined role, an identity, scoped permissions, approved tools, a monthly budget, and a manager and are designed to own a service function end to end rather than executing a step and handing the outcome back
The AI Coworker I built was designed to be a read-only fleet scanner exposed to theCoworker as tools, and Atomicwork is the system of record — so the request, the notes, the linked asset and the evidence chain all sit on one auditable record that a human then acts on.
