High Effort, Low Return: Why AI Agents Fail on Top of Broken Monitoring — and What to Fix First

McKinsey's Technology Trends Outlook 2026 delivers a number every IT leader should sit with for a minute: 89% of companies now use AI regularly, most are experimenting with AI agents, and only 37% attribute any positive EBIT impact to their AI programs. If you've sat through this year's vendor webinars, none of this is surprising. Every RMM, every monitoring platform, every helpdesk now ships with an "AI copilot" or an "autonomous remediation agent."

Meanwhile, on the ground: your on-call tech learns about a failed backup job from an angry ticket, the disk that filled up over six days gets discovered when SQL stops writing, and your "monitoring" stack is really four tools that don't talk to each other. That is exactly the gap McKinsey is describing — AI is being bolted onto IT foundations that were already shaky, and the result is cost and complexity without return.

The lesson for infrastructure and server monitoring teams is not "AI doesn't work." It's that autonomy on top of fragmented telemetry is an autopilot with no instruments. Here's why agents underdeliver, and what to fix first.

Why AI Agents Underdeliver on Real Infrastructure

An AI agent that promises to remediate incidents automatically needs three things to be anything more than a demo:

1. Complete, real-time telemetry. The agent can only act on what it can see. If disk data comes from a 15-minute poll, services are only covered by one generic RMM template, and scheduled task failures are invisible entirely, the agent is blind exactly when it matters.
2. A single, reliable alert stream. Not PRTG emailing a shared alias while Ninja opens its own ticket and the helpdesk gets the user's complaint three tools later.
3. Context. Knowing that the disk filling up on SQL01 coincides with a failed log-shipping task is context. Three disconnected tools produce three disconnected stories.

Most IT shops — and most MSPs with 20, 50, or 100 client environments — have none of the three. The typical stack looks like this: a server agent from ConnectWise or Ninja covering Windows endpoints, PRTG or Zabbix for network and uptime, a few application monitors owned by different teams, and ServiceNow or ConnectWise Manage for tickets. The disk alert fires in one tool. The service crash lands in another. The only alert that actually gets actioned is the user's ticket.

This is precisely what McKinsey points to when it notes that upgrades to the existing tech stack are necessary before agents function reliably. Agents also introduce their own failure modes: API rate limits, hallucinated runbooks, runaway automations, per-token costs, and an integration layer that has to be monitored itself. If your current monitoring missed the disk filling up for six days, it will also miss the agent that was supposed to clean it up failing to authenticate.

What This Costs in Practice

Three scenarios every sysadmin and MSP tech will recognize:

The disk that ate the weekend. Friday, 6 p.m. File server FS01, D: drive at 87%. Your monitoring checks every 15 minutes but thresholds are static — nothing tracks rate of change, and the 90% alert email goes to a shared mailbox nobody watches after hours. By Saturday evening the volume is at 100%, transaction logs can't grow, and the line-of-business app is down. The first ticket arrives Sunday at 9:12 a.m. — from a user. Detected by monitoring: never. MTTR: 38 hours, almost all of it detection delay.

The alert nobody owns. A critical Windows service crashes on APP01. Nagios emails the ops alias. The RMM creates a ticket in its own PSA with different timestamps. The tech who fixes it closes the RMM ticket, but the helpdesk ticket stays open until someone calls in. Your SLA report says four-hour response; reality was eleven minutes. You can't prove it, because the data lives in three systems that don't reconcile.

The AI pilot that quietly dies. Your team buys an "autonomous remediation" add-on to restart failed services. The agent polls stale data, doesn't know the service has a scheduled-task dependency, and restarts it on the wrong cluster node — twice. After the third incident, someone disables it. Nobody removes it, so it keeps burning subscription and token costs. Twelve months later: no EBIT impact. Welcome to the 63%.

Each of these is fundamentally a monitoring foundation problem, not an AI problem. And McKinsey's cost warning cuts both ways: agents don't just cost what you pay for them — they cost the stack upgrades you need first. If a monitoring overhaul is unavoidable anyway, the real question is what you build it on.

Get the Foundation Right First

The unglamorous answer is the correct one: before you buy autonomy, fix visibility. Unified monitoring is the work that makes every future automation — AI-driven or human — actually function.

AlertMonitor was built around that premise. It gives IT teams and MSPs a single pane of glass for the entire stack — servers, services, applications, Windows workstations, and scheduled tasks — monitored in real time with intelligent alerting. Instead of stitching together a server agent, a separate uptime tool, and a third application monitor, everything feeds one platform with one alert stream. When a disk hits 90% or a critical Windows service crashes, the right person is paged within seconds — not discovered by a user ticket 40 minutes later.

Here's the same incident, two ways:

The old fragmented way:

1. Disk alert fires in the uptime tool → email to a shared alias
2. Service crash caught by the RMM → a different tech's queue, different timestamps
3. User opens a ticket in the helpdesk → the only alert actually triaged
4. Tech RDPs into the server and digs through Event Viewer manually
5. Post-incident: reconstruct the timeline from four tools for the postmortem

The AlertMonitor way:

1. Disk crosses the 90% threshold → one alert in one stream, tagged with server, client, and severity
2. Service crashes, failed scheduled tasks, and patch status all surface in that same stream
3. The alert links directly to a ticket in the integrated helpdesk — no reconciliation needed
4. The tech remediates from the same console, because RMM is built in
5. One timeline, one report — SLA numbers you can actually defend in a QBR

What this changes in measurable terms: MTTD drops from tens of minutes (or "whenever a user notices") to seconds. The 2 a.m. page points at the actual problem instead of a symptom. New technicians onboard onto one console instead of five. And your alert history becomes real data instead of folklore.

One more thing: agents need this layer anyway. When you eventually pilot AI-driven remediation, you want it acting on unified telemetry, a single alert bus, and full environmental context — and you want a monitoring platform that watches the agents themselves. The foundation work is not a detour from your AI strategy. It is the prerequisite.

Practical Steps: What to Do This Week

Before evaluating any agent platform, run these checks. Each takes minutes, and each will show you exactly where your telemetry is leaking.

1. Pull disk usage across your servers right now

$servers = @("FS01","SQL01","DC01","APP01","RDS01")
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" -ErrorAction SilentlyContinue |
    Select-Object PSComputerName, DeviceID,
        @{N='SizeGB';E={[math]::Round($_.Size/1GB,1)}},
        @{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,1)}},
        @{N='UsedPct';E={[math]::Round((($_.Size - $_.FreeSpace)/$_.Size)*100,1)}} |
    Where-Object { $_.UsedPct -ge 85 } |
    Sort-Object UsedPct -Descending |
    Format-Table -AutoSize

If this returns a server above 85% that none of your tools alerted on, that's a concrete telemetry gap — exactly the kind an AI agent would have inherited rather than fixed.

2. Verify your critical services are actually being checked

Most RMM monitoring templates check "services" generically. Confirm the state of the ones that actually take the business down:

$criticalServices = @("DNS","kdc","Netlogon","W32Time","MSSQLSERVER")
foreach ($svc in $criticalServices) {
    $service = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if ($null -eq $service) {
        Write-Output "NOT INSTALLED: $svc"
    }
    elseif ($service.Status -ne 'Running') {
        Write-Output "DOWN: $svc is $($service.Status)"
    }
}

Any "DOWN" line here that didn't page anyone on your team is another blind spot to close. AlertMonitor checks critical services in real time and pages the right person the moment one stops — with the server, service, and exit state attached to the alert.

3. Find scheduled tasks that are failing silently

Backup scripts, maintenance plans, log rotations — tasks that run at 3 a.m. and fail without a sound are the classic "we found out from the user" incidents:

Get-ScheduledTask |
    Where-Object { $_.State -ne 'Disabled' } |
    Get-ScheduledTaskInfo |
    Where-Object { $_.LastTaskResult -ne 0 -and $_.LastTaskResult -ne 267009 } |
    Select-Object TaskName, LastRunTime, LastTaskResult |
    Sort-Object LastRunTime -Descending

0 means success, 267009 (0x41301) means currently running, and 267011 (0x41303) means the task never ran at all. Anything else deserves a look. AlertMonitor monitors scheduled task results natively, so a non-zero exit code lands in your alert stream with the code attached — not buried in an Event Viewer nobody opens.

4. Baseline patch status

Stale hotfix data is usually a symptom of a broken check-in chain — the same kind of broken foundation that will sink anything autonomous you layer on top:

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 5 HotFixID, Description, InstalledOn

If InstalledOn on a production server is months old, fix the reporting chain before you automate anything against that data.

5. Consolidate alert streams before adding intelligence

Apply a simple rule this quarter: every alert lands in one stream, with severity, asset, and client attached. If an outage today can page one tool while the ticket is created by another and reported by a third, no AI layer will fix that — it will just accelerate the confusion. This is exactly the problem AlertMonitor collapses: unified telemetry, a single intelligent alert stream, escalation rules that page the right person in seconds, and RMM, helpdesk, and patch management in the same platform so detection and remediation share one system of record.

6. Only then, pilot agents — against a baseline you can measure

With unified monitoring in place, an AI agent gets clean telemetry, full context, and — critically — you can measure its actual impact on MTTD and MTTR from one system. That's how you end up in McKinsey's 37% with real EBIT impact, instead of in the 63% paying for complexity you can't demonstrate value from.

The Bottom Line

The industry consensus is shifting from "AI everywhere" to "AI where the data supports it." For infrastructure and server monitoring teams, that data starts with coverage: every server, every service, every scheduled task, one alert stream, one timeline. Get that right with AlertMonitor, and you fix today's outages first — then, and only then, hand the wheel to an agent with instruments it can actually read.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources