ServiceNow's AI agents triage tickets but wait on set guardrails

The setup

ServiceNow's Now Assist product page, preserved by the Wayback Machine from a November 2025 snapshot after the page's original URL stopped resolving, describes Now Assist as generative AI built directly into the ServiceNow AI Platform rather than a bolt-on tool. Its own account of setup is a guided one: the page states summarization for cases, chats and incidents is configured through a guided setup in the Now Assist admin console, which an administrator runs rather than an end user. A related AI agents page, from the same archived snapshot, adds that a separate AI Agent Studio lets an admin build and customize AI agents, including setting guardrails, through a natural-language interface.

What the documents show

The AI agents page states directly that a team might configure agents to triage cases or categorize incidents, naming specific IT-service-management tasks the agents can be pointed at, and describes an AI Agent Orchestrator that coordinates multiple agents working toward a shared goal rather than one agent acting alone. The Now Assist page frames the same capability at a company level, stating that teams of ServiceNow AI agents can work around the clock to resolve IT incidents or customer support tickets, a description of intended capability from ServiceNow's own product marketing rather than an independently measured resolution rate.

The friction

The same Now Assist page discloses the intended limit on that autonomy in the same breath as the capability claim: it states a customer remains in control by setting the guardrails for ServiceNow AI Agents and specifying when their actions require human approval. That puts the actual boundary between automatic resolution and required escalation in the hands of whoever configures the guardrails, not in a fixed rule ServiceNow states itself, and neither archived page discloses a default position — such as which actions require approval before any admin configuration — for a workspace that has not yet set one.

What changed in the work

The documents support a claim about IT ticket handling specifically: a routine incident or category of request that previously always reached a human queue can instead be triaged or resolved by an agent, with the vendor's own material describing the remaining human role as defining, in advance, where the line sits rather than reviewing every ticket after the fact. The editorial read is that this shifts an IT team's setup work from staffing a queue to writing the guardrail rules that decide what the queue even sees, which is not documented here as easier, only as different.

• What guardrails has this workspace's admin console actually set, versus what the platform defaults to before configuration?
• Which categories of incident are explicitly excluded from agent triage, and who decided that list?
• Is a claimed resolution capability describing what the product can do, or what this specific deployment has been configured to allow?

A platform that puts guardrail configuration in an admin's hands, rather than shipping a single fixed policy, moves the friction earlier in the process — into a setup decision instead of an in-the-moment override.