AI Changed the Technician's Job Before It Changed Your RMM — Here's How to Catch Up

Every IT team has lived a version of the story in that recent InfoWorld article. Someone tries AI, asks it to replicate something they already understand, gets back confident garbage, blames the tool, and walks away for a month. Then they come back, change exactly one thing — they stop asking the AI to infer their intent and start describing the outcome they want — and it works. Twenty minutes later they're not frustrated anymore. They're unsettled.

Unsettled is the right word, and not just for app builders. For sysadmins, help desk leads, and MSP technicians, that same role change is already happening — and it's landing hardest on remote management. The technician who built a career on hands-on-keyboard remote sessions is becoming the technician who describes outcomes precisely enough that a script fixes the issue across 200 endpoints before anyone gets paged.

The uncomfortable part? Most monitoring and management stacks weren't built for that workflow. If your RMM lives in a different tab than your monitoring, and your helpdesk lives in a different product entirely, no amount of AI scripting will save you from the real bottleneck: the loop between alert, action, and resolution is broken.

The Face-Plant Every IT Team Recognizes

The author's first attempt failed because they uploaded a working spreadsheet and said "replicate this," assuming the AI could infer intent from a finished artifact. Translate that into IT operations and it looks like this: you type "fix disk space issues" into an AI assistant, paste whatever it produces into your RMM's script runner, push it to a device group, and get back a wall of red. You conclude AI isn't ready for production. You go back to remoting in manually.

The second attempt worked because the author described the outcome: the user journey, the assessment flow, the expected behavior. The IT-ops equivalent looks like this:

"Write a PowerShell script that checks free space on all fixed drives, flags any drive over 85% used, prints Server, Drive, UsedPct, and FreeGB for each failure, and exits 1 so my RMM routes the failure to the helpdesk. Exit 0 when everything is clean."

Same AI. Different job description for the human. That's the role change — and it's why your platform matters more, not less, in the AI era. A script is only as good as the feedback loop that runs it, watches it, and escalates when it fails.

The Problem in Depth: Three Tools, One Broken Loop

Ask an MSP tech what their screen looks like right now and you'll hear some version of this: a monitoring dashboard (maybe PRTG or SolarWinds), a separate RMM or remote access tool (ConnectWise Control, TeamViewer, NinjaOne), a helpdesk (ConnectWise Manage, Autotask, Freshservice), and a browser tab of client documentation. Twelve tabs. Five tools. One client.

Here's what that fragmentation costs, concretely:

1. Alerts fire in one place; action happens in another. The disk alert pages the on-call tech at 2 a.m. The tech remotes in through a separate tool, clears 20 GB of old IIS logs, and goes back to bed. The monitoring tool never learns what happened. Ten days later, the same server pages the same tech for the same reason.

2. Scripts run blind. Most RMM platforms will happily push a PowerShell script to 200 endpoints. What many won't do is feed the result back into the monitoring state. You get an exit code in a CSV export nobody reads, while the monitor keeps alerting on the very condition your script just fixed — or stays quiet about a condition your script's verification step just failed.

3. Manual fixes are invisible. The tech who remoted in and fixed the problem didn't document it, because documenting means switching to the helpdesk, finding or creating a ticket, and writing it up. So the MTTR report says the incident took 38 minutes, when the actual fix took 90 seconds and the rest was tool-switching. And nobody can answer the question "how many times this year did we clean logs on FS01?"

4. AI scripts inherit the same broken loop. Teams experiment with AI-generated remediation, get burned by vague prompts, and give up. The AI wasn't the problem. The absence of a place to run, verify, and escalate the script was.

The business impact adds up fast: a 15–25 minute manual remote session per endpoint for issues a 20-line script would fix in seconds; the same alerts re-firing weekly; SLA reports stitched together by hand from two systems that disagree; and technicians burning out on 2 a.m. pages for problems that should have auto-remediated at 2 p.m. If your helpdesk numbers say one thing and your monitoring says another, you already know what that monthly report to management looks like.

How AlertMonitor Closes the Loop

AlertMonitor was built on a different premise: monitoring and remote management belong in the same platform, and every action — automated or human — should land in the same timeline.

The built-in RMM lets technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions — without leaving the console where the alert fired. Script results feed back into the monitoring data, so an automated remediation and a manual technician action are both visible on the same timeline, attached to the same alert, and linked to the same ticket when one exists.

Here's the workflow difference in practice:

The old way: Disk alert on FS01 → on-call tech gets paged → wakes up → opens the monitoring console → opens a separate remote access tool → remotes in → cleans up manually → writes nothing down → same page again in 10 days.

The AlertMonitor way: Disk usage on FS01 crosses 85% → the alert policy triggers a remediation script on that device group → the script prunes logs and temp files → its output lands in the alert's timeline → exit 0, the alert auto-resolves with the script output attached as evidence. Total time: under five minutes, no human woken up. If the script had exited 1, AlertMonitor would have auto-created a helpdesk ticket with the failure output pre-filled, and the on-call tech would open a remote session from the same alert view — already knowing exactly what was tried and why it failed.

That last part is what experienced IT managers notice first: the time between alert and resolution stops being dominated by tool-switching. Fleet-wide checks that used to eat a full day of clicking become a single script run across a device group. And because monitoring, helpdesk, RMM, and patch management share one data model, your SLA report is a query — not an archaeology project across three CSV exports.

This is also what makes the AI role change safe to adopt. When you describe an outcome to an AI, get a script back, and drop it into AlertMonitor's script library, the platform does what a script library must do: run it against a defined scope, capture the verification output, and escalate on failure. The AI writes. The loop guarantees.

Practical Steps: Outcome-Based Scripting You Can Ship Today

Step 1 — Write down your five most repeated manual fixes. For most teams it's some mix of disk cleanup, service restarts, printer spooler resets, patch gaps, and stale user sessions. These become your first automated remediations.

Step 2 — Write outcome-based prompts, not intent-based ones. Use the pattern from the article: scope, action, verification, output, escalation. "Check disk space" is intent. The example above is an outcome.

Step 3 — Structure scripts the way an RMM expects: exit 0 on success, exit 1 on failure, human-readable output in between — so the platform can route results automatically.

Check disk usage across a group of servers:

$servers = Get-Content 'C:\RMM\servers.txt'
$threshold = 85
$failures = foreach ($server in $servers) {
    Get-CimInstance -ComputerName $server -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
        ForEach-Object {
            $usedPct = [math]::Round((($_.Size - $_.FreeSpace) / $_.Size) * 100, 1)
            if ($usedPct -gt $threshold) {
                [PSCustomObject]@{
                    Server  = $server
                    Drive   = $_.DeviceID
                    UsedPct = $usedPct
                    FreeGB  = [math]::Round($_.FreeSpace / 1GB, 1)
                }
            }
        }
}
if ($failures) {
    $failures | Format-Table -AutoSize
    exit 1
}
Write-Output 'OK: All fixed drives are below the usage threshold.'
exit 0

A self-remediating service check — attempt the fix, verify it held, escalate on failure:

$service = 'Spooler'
$status = Get-Service -Name $service -ErrorAction SilentlyContinue
if ($null -eq $status) {
    Write-Output "SKIP: $service is not installed on this endpoint."
    exit 0
}
if ($status.Status -ne 'Running') {
    Start-Service -Name $service -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 5
    if ((Get-Service -Name $service).Status -eq 'Running') {
        Write-Output "REMEDIATED: $service was stopped and is now running."
        exit 0
    }
    Write-Output "FAILED: $service did not start. Escalating to helpdesk."
    exit 1
}
Write-Output "OK: $service is running."
exit 0

A quick patch compliance gate — the kind of check you run across every Windows endpoint at a client site:

$lastPatch = Get-HotFix |
    Where-Object { $_.InstalledOn } |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 1
if (-not $lastPatch) {
    Write-Output 'UNKNOWN: No hotfix history found on this endpoint.'
    exit 1
}
$daysSince = (New-TimeSpan -Start $lastPatch.InstalledOn -End (Get-Date)).Days
if ($daysSince -gt 45) {
    Write-Output "NON-COMPLIANT: Last hotfix $($lastPatch.HotFixID) installed $daysSince days ago."
    exit 1
}
Write-Output "COMPLIANT: Last hotfix $($lastPatch.HotFixID) installed $daysSince days ago."
exit 0

And the same outcome-based pattern for your Linux endpoints:

#!/bin/bash
SERVICE="nginx"
if ! systemctl is-active --quiet "$SERVICE"; then
    systemctl restart "$SERVICE"
    sleep 5
    if systemctl is-active --quiet "$SERVICE"; then
        echo "REMEDIATED: $SERVICE was stopped and is now active."
        exit 0
    fi
    echo "FAILED: $SERVICE restart did not hold. Escalating."
    exit 1
fi
echo "OK: $SERVICE is active."
exit 0

Step 4 — Wire exit codes to routing. In AlertMonitor, attach the script to an alert policy on the relevant device group: a threshold breach triggers the script, exit 0 logs the output to the timeline and auto-resolves the alert, exit 1 opens a helpdesk ticket with the failure output attached.

Step 5 — Review monthly. Look at which scripts resolved issues silently, which escalated, and which failures were really missing scope in your outcome description. That monthly review is the new technician skill the article describes — and it's a skill, not a threat.

The Role Change Is the Point

The InfoWorld author's conclusion wasn't "AI is magic." It was "my role changed first." For IT teams, that's exactly right. The technicians who thrive won't be the ones who can remote in fastest — good tooling is making hands-on-keyboard the exception, not the badge of honor. They'll be the ones who can describe an outcome precisely, hand it to a script, and trust the platform to run it, verify it, and escalate when it fails.

That trust is the whole product. An RMM bolted onto the side of a monitoring tool can't give it to you, because the loop between alert, script, session, and ticket is where trust is built or broken. AlertMonitor keeps that loop in one place — which is why your first AI-generated remediation script won't be a science experiment. It'll be a Tuesday.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources