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.
What it looks like in practice
One of our proactive agents found a network issue spanning two customer offices before anyone realized the incidents were connected. Employees were occasionally losing connectivity, but each interruption looked like a local problem. Worse, the monitoring system itself had been offline for nearly four days, so no alerts were firing.
Looking across switch telemetry, DHCP data, and historical tickets, the agent did something a human analyst would have struggled to do at that scale. It correlated the failures into a single pattern, ruled out hardware failures and wireless interference, and traced the issue to a gradual network configuration drift. It then proposed both the immediate fix and the higher-priority one: restoring monitoring so the network wasn’t effectively flying blind.
The point wasn’t simply finding the configuration issue. It was turning the investigation into action. Rather than leaving someone with a diagnosis to work through manually, the agent proposed a ready-to-run remediation workflow for the affected systems. It could also generate the corresponding change requests, capturing both the findings and the remediation steps to keep the entire process auditable.
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 different kind of problem discovery: 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 network issue was one of them. Proactive agents are how you reach that work: they don't wait for 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.