The best alternatives to a recently acquired IT automation platform aren't the ones with the longest feature list. They're the ones built on a different execution model entirely: workflows that run as deterministic code you own and can audit, not probabilistic AI that decides what to do at the moment a request arrives. That distinction drives everything else: approvals, auditability, compliance posture, and whether your automation logic survives a vendor strategy change.

Why are IT teams re-evaluating their AI automation platform right now?

The ServiceNow acquisition of Moveworks changed the competitive calculus in a way that goes beyond pricing and support tier concerns. It made an architectural question unavoidable: what happens to your IT automation when it's owned by the same company that owns your ticketing system?

This isn't a hypothetical risk. Acquisitions in the enterprise software market often produce product consolidation over time. Integrations that were neutral get deprioritized. Roadmaps align to the parent company's installed base. Pricing changes. Features that distinguished the acquired product get subsumed into the acquiring platform's vision.

For IT teams who have built workflows in that environment, this creates a real exposure. They're not just looking for a different product. They're looking for a model where their automation logic doesn't depend on a vendor's strategic relationship with another part of their stack.

That's the question driving most Moveworks alternatives evaluations right now. It's not "which tool has better AI." It's "which model do I trust to still serve my team independently in three years?"

What execution model should you require from any Moveworks alternative?

Every platform in this category claims to use AI to resolve IT requests. What they rarely explain clearly is what the AI does at the moment a request actually arrives.

There are two fundamentally different models.

Probabilistic at runtime. The AI interprets the incoming request, reasons about it, and decides what actions to take on the fly. Different phrasing, slightly different outcomes. The system is flexible but non-deterministic. You can observe what happened, but you can't fully prove what was supposed to happen, because the decision was made at execution time, not at build time.

Deterministic from pre-built code. The AI generates a workflow at build time. At runtime, a separate layer interprets the request, matches it to the right pre-built workflow, and triggers it. No code is generated or modified during execution. The workflow runs exactly as written. Employee 1 and employee 10,000 get the same result from the same workflow.

These aren't equivalent approaches with different aesthetics. They have different implications for compliance, security, and auditability. If your IT team handles access provisioning, manages sensitive credentials, or needs to prove to an auditor exactly what happened and who approved it, a probabilistic execution model creates problems a deterministic one doesn't.

Serval is built on the second model. The Automation Agent converts plain-language descriptions into TypeScript workflows at build time. The Help Desk Agent executes those workflows at runtime. These are structurally separate: there's no path from the conversational layer to the workflow-building layer. When a request arrives, the Help Desk Agent matches it to a published workflow and triggers it. If no matching workflow exists, the request escalates to a human. Nothing is improvised.

Why does the separation between building and execution matter for security?

The air gap between Serval's Automation Agent and Help Desk Agent isn't an implementation detail. It's the mechanism that makes trust possible.

In systems where the same AI layer handles both building and executing, a bad actor who can manipulate the conversational interface has a potential path to the execution layer. An AI that reasons at runtime about what actions to take is, by definition, reasoning about actions that haven't been pre-approved.

In Serval's model, end users only ever interact with the Help Desk Agent. The Help Desk Agent can only trigger workflows that have already been built, scoped, and published. It cannot call the Automation Agent. It cannot modify workflows. The set of things it can do is bounded by the set of workflows that already exist and have been explicitly authorized.

This is what "IT's Serval Now" means at the architecture level. It's not marketing language. It's a structural constraint that limits what the system can do without IT's explicit permission.

How should approval chains work in a trustworthy automation platform?

Any platform can say it supports approvals. What separates enforced approvals from advisory ones is where the approval configuration lives.

In a genuinely secure system, approvals are compiled into the workflow at build time. They're not a runtime option a user can configure or skip. The approval chain is part of the workflow definition: who must approve, in what order, under what conditions. When the workflow runs, those requirements are enforced. Every time. The audit log records who requested it, who was notified, who approved or denied, when execution started, and what the workflow did.

Serval's approval system works this way. When building a workflow in the Automation Agent, you configure individual approvers, groups synced from external systems, manager-based routing, multi-step sequential chains, or custom business-rule logic that approves or denies instantly based on conditions you define. Those approval requirements are part of the workflow and run identically on every execution. You can't trigger the workflow and skip the approval step. That's not a configuration option.

The audit log that results from this architecture is exportable, covers all workflow runs and configuration changes, and is ready for SOC 2 reporting, access reviews, and incident investigation.

What does RBAC on the automation layer actually mean?

Most ITSM platforms think about role-based access control in terms of who can see and edit tickets. Very few extend it to who can create and publish automation. That gap is where trust breaks down.

If any user with admin access can build a workflow and push it to production, you have a capable system with no guardrails on what gets shipped. The question "who approved this automation?" has no answer.

A genuine alternative needs enforced role separation on the building layer:

• Who can create new workflows (not everyone with admin access)

• Who can publish workflows to production (a distinct permission from creating them)

• Who can connect new integrations (a separate role from both)

• Which API endpoints a given integration is ever allowed to access, set as a ceiling at integration time, not just as a current default

• Which users or teams can trigger a given workflow, enforced by the platform, not advisory

Serval implements this at the workflow level through execution scope controls. Workflows are scoped as organization-wide, available to all employees via the Help Desk Agent, or team-members-only, restricted to internal IT team channels. A team-only workflow is invisible to the Help Desk Agent in user-facing channels. There's no configuration path that makes it accessible to end users without explicitly changing its scope. The platform enforces this. It doesn't ask you to remember.

The API scope ceiling is a related constraint. When you connect an integration to Serval, you define what that integration is ever permitted to access, not just what it uses on day one. Workflows built on that integration can never exceed that ceiling. This limits blast radius if a workflow has a bug, and it's provable to a security reviewer without having to audit the workflow code directly.

How do you evaluate whether a platform gives you real ownership of your workflows?

Portability is a useful proxy for architectural honesty. Ask any vendor: if you leave, what happens to the automation logic you've built?

In a code-based system, the answer is clear. Workflows are TypeScript files in version control. You can export them, diff them, hand them to a security reviewer, and run them through your standard code review process. You understand exactly what they do without the vendor's proprietary tooling. If you migrate to a different platform, you have your logic in a portable, readable format.

In a proprietary playbook system, the answer is much less clear. The workflows live inside the vendor's system. Portability depends on export features the vendor chooses to build and maintain. If the vendor is acquired and the product is consolidated, your automation logic may not travel with you.

Serval's Automation Agent generates TypeScript workflows. They're readable code, not proprietary configuration. The Serval CLI lets IT and development teams pull workflows to their local environment, edit them in any tool, push updates back, and maintain a comprehensive version history. The change log is visible, the diffs are reviewable, and the code is yours.

This matters not just for the exit scenario, but for day-to-day governance. Handing a workflow to a security reviewer for audit is a normal engineering process when the workflow is TypeScript. It's a different kind of conversation when the automation logic lives in a black box.

What does a complete IT automation platform look like versus a chatbot layer?

Platforms in this category fall into two rough architectural camps.

The first camp is a conversational layer added to an existing ticketing system. The AI routes requests, suggests articles, and deflects some volume. But the underlying resolution still involves a human, the ticketing system, and the existing workflow infrastructure. "Deflection" is the metric, meaning the user was redirected, not that the problem was solved without IT involvement.

The second camp is a platform built for full automation from the ground up. The goal is zero IT touch on requests that qualify for it. The metric is automation rate: requests completed without a human ever touching the ticket. Approvals may require human input, but that's a security feature, not a workaround.

Serval covers the full IT automation surface without being a chatbot layer on top of a ticketing system: help desk request resolution via Slack, Teams, email, phone, or web portal; access management with fine-grained policies, time limits, justification requirements, and automated deprovisioning; workflow builder that generates TypeScript from plain language and ships same-day against your actual stack; asset management; ticketing; and analytics powered by the Insights Agent, which surfaces automation opportunities from your ticket history.

The Insights Agent specifically is worth understanding. It analyzes patterns in your help desk requests and suggests new workflows based on what your team resolves manually. It doesn't require you to know what to automate next. It tells you. That feedback loop is what drives automation rates from 20% to 50% to 90%+ as the platform learns your environment.

What questions should you ask any vendor in this evaluation?

Use these as the baseline before moving any shortlisted platform to a pilot:

The acquisition of a major platform by a ticketing vendor didn't just create a switching moment. It clarified the question every IT team should be asking anyway: do you want IT automation that's auditable, deterministic, and owned by your team, or automation that's automatic in ways you can't fully inspect or prove?

Those are different products built on different principles. The one that fits your team depends on which answer you can defend to a security reviewer, a compliance auditor, and your own engineers.

Serval is built for the second answer. See how the platform works.