What can this agent do in my stack, with whose permission?
An answer, a ticket and a provisioned account are three different outcomes. Buy an IT agent for the change you need—not for the conversation it can hold.
Start with your existing service desk and identity provider. Then name the exact action, execution credential and approval rule. This comparison separates established platforms and newer options, including Serval, by what the sources establish and what your pilot still has to prove.
By Penny · StackReceipt · Documentation research, not a hands-on benchmark
The decision before the shortlist
“Give me access” is not one capability.
The following is an illustrative request, not a tested workflow. An employee asks for access to a design app. An agent might do any of these jobs:
01
Answer
Find the approved access policy or troubleshooting article. No account changes.
Proof to inspectThe current source, and whether the requester is allowed to read it.
02
Collect and route
Capture the app, reason and requested scope; create a ticket or link to a portal.
Proof to inspectThe right ticket, owner and context—not a message saying “done.”
03
Assist a technician
Suggest or run a configured action while a service-desk professional is working.
Proof to inspectWho confirms the action, and whether that person is the required approver.
04
Execute the request
After the required authorization, change access in the actual identity or application system.
Proof to inspectThe execution identity, approval record and target resource’s final state.
These are workflow descriptions, not maturity scores. One product can do several. Closing a ticket does not prove that access changed; a technician’s confirmation does not necessarily satisfy a manager-approval policy.
Separate five roles before you connect anything.
Requester asks for help. Invoker is allowed to launch the agent. Execution identity holds downstream permissions. Approver authorizes the specific change. Log reader can inspect the resulting conversation or action record. One login does not establish all five.
No overall winner
Compare the action and its authority.
Start with the products already closest to your support system. Do not compare integration counts as if each logo meant a working, authorized action.
Documented
Technical/support docs explain a capability or mechanism. Not independently tested.
Vendor-claimed
A product page or broad assertion without the action-specific mechanics needed here.
Unknown
Not established by the reviewed sources. Not proof that a feature is absent.
Sources checked (UTC). Availability, release, plan and configuration can change the answer. There are no product test scores in this guide.
Vendor-claimed workflow RBAC and directory-synced group protection; execution principal unknown.
Manager/admin approval settings; Runbook approval can be disabled. [RI1][RI2]
Scope: employee knowledge, access requests, software fulfillment, ticket triage and escalation. Not autonomous SRE, SOC/security response, production-infrastructure remediation or general-purpose agent builders.
Broaden the shortlist
Look beyond the incumbent. Keep the same evidence bar.
Newer options can change who builds the workflow, who runs the help desk, and how much of your existing stack you keep. Funding and vendor-reported growth are context, not proof that an agent can safely complete your request.
Decide whether you want an AI layer over the current service desk or a service-management replacement. Validate the chosen deployment, not both at once.
A startup-origin option, now part of Palo Alto Networks. Check the employee action path and confirm product continuity, packaging and support in writing.
Consider a chat-first IT support startup with Okta-focused access workflows. Ask for the enforcement mechanics behind its approval and logging claims.
Follow each profile for the primary sources and their limits. This is a curated comparison, not a fastest-growing ranking. Require an action-specific demo and a written plan, implementation and usage quote before committing.
What the demo must settle
Read the boundary before the feature list.
“Editorial fit” and the disqualifiers below are our reasoning from the cited scope, not measured superiority. Each profile keeps the unknowns visible.
01 / Employee self-service
Moveworks
Editorial fitEvaluate a conversational entry point over the business systems you intend to keep.
Built-in actions include account unlocks, password resets, software provisioning and ticket changes. For supported account plugins, a deflection setting can substitute instructions or a self-service link for execution. [M1]
Permission boundary Documented
The docs describe plugin launch rules, downstream/API authorization checks and a delegated OAuth option. Do not assume every connector runs as the requesting employee. [M2][M3]
Logging boundary Documented
Built-in plugin logs document action traces, requester, timestamps and available request/response details. Collection starts when enabled, with a rolling one-week view and no backfill. Agent Studio, ingestion and authentication calls are outside this log’s scope; sensitive bodies are redacted for users without the specified privileged roles. [M5]
Not established Unknown
Mandatory pre-execution approval for every sensitive action, complete cross-system action audit coverage and universal rollback are not established by this source set.
What could rule it out
Do not count an account request as automated fulfillment if its selected plugin only returns a portal link. Require the target-system action, not just a supported app name.
Ask to see, not just hear
Show one permitted account action, the credential it uses and a denied requester. Inspect the target record and the approval evidence for that exact plugin.
02 / Service-desk record automation
ServiceNow native ITSM AI agents
Editorial fitIf service records already live in ServiceNow, evaluate the native workflow before adding another orchestration layer.
The cited incident-triage workflow categorizes incidents, adds service/configuration-item context and associates related records. It writes changes to incident notes/comments; this does not prove the employee’s underlying problem was resolved. [S1]
Two separate authority decisions Documented
Invocation permissions and execution identity are distinct. Dynamic-user role filtering differs from the fixed roles of a dedicated AI user. Inspect downstream authority as well as who may invoke the agent. [S2]
Approval is configuration-specific Documented
The documented flow action supports supervised and autonomous modes. This is not a universal approval default for every ITSM agent. Confirm release, required plugins, active triggers and execution roles. [S1][S3]
Not established Unknown
Immutable audit retention/export and automatic reversal of every downstream write are not established here. The checked unversioned documentation resolved to the Brazil release.
What could rule it out
If your requirement is software provisioning, incident categorization alone does not meet it. Ask for the additional fulfillment workflow and its permissions.
Ask to see, not just hear
Run the chosen workflow with an underprivileged requester and a denied reviewer. Trace the execution user, incident changes and any downstream write separately.
03 / Employee and technician surfaces — keep them separate
Freshservice with Freddy AI
Editorial fitStart by deciding whether the employee or the service-desk technician will use the agent; then evaluate the matching surface.
Studio agents can answer questions, create incidents and invoke configured workflows, including prebuilt IT requests. Workflow-specific connector permissions and approvals still need inspection. The introduction excludes Freshservice MSP mode. [F1]
Technician: Copilot Actions Documented
Copilot Actions has app/action configuration, agent-group access and per-action allow, approval-required or block settings. Approval is the human service-desk agent’s confirmation in the ticket view—not necessarily a separate manager’s authorization. An assigned Copilot license is a dependency; do not transfer these controls to every Studio workflow. [F2]
Conversation-reader boundary Documented
Studio users can access conversation histories across the workspace without conversation-level restrictions; linked tickets retain their ticket permissions. Conversation logs include transcripts, sources and triggered skills, not independent proof of the target’s final state. [F3]
Not established Unknown
A uniform downstream execution identity and approval policy across all Studio external actions are not established. The Copilot action page does not establish a complete cross-app audit or universal rollback.
What could rule it out
The cited Studio introduction excludes Freshservice MSP mode. If your policy requires per-conversation restrictions for Studio users, resolve workspace-wide visibility before granting access. Confirm edition, channel and packaging.
Ask to see, not just hear
Demonstrate the employee path and technician path separately. Reject a sensitive action, inspect the target system and check which staff can read the transcript.
04 / Managed conversation flows
Jira Service Management virtual service agent
Editorial fitEvaluate it when the support system is Jira Service Management and the required task can be expressed as a configured conversation flow and API call.
A building block, not a ready-made task Documented
A send-web-request step supports read/write HTTP methods, configured authentication and response-dependent branches. A named application’s presence does not prove your desired operation is already implemented. [J1]
Credential and rollout boundary Documented
The step documents client-credential and basic-auth configurations and flags rollout. Chat login does not establish delegated employee authorization for the downstream request; confirm availability in your tenant. [J1]
Tracking must be designed Documented
The step describes using request/response identifiers for downstream tracking. That configurable pattern is not a complete action-audit guarantee. [J1]
Not established Unknown
Mandatory human approval, universal audit export and automatic rollback are not established by the reviewed step documentation.
What could rule it out
If no one owns the endpoint, credentials, error branches and permission checks, a flexible HTTP step is not a maintained fulfillment service.
Ask to see, not just hear
Call a sandbox endpoint as an allowed and denied requester. Return a timeout, retry safely and prove that the target changed once—or not at all when rejected.
05 / AI service management + governed workflows
Atomicwork AI Workforce
Editorial fitEvaluate its proposed AI roles and workflow engine as an overlay to ServiceNow/JSM or as a replacement; distinguish product-level claims from specific released controls.
Product pages describe Okta app provisioning/revocation, cross-system workflows and tool-level Allow/Ask/Deny policies. Natural-language, visual and code-based builders are offered. These remain vendor claims rather than tested action-specific enforcement. [A1][AW2]
Specific approval behavior is documented Documented
Release notes document change approvals from Slack, Teams or a dashboard, with timestamps and comments. The July 18, 2025 release note says requester self-approval is enabled by default; disabling it blocks self-approval even when assigned indirectly. Do not generalize this change-specific control to every AI tool call. [AW3]
Workflow logs, with a scope limit Documented
A product release documents Request Activities logs showing workflow action inputs/outputs, third-party API calls and retries. This is useful troubleshooting evidence, but does not establish coverage of every AI Coworker action, immutable retention, export or automatic reversal. [AW4]
Company context
Startup provenance: founded in 2022; Atomicwork announced more than $25M in Series A financing on January 28, 2025. Funding is not a customer-outcome or revenue-growth benchmark. [AW5]
Ask for the full quote
Compare usage credits with completed-outcome billing: how do retries, multi-Coworker handoffs, minimums and implementation affect the quote, and what differs between an ITSM overlay and full-platform plan? [AW6]
Not established Unknown
Action-specific execution credentials, downstream authorization mechanics, current log retention/export and compensating actions are not established by this source set. Confirm whether the selected flow uses workflow approvals, AI tool policies or both.
What could rule it out
Do not equate Ask with independent manager authorization, or assume change self-approval prevention is enabled. Require proof of the selected request’s exact gate before sensitive provisioning.
Ask to see, not just hear
Show one Okta access request using the selected AI/workflow path. Withhold approval and try an ineligible requester; inspect target membership and action logs. For change workflows, disable requester self-approval and test an indirect approver assignment.
06 / Workflow-based request fulfillment
Aisera agentic ITSM
Editorial fitEvaluate a named employee request and its fulfillment workflow; keep broader IT-operations claims out of this purchase decision.
The vendor’s ITSM overview describes request fulfillment through integrated workflows and Hyperflows, plus decision tracking and diagnostic visibility. It does not establish action-specific employee-fulfillment mechanics; establish the target app, credential and workflow in a demo. [AI1]
Recovery claim has a different scope Vendor-claimed
Broad completeness and rollback language appears alongside change-management use cases. That is not evidence that every help-desk request is automatically reversible. [AI1]
Not established Unknown
A single execution-identity model, the approval gate, audit retention/export and task-specific reversal for your selected employee request are not established here.
What could rule it out
If an irreversible write needs a guaranteed recovery path, broad change-management rollback language is insufficient. Obtain the specific compensating action and its owner.
Ask to see, not just hear
Show one employee request end to end: invocation, connector credential, approval, safe failure, handoff and target-system record. Demonstrate recovery for that request only.
07 / Employee help desk + admin workflow authoring
Serval
Editorial fitEvaluate when you want published code-based fulfillment, either above your current ITSM or as a replacement service-management platform.
Published actions, not improvised writes Documented
Catalyst builds workflows such as Okta password resets or adding a user to a GitHub team. The employee agent can invoke published workflows but cannot edit them. Runtime is fixed TypeScript by default; teams can deliberately include LLM steps. Integrations use server-injected credentials within the team’s configured API scopes. [SV1][SV8]
Approval and identity boundaries Documented
Requester identity comes from the authenticated session. Configured approvals can use people, groups/quorums, managers or sequential steps. Self-approval is configurable and stays on for a single-approver step. The built-in Team Manager role grants approval override by default; other roles can be granted Override approvals. Holders can approve or deny the current step without being assigned approvers, and overrides are audited. Human approval is not a universal default. [SV1][SV2][SV4]
Execution evidence, not reversal Documented
Run history exposes step inputs, outputs and status; CSV/JSON export includes trigger identity, timing and success/failure details. Workflow publishing is versioned separately. Restoring code is not evidence that already-completed account or access changes are undone. [SV1][SV3]
Company context
Growth-stage startup: Serval announced a $150M Series C on October 29, 2026. The funding announcement is a dated company signal, not evidence of automation quality. [SV6]
Ask for the full quote
For automation-layer versus full-platform deployment, what is the pilot price, contract metric, included deployment work and charge for expansion or renewals? [SV7]
Not established Unknown
Connector-specific service-account versus delegated-user identity, log retention/immutability and compensating actions for partial failures still require confirmation. Reusable approval procedures are marked beta.
What could rule it out
New workflows default to organization-wide scope. Do not publish sensitive flows until scope, self-approval and override permissions are reviewed. The docs warn that Team Only Slack channels must contain the intended team because channel participants can trigger those workflows.
Ask to see, not just hear
Publish a low-risk access workflow with explicit scope and approval. Try a denied requester, withheld approval and an authorized override; inspect both target-system membership and exported run evidence. Test partial failure without assuming code restoration reverses side effects.
08 / Slack/Teams employee fulfillment
Console
Editorial fitEvaluate chat-native actions and controlled self-service against your identity, SaaS and device stack; separately confirm post-acquisition product availability.
Console describes app access changes, IdP group membership, device commands and IT/HR record changes from Slack or Teams. Its natural-language Playbooks collect inputs, route approvals and use configured API actions; unavailable answers can be escalated to a person. [CO3][CO5]
Checks outside the model Documented
The technical FAQ says backend logic checks configured approval requirements and approver identity/permissions against systems such as Okta before execution. MFA checks can be attached independently or alongside approval. Its security page describes requester-only action scope by default, with elevated scope for acting on others. [CO1][CO2]
Validate and record each step Documented
The execution FAQ describes checking outcomes such as group membership after actions and showing failed steps to operators. Actions, approvals and validations are recorded in an Activity Stream. This is vendor documentation, not a tested guarantee that every connector has equivalent validation or recovery. [CO3]
Company context
Startup-origin option: Palo Alto Networks announced on September 1, 2026 that it had acquired Console. Do not label it an independent startup or treat the announced Cortex direction as a delivered feature. [CO4]
Ask for the full quote
Can we still buy Console as a standalone IT help-desk product, and what are the pricing unit, minimum, migration commitments and post-acquisition support terms? [CO4]
Not established Unknown
Connector execution principals, least-privilege scopes, log retention/export and partial-failure compensation are not established by these pages. Confirm standalone licensing, support and roadmap after acquisition.
What could rule it out
Not an independent startup: Palo Alto Networks announced the acquisition on September 1, 2026. If independent ownership or a stable standalone roadmap is a requirement, resolve that before shortlisting.
Ask to see, not just hear
Configure a group-access action with an eligible approver and MFA. Try a non-approver, withheld approval and an on-behalf-of request. Inspect the denied target state, a successful group update and its Activity Stream; deliberately fail a downstream step.
09 / Chat-first IT support and Runbooks
Risotto
Editorial fitEvaluate a startup focused on employee IT support in chat, especially when Okta fulfillment and keeping your existing ticketing system are priorities.
Risotto’s Okta page lists access provisioning, group changes, MFA resets, account unlocks, expiring access and OIG workflow triggers from Slack. It says directory-synced groups are checked and protected from writes. These are connector-specific vendor claims, not our hands-on results. [RI1]
Approval is configurable Vendor-claimed
The Okta page describes role-based workflow eligibility and manager/admin approval settings. Its Runbook FAQ explicitly allows approval to be turned off. Require the actual backend permission and approval configuration rather than assuming every generated automation is human-gated. [RI1][RI2]
Run and authoring evidence Vendor-claimed
The Okta page claims logs in Risotto and Okta with requester, workflow, approvals, result and time. The builder page claims versioned Runbooks and records of creation, tests, changes and approvers. Log retention, export and reversal are not established by these pages. [RI1][RI2]
Company context
Startup provenance: Y Combinator lists Risotto as founded in 2023, Winter 2024 and active. This establishes an emerging-company option, not a measured growth rate. [RI3]
Ask for the full quote
Which Startup/Enterprise plan applies to our employee count, with what annual commitment, usage limits, integrations and implementation support? Price the overlay and native-ticketing scenarios separately. [RI4]
Not established Unknown
Execution credential and scopes, identity binding, enforcement outside the model, approval override behavior, retention/export and recovery from partial writes require implementation evidence. API/MCP support alone does not establish a maintained connector.
What could rule it out
If security needs documented enforcement mechanics before a pilot, the reviewed product pages are insufficient. Require a connector setup/permissions review and a denied-write demonstration, not a customer automation percentage.
Ask to see, not just hear
Request time-limited access to a low-risk Okta group. Withhold or deny approval, try an ineligible requester and a directory-synced group, then approve an eligible request. Verify grant and expiry directly in Okta and reconcile both systems’ logs.
ServiceNow completed its acquisition of Moveworks on December 15, 2025. They appear here as distinct product choices, not independent vendors. [C1]
A buyer-run protocol, not our results
Make the pilot prove the permission boundary.
Pick three recurring requests from your own ticket mix. Use a vendor-approved sandbox, synthetic people and non-production resources. Agree on the target state and pass/fail conditions before the demo starts.
Record the configuration
Product, release, plan, enabled modules and test date.
Employee or technician surface, channel and exact connector action.
Requester, execution identity, required approver and log-reader roles.
Expected final state, recovery owner and any irreversible step.
Keep the full bill visible
Request base licenses, required upgrades, AI usage, connectors, implementation and ongoing administration separately. Record retries, rework and human approval time.
Sessions, conversations, seats and confirmed resolutions are not interchangeable units. No price or savings ranking is established here.
Allowed request
Run the intended operation with the least-privileged production-like identity.
Pass evidence: inspect the target application independently. Capture who acted, what changed and the matching request/transaction identifier.
Denied requester
Repeat as a synthetic user who is not entitled to the resource.
Pass evidence: no forbidden read or write, an honest denial and a useful handoff. A refusal in chat is insufficient if the target still changes.
Rejected or stale approval
Withhold or reject approval. Then change the target or scope after an approval.
Pass evidence: no write without the required approval; changed parameters require the authorization your policy specifies.
Timeout and retry
Trigger a safe endpoint failure or partial completion, then retry.
Pass evidence: truthful status, preserved handoff context and no duplicate write. Demonstrate a compensating action or document manual recovery.
Transcript and audit access
Inspect the same records as an operator and a user with less access.
Pass evidence: appropriate readers only; required identity, time, parameters, result and approval evidence. Confirm retention/export separately.
Record each case as success, failure, partial completion, blocked or not run. Keep all attempted relevant cases in the denominator and name exclusions. A small scripted pilot evaluates that configuration—not the safety or success rate of an entire product.
Stop the purchase when a required control cannot be shown.
Examples: the connector cannot perform your exact operation; no one can name the execution credential; rejection still permits a write; the required approver is bypassed; retries duplicate provisioning; sensitive transcripts are too widely visible; or the only completion evidence is the agent’s own answer. An unresolved requirement is a blocker for that workflow, not a reason to invent a product-wide safety score.
The receipt
What we read. What we did not test.
This guide uses vendor primary sources. No product accounts were accessed and no requests, permissions or recovery paths were executed. Documentation can explain a mechanism; it cannot establish that it is enabled or effective in your tenant.
Source links beside each claim lead here. Dates below are actual source-check dates, not release or general-availability dates. Unversioned documentation may redirect to a different release later.
Technical/support documentation. Checked (UTC). Source revision date not established. Built-in actions; deflection is documented for supported account plugins, not every software action. Not a release-specific compatibility guarantee.
Technical/support documentation. Checked (UTC). Source revision date not established. Delegated OAuth for the supported HTTP connector, not all integrations.
Technical/support documentation. Checked (UTC). Source revision date not established. Built-in plugins only, not Agent Studio; excludes ingestion and authentication API calls. Collection starts on enablement; rolling one-week view, no backfill. Sensitive request/response visibility is role-dependent.
Technical/support documentation. Checked (UTC). Source revision date not established. Unversioned URL resolved to Brazil release documentation during review.
Technical/support documentation. Checked (UTC). Published or updated 2026-09-01. Brazil release; invocation permissions and execution identity/role filtering.
Technical/support documentation. Checked (UTC). Source revision date not established. Supervised/autonomous settings for this flow action, not all ITSM workflows.
Technical/support documentation. Checked (UTC). Source revision date not established. Jira Service Management virtual service agent; source flags feature rollout.
Product page / vendor claims. Checked (UTC). Source revision date not established. Vendor product claims; no action-specific implementation or test evidence.
Technical/support documentation. Checked (UTC). Source revision date not established. Mix of workflow descriptions, broad claims and adjacent ITOM/change-management uses.
Technical/support documentation. Checked (UTC). Source revision date not established. Step-level run inspection and CSV/JSON export; no universal reversal or fixed retention promise established.
Technical/support documentation. Checked (UTC). Source revision date not established. Organization/team roles and custom permissions, including audited approval overrides. Drafter rollout is gradual; built-in roles can be customized where enabled.
Technical/support documentation. Checked (UTC). Source revision date not established. New workflows default to org-wide; Team Only channel membership must be controlled. Scope describes invocation, not target-system delegated identity.
Company announcement. Checked (UTC). Published or updated 2026-10-29. Series C and company-reported growth only; not a product benchmark or independent revenue verification.
Vendor pricing page. Checked (UTC). Source revision date not established. Current page describes full-stack ESM or automation-layer engagements and a pilot-led proposal. No numeric public quote observed; do not reuse an older flat-fee description.
Technical/support documentation. Checked (UTC). Source revision date not established. Examples include Okta password resets and Okta-to-GitHub membership; review/test/publish process. Direct publishing versus review is team configuration, not mandatory independent review.
Technical FAQ / vendor documentation. Checked (UTC). Source revision date not established. Vendor explanation of backend-enforced approval and MFA checks, IdP-based approver validation and time-limited access. Requirements must be configured; not tested here.
Company announcement. Checked (UTC). Published or updated 2026-09-01. Completed acquisition announced September 1, 2026. Ownership evidence only; proposed Cortex benefits are forward-looking, not proof of current packaging.
Technical FAQ / vendor documentation. Checked (UTC). Source revision date not established. Natural-language Playbooks, preconfigured actions, API integrations, policy setup and human escalation. Does not establish support for every external operation.
Product page / vendor claims. Checked (UTC). Source revision date not established. Connector-specific vendor claims: group/access actions, MFA checks, directory-synced group protection, request approval and dual-system logging. No setup schema or execution principal disclosed.
Product page / vendor claims. Checked (UTC). Source revision date not established. Vendor claims for natural-language Runbooks, API/MCP tool connections, versioning and logs. FAQ says run approval can be switched off; do not describe all runs as obligatorily human-approved.
Investor company profile. Checked (UTC). Source revision date not established. YC Winter 2024, founded 2023, active status. Startup provenance only; team-size field may be stale and is not used.
Vendor pricing page. Checked (UTC). Source revision date not established. Published Startup and custom Enterprise packaging; existing-ITSM overlay or native ticketing. Reconfirm employee cap, billing commitment, inclusions and usage allowances; no price copied into guide.
Vendor release notes. Checked (UTC). Source revision date not established. July 18, 2025 entry documents change-approval history and a workspace setting that permits requester self-approval by default; disabling it prevents self-approval. October 9, 2026 adds cancelled approval outcome. Applies to stated features, not every AI tool policy.
Vendor release notes. Checked (UTC). Published or updated 2025-02-05. Request Activities workflow logs: action inputs/outputs, third-party API calls and retries. Historical release evidence, not proof that all AI Coworker tool calls share this log.
Company announcement. Checked (UTC). Published or updated 2025-01-28. Company states founded in 2022 and announced Series A on January 28, 2025. Startup provenance, not verified revenue growth.
Vendor pricing page. Checked (UTC). Source revision date not established. Current usage-based and outcome-based plans; existing ServiceNow/JSM overlay or full platform. Dollar amounts omitted to avoid unscoped price comparisons.