Auto-Built Automations Need Approval and Rollback Gates

Every IT automation I've shipped started as a script someone wrote at 11pm to stop a recurring annoyance, and every one of them eventually did something its author didn't predict. Now vendors are shipping agents that write those scripts for you, on a schedule, without being asked. That's a real step forward, and it moves the failure point from "the script has a bug" to "nobody reviewed what the agent decided to build."

What Serval actually shipped

Serval made Catalyst, its admin-facing "super agent," generally available on August 20, 2026, and enabled it by default for every organization. It sits above the service management platform and can look at ticket history and existing procedures, then build automations. The part that caught my attention is the background agents: long-running agents that investigate, diagnose and suggest fixes before an employee files a ticket.

The press-release example is a good one. A background agent correlated switch telemetry, DHCP data and historical tickets, traced the problem to network configuration drift, and drafted a remediation workflow that admins could apply in one click. That is exactly the kind of cross-system correlation a human on-call engineer does at 2am, badly, with six browser tabs open.

The adoption and savings numbers are vendor-reported, so treat them as claims, not benchmarks. Serval says more than 90% of customers adopted Catalyst as their starting point for automation after the beta, and that Ramp builds workflows 50% faster with it. VentureBeat's report attributes to Serval that Ramp automated 600 laptop replacements and saved 150 hours. Those are plausible magnitudes. I've seen a 4-system automation ecosystem save 73+ hours a month for me, so I don't find the order of magnitude hard to believe. I just can't verify theirs.

Why "agent builds the automation" changes the risk

When a human writes an automation, review happens at a natural choke point: the pull request, the change ticket, the colleague who asks "wait, what does this do to contractors?" When an agent proposes and builds the automation, that choke point doesn't exist unless someone deliberately builds it back in.

There are two distinct failure modes, and they need different controls:

An approval gate only covers the first row. Most teams I've worked with stop there and call it done. The other three rows are where the 3am incidents live.

What Serval gets right

I'll be fair here, because the design is more careful than the headline suggests. According to Serval's announcement, Catalyst operates with the permissions of the user and is scoped to a single team workspace. Everything it builds is staged as a draft, and nothing touches production until it is explicitly published. When it runs a temporary workflow in a third-party system, reads run freely, but any action that would mutate an external system needs user approval first.

That read/write split is the single most important pattern for agents touching infrastructure, and I use it in everything I build. Reads are cheap and reversible. Writes are where you pay.

Two more details matter. First, workflows are deterministic TypeScript code, so once published, what runs is reviewable code in version control, not a model improvising at runtime. Every run produces an exportable execution record. That's the difference between "the agent decided something" and "this exact code ran with these inputs." Second, Serval can require a second person to sign off using a pull-request-style review, and its documentation describes approval options from individual approvers to group quorums and multi-step chains.

Compiling the agent's output down to deterministic code is the right call. It means the model's non-determinism is confined to authoring time, where a human can inspect the result, and removed from execution time, where it would hurt.

The gaps I'd check before turning it on

Here is where I'd push, and where you'd want to verify against Serval's docs for your own plan rather than take my reading as settled.

Rollback of the side effects, not just the workflow. Serval's docs describe workflow versioning: restoring an earlier version creates a new version on top and doesn't overwrite or delete existing ones. That's a clean rollback for the automation definition. But the sources I found don't describe a dedicated undo for the changes a background agent's fix made in a live system. If a drift remediation rewrites switch configuration, restoring the old workflow version does not restore the old switch config. Ask the vendor directly how that's handled, and don't assume the answer.

Background agent approval versus workflow approval. Reporting from runtimewire says background agents inspect connected systems on a schedule and require approval before applying a proposed fix. Good. But "approval" is only as good as who gets asked and how often. An approval queue that pings the same admin forty times a day becomes a rubber stamp within a week. I've watched this happen with every alerting and approval system I've ever deployed.

Which data the agent sees. Serval's security documentation reportedly says Catalyst has no access to end-user ticket context and runs in a different environment from the help desk, while the marketing talks about mining ticket history. That is probably the difference between admin-side ticket data and end-user conversation content, but I'd confirm exactly what flows into the model before you hand it a production tenant.

Which model. Serval is model-agnostic and lets admins supply their own OpenAI or Anthropic API keys, per VentureBeat's report. Which specific model powers Catalyst isn't confirmed in what I found, and I wouldn't assume every user gets to choose. If model behavior matters to your compliance posture, get it in writing.

The gate pattern I use on every agent that writes automation

I've built this shape into every project where an agent can propose changes to real systems, including the AWS and Zendesk serverless integration that delivered first-ever SLA compliance. The principle is the same whether the agent is vendor-built or mine. Roughly:

propose  ->  draft (inert)  ->  review  ->  canary  ->  publish  ->  monitor
                                   |           |                        |
                              different       small                   auto-
                              human than      scope,                  revert on
                              requester       reversible              threshold

Concretely, that becomes six rules:

1. Drafts are inert. A proposed automation can be read, diffed and dry-run, but it can't execute against production. Serval's draft-until-published model satisfies this.
2. The approver is not the requester. If the person who triggered the agent can also approve its output, you have a single point of failure with extra steps.
3. Dry-run output is part of the review. The reviewer should see "this would have touched these 12 objects," not just the code. Diff the effect, not only the source.
4. First publish runs on a canary scope. A handful of devices or users, not the fleet. If the agent's inference was wrong, you find out at n=4, not n=400.
5. Every mutation is attributable and reversible by design. Before the automation changes a system, it records the prior state somewhere it can restore from. This is the rollback that versioned workflows alone don't give you.
6. A tripwire halts it. A threshold on error rate or number of objects changed per window flips the automation back to draft automatically. A kill switch someone has to remember to press is not a kill switch.

Rule 5 is the one teams skip, and it is the hard one. Snapshotting prior state means every connector needs a "read current, write previous" pair. It roughly doubles the work per integration. It is also the difference between a five-minute recovery and a multi-day forensic exercise.

What I'd do

If I were adopting Catalyst or anything like it tomorrow, I'd start with read-only background agents for two weeks. Let them surface findings and draft workflows, publish nothing, and measure how often the proposals are correct. That gives you a real precision number for your environment instead of a vendor's headline.

Then I'd open writes one low-risk workflow class at a time (laptop replacement, access requests with clear policy) and keep high-blast-radius classes like network or identity configuration behind two-person review indefinitely. Require a different approver than the requester, keep canary scopes small, and build the prior-state snapshot yourself if the platform doesn't give you one.

The reported results, 150 hours saved on laptop replacements and 95% of just-in-time infrastructure access automated at one customer, are exactly the low-risk, high-repetition work where automation pays and where approval flows are cheap. The danger is the temptation to extend the same trust to work where a wrong guess is expensive. Match the control to the cost of being wrong.

If you're designing agent approval and rollback flows for your own IT or ops stack and want a second pair of eyes, you can reach me at lazar-milicevic.com/#contact, or browse the rest of the blog for more on running agents unattended without losing sleep.