Roving IT Agents: What Serval's Catalyst Signals

By Lazar Milicevic · Published September 23, 2026 · 10 min read

Your help desk queue is a lagging indicator. By the time a ticket says "VPN is slow again," three people already Slacked you, one gave up and went home, and the root cause — a certificate that expired at 2 a.m. — has been sitting in a monitoring dashboard nobody reads. Serval is betting the fix is to stop waiting for tickets at all: their new admin-facing "super agent," Catalyst, spawns background agents that read ticket history, SOPs, and system telemetry, then propose (or build) the automation that removes the class of ticket entirely.

If you run IT for a 20-person startup or ops for a 200-person company, this is the pattern worth paying attention to — not because Serval is the only vendor, but because the shape of the solution (roving agents that automate themselves) is what internal automation is going to look like for the next few years. Here's what actually changes, what to steal for your own stack, and where the sharp edges are.

What Catalyst actually does

Catalyst is a control-plane agent that sits above Serval's service management platform and orchestrates smaller agents that inspect ticket history, standard operating procedures, and connected systems (Okta, Jamf, Google Workspace, Slack, and so on). Instead of a human admin deciding "we should automate password resets," Catalyst clusters the tickets, drafts the workflow, and — if you let it — deploys it.

The three things that make this different from a normal ticket-automation tool:

1. The agent picks the automation target. It reads six months of tickets and says "you've resolved 412 instances of the same MDM enrollment failure; here's a runbook."
2. It writes the workflow itself. Not a template you fill in — an actual sequence of API calls, conditionals, and approval gates.
3. It runs continuously in the background. Not a one-shot audit. It keeps watching for new patterns and new ticket clusters.

That third point is the operationally interesting one. Most "AI in ITSM" tools today are reactive: a ticket comes in, a model classifies it, maybe suggests a KB article. Roving background agents flip the polarity — the goal is to prevent the ticket from ever being created.

Why "background agent" is the right primitive

The industry keeps rediscovering this pattern. GitHub's autofix, Visa's patching agent, Cursor's async coding agents, and now Catalyst all share the same shape: a long-running process that watches a stream of events, decides when to act, and either fixes the issue or files a proposal for a human to approve.

For internal IT, the stream is:

• Ticket creation events (Zendesk, Jira Service Management, Freshservice)
• Endpoint telemetry (MDM, EDR, patch status)
• Identity signals (failed logins, MFA prompts, group membership drift)
• SaaS admin logs (Google Workspace, Slack, GitHub)
• Monitoring alerts (Datadog, Grafana, uptime checks)

A background agent is fundamentally a loop:

# Simplified skeleton of a roving IT agent
while True:
    events = ingest_events(since=last_checkpoint)
    clusters = cluster_by_signature(events)

    for cluster in clusters:
        if cluster.frequency > THRESHOLD and cluster.confidence > 0.85:
            proposal = draft_automation(cluster)
            if proposal.risk_score < AUTO_APPROVE_CEILING:
                deploy(proposal, mode="shadow")
            else:
                notify_admin(proposal, channel="#it-automations")

    last_checkpoint = now()
    sleep(POLL_INTERVAL)

Nothing here is exotic. What's changed is that LLMs are now good enough to do the cluster_by_signature and draft_automation steps against messy natural-language ticket text and heterogeneous API surfaces without a human writing the classifier.

The four categories of tickets worth attacking first

Not every ticket should be automated. In practice, the ROI concentrates in four buckets:

The buckets to not automate first are the interesting ones: vague performance complaints, anything touching payroll or finance systems, and one-off exceptions. Those need judgment, and an agent that guesses wrong on payroll access is a fireable offense.

A useful heuristic: if a human resolver has closed the same ticket signature more than a dozen times with the same three steps, that's an automation. If they've closed it three times with three different sequences, it's not — yet.

How to build a Catalyst-style loop on your own stack

You don't need to buy Serval to get the pattern. Here's the minimum viable version, using tools most small teams already have.

Step 1: Get your tickets into a queryable form. Export or stream from your help desk into a database (Postgres works fine) or a vector store if you want semantic clustering.

# Nightly export from Zendesk to Postgres
curl -u "$ZENDESK_USER/token:$ZENDESK_TOKEN" \
  "https://$SUBDOMAIN.zendesk.com/api/v2/incremental/tickets.json?start_time=$LAST_RUN" \
  | jq '.tickets[]' \
  | psql -c "COPY tickets FROM STDIN WITH (FORMAT csv)"

Step 2: Cluster by signature, not by keyword. Embed the ticket subject + first message, run HDBSCAN or a simple k-means, and label the clusters with an LLM. The output is a table of "here are the 20 things people ask about, sorted by frequency."

Step 3: Have an LLM read the top clusters and the closed-ticket resolution notes. Ask it to write a runbook in structured YAML:

automation:
  name: mdm_reenrollment_macos
  trigger:
    ticket_signature: "MDM enrollment failed"
    confidence_threshold: 0.9
  preconditions:
    - user.department != "Finance"
    - device.os == "macOS"
    - device.last_check_in < "24h"
  steps:
    - action: jamf.trigger_reenrollment
      params:
        device_id: "{{ device.id }}"
    - action: wait
      duration: 300s
    - action: verify
      check: device.mdm_status == "enrolled"
  fallback:
    - action: escalate_to_human
      queue: "it-tier-2"
  approval_required: false
  audit_log: true

Step 4: Deploy in shadow mode first. The agent watches for the trigger, generates what it would do, and writes it to a log. A human reviews for two weeks. Only then flip to active.

Step 5: Instrument everything. Every action, every skip, every fallback, every approval — logged with a correlation ID so you can audit "why did the agent do X on Tuesday?"

The whole thing is maybe 1,500 lines of Python plus a scheduler. The hard part isn't the code; it's the discipline of not skipping shadow mode.

Where roving agents break (and how to bound the damage)

The failure modes are predictable. If you're deploying this pattern, plan for them explicitly.

Silent scope creep. The agent starts by resetting passwords, then quietly starts resetting service account passwords, then locks out a production integration at 3 a.m. Bound this with an explicit allowlist of actions per automation, not a denylist. If the runbook doesn't say "you may touch service accounts," it can't.

Confidence inflation. LLMs are chronically overconfident on ticket classification. A ticket that says "email not working" could be Gmail, Outlook, a distribution list, a mail relay, or the user's phone. Require multi-signal confirmation before auto-acting: ticket text + user's device state + recent login patterns. Any single signal is not enough.

The training-data trap. If your resolvers have been closing tickets badly for a year (e.g., "restart the laptop" for every issue), the agent will learn to do that too. Before you turn this on, audit your top 20 ticket resolutions for actual correctness. Anthropic's guidance on building effective agents makes this point well: the workflow inherits the quality of its exemplars.

Approval fatigue. If every automation needs human approval, humans start rubber-stamping. Better: tier your automations. Tier 1 (read-only, self-service unlocks) runs freely. Tier 2 (writes to non-critical systems) needs one approver. Tier 3 (touches finance, payroll, or production) needs two approvers and a change window.

Audit trail gaps. When something goes wrong six weeks later, you need to know exactly what the agent saw, what it decided, and why. Log the input context, the model output, the action taken, and the observed result. Ship it to somewhere immutable. The NIST AI Risk Management Framework is a reasonable starting point for what "reasonable governance" looks like if your compliance team asks.

Buy vs. build: an honest read

Serval, Moveworks, and a handful of others are selling the packaged version of this. The math for a 10-person shop looks different from a 500-person shop.

For companies under about 50 people, the honest answer is that you don't have enough ticket volume to justify either the vendor cost or the build cost. What you have is three to five painful recurring problems, and each of them is one focused workflow — not a super-agent — away from being solved. Check current pricing pages directly; the vendor landscape is moving fast enough that any number I quote will be wrong by next quarter.

The agent-writes-agents pattern is spreading

Catalyst is one instance of a broader shift: agents that decide what to automate and then build the automation. GitHub's Copilot Workspace does this for code changes. Visa's patching agent does it for CVEs. Cursor's background agents do it for pull requests. The common thread is that the identification of work has been merged with the execution of work.

For internal ops, the implications are:

• Your automation surface area explodes. You used to have 30 workflows because you had time to build 30. Now you can have 300, because the agent builds most of them.
• Governance becomes the bottleneck. Deciding which of those 300 workflows should exist, and who's accountable when one misfires, is the new hard problem.
• The role of "IT admin" shifts toward "policy author." You spend less time writing scripts and more time writing the boundaries the agents run inside.

None of this is speculative — it's already how the teams shipping this stuff talk about it. Google's Site Reliability Engineering handbook has been making the "toil elimination" argument for a decade; agents are the mechanism that finally makes it tractable for teams smaller than Google.

What to actually do this quarter

If you're a solo founder or a small ops lead reading this, here's the boring, high-leverage version:

1. Pull your last 90 days of tickets or support requests into a spreadsheet. Just the subject line and resolution notes.
2. Sort by frequency of similar-sounding issues. You'll find that 60-70% of your volume is 8-12 patterns.
3. Pick the top three that have a deterministic fix. Not the ones that need judgment — the ones where a human is doing the same three clicks every time.
4. Automate those with whatever you already have — Zapier, n8n, a Python script on a cron, a Claude-based agent with tool access. Doesn't matter. What matters is closing the loop.
5. Only after those three are running cleanly for a month, think about a roving agent that watches for new patterns.

Skipping step 4 and jumping to step 5 is the most common mistake. A background agent that generates automations for a team that hasn't proven it can run automations is a way to generate expensive incidents faster.

How BizFlowAI approaches this

We build the small-team version of what Catalyst does at enterprise scale: custom Claude-based agents that read your ticket queue, your Slack, or your inbox, cluster the recurring work, and either resolve it directly or file a clean handoff to a human. Most of what we ship for clients is a focused agent that owns one workflow end-to-end — lead qualification, invoice follow-up, onboarding provisioning, first-line support triage — with a shadow-mode rollout, clear audit logs, and a kill switch. Boring on purpose.

If you're staring at a ticket queue or an inbox that keeps generating the same five problems and you want to know which ones are worth automating first, that's the discovery call. We'll look at your actual data, tell you what's worth building, what isn't, and what you can wire up yourself in an afternoon.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.