Most agents wait for a prompt. Proactive agents don't.

Agentic automation follows a familiar pattern: someone asks a question, files a ticket, fires an alert, and the agent responds. The prompt is the trigger. No prompt, no work. Automation has worked this way for decades, long before anyone called it an agent: it waited for a human to notice a problem before it could act.

Proactive agents break that pattern. They run without anyone asking, looking for problems no one has reported yet. Removing the prompt expands how much can be automated.

It’s also where the difficulty comes from. A prompt quietly does two jobs at once. First it detects, because someone noticed a recurring pattern or suspected something was off. Then it judges, deciding the pattern is worth chasing. Strip the prompt away and the agent has to do both itself: find what's wrong, and decide whether the finding is worth a person's time. So the surprising lesson from building these isn't about finding issues. It's about deciding which ones are worth surfacing.

The ticket that was never filed

One of our proactive agents found a problem across a customer's laptop fleet before a single ticket had been filed about it. No one had reported it, because to any individual user it hadn't yet become bad enough to report, but in the fleet's device data, the pattern was already there.

Roughly 4,900 devices were affected by a single root cause: built-in audio was cutting out mid-session, recoverable only by a reboot that held until the next failure. Reinstalling drivers didn't help. 

Running against the customer's device logs and device-management data, the agent did something a human analyst would have struggled to do at that scale. It correlated the failure signals across the whole fleet, isolated the affected hardware models, and cross-referenced the vendor's own documentation. The cause wasn't a driver bug. It was an interaction between a firmware setting and an OS-level configuration for this customer, the kind of bug that only becomes visible when you can see across thousands of devices, the vendor's configuration model, and outside reports, all at once.

The whole investigation took 26 minutes.

But finding the problem was only half the work. Rather than leave a diagnosis, the agent proposed a ready-to-apply remediation workflow to apply the fix per device across every affected user. Optionally, agents open a change ticket capturing the findings and steps, keeping the whole process auditable, which meant IT never had to open, triage, and resolve thousands of hardware tickets.

Not every proactive agent hunts for incidents. One reviews recent tickets, finds repetitive requests that don't yet have a workflow behind them, and suggests one. Nobody filed a ticket saying "we're missing automation." The agent found that pattern on its own.

That's a problem discovery of a different kind: not finding what broke, but finding what was never built.

What these agents have in common — and why it's practical now

They don't share a task. Serval ships a handful out of the box: one grades how the team handled escalated tickets, one digests the last day of tickets and flags what needs attention, one scans the endpoint fleet for at-risk devices, one sends a daily Slack digest of unresolved issues to the right owner. And customers build any number of their own, pushing the ceiling of how much they can automate as high as they want.

These agents are always-on, running every hour, every day, every week. Because the context they run against is always changing, agents can catch problems as they emerge.

The industry shift from reactive to proactive was driven by two reasons. First, models got much better at long-running, open-ended tasks, so they can explore a problem, gather evidence, and refine their findings. Second, they can now reason across large and heterogeneous inputs at scale: tickets, logs, asset inventories, device data, and external sources. 

The question we're still working through

Should a proactive agent be narrow or broad? A narrow agent has a specific task: scan device logs for driver conflicts, check the asset database for duplicates. It does one thing well and its output is easy to judge, but you have to know what to point it at. A broad agent gets an open instruction: investigate, find anything concerning. It can surface things you'd never have thought to ask about. It can also surface things that aren't problems, and it's harder to tell whether its findings are useful.

We chose broad. We can afford to, because narrow work is already handled by other parts of Serval’s system (deterministic workflows for small repeatable tasks, and one-time sessions when someone knows what to build). We wrote about that engine, Catalyst, in an earlier post. Proactive agents run on the same underlying system, but unprompted, which is what frees them to go looking without a specific target. That's the only way to discover unknown problems.

Our bet comes with a catch we haven't fully solved. A broad agent is only as good as its filtering: the more open the instruction, the more it surfaces, and the more the value rides on suppressing the noise. The question isn't really "narrow or broad" anymore. It's whether it can access the right tools when it needs to, find relevant results, and distinguish signal from noise. We think it can. We're not done proving it.

The hardest problem is the output

We assumed the investigation would be the hard part. A few months in, we found that filtering the results was harder.

Getting an agent to watch systems and investigate is the easy part. Getting it to produce relevant output is hard. Return the same findings every run, and people stop reading the reports. Surface fifty issues a day, most of them noise, and people start ignoring it. Either way the value disappears, and you've built a more expensive version of the alert fatigue you already had.

We fight this on a few fronts. We deduplicate issues already reported, so the agent doesn't resurface them. We rank findings by how many users or devices are affected, so the biggest ones come first. And we close the loop, so every finding gets feedback, explicit and measured. An admin can mark a finding useful or not, and the system tracks the impact: users helped, hours saved, tickets prevented. In a closed-loop system, feedback re-tunes the agent's instructions, adjusting how broad or narrow it should be and what's worth looking at next.

This is still an open problem. The ideal is an agent that surfaces exactly the issues that deserve attention, nothing more, nothing less. Getting there takes real calibration with real customers.

Finding the problem first

Most organizations have already automated the obvious things: password resets, device enrollment, access requests, provisioning. Automating those gets you to a certain level of coverage, and then the usual approach stops working. Call it the automation ceiling.

The problems above that ceiling are the ones without a known pattern to automate against, the ones that often don't even look like problems until they're widespread. The audio failure was one of them. Proactive agents are how you reach that work: they don't wait for a pattern or a prompt, they go find the problem first.

That is what raising the automation ceiling means. Not automating common use cases, but automating what couldn't be automated before.