ServiceNow Virtual Agent is the platform’s built-in conversational bot: a topic-and-NLU engine that resolves scripted requests, like a password reset or an order status check, inside the Now Platform. It handles narrow, well-defined intents reasonably well. It stalls on tickets that need judgment, multi-system context, or language it was never trained on, which is exactly where a custom AI agent built on a large language model earns its keep.
I’ve configured Virtual Agent topics for clients who use it exactly as ServiceNow intended: build the intent, wire the topic to a workflow, ship it. That works right up until a user types something the NLU model has never seen, or the ticket needs data pulled from Microsoft 365 and cross-referenced against three ServiceNow tables. At that point the conversation dead-ends into "let me connect you to an agent," and the ticket lands back in a human queue anyway.
This post breaks down what Virtual Agent actually does, where it runs out of road, and when the cost of building something custom is worth paying.
Virtual Agent is a chat interface backed by Conversation Designer, ServiceNow’s low-code, drag-and-drop tool for building conversation flows called topics. Each topic is trained with an NLU model that maps phrasing variants, "reset my password," "I’m locked out," "can’t log in," to the same intent, then routes to a scripted flow that does the actual work.
The honest baseline for an out-of-the-box Virtual Agent deployment is under 15% deflection. Practitioners who’ve run it for years compare training it to teaching a child to speak: it needs constant correction, and it never generalizes past what you’ve explicitly taught it.
Virtual Agent does not learn from the conversations it has. Every gap you spot in a chat transcript has to be manually turned into a new topic, tested, and deployed. Teams that skip this maintenance cycle end up with a bot that plateaus around 20% deflection and stays there.
ServiceNow’s newer Now Assist AI Agents are a different product from the conversational Virtual Agent: they’re agentic, meaning they can take multi-step action rather than just route a chat. That’s closer to what a custom agent does. But the same platform constraints show up. Each agent runs with a 128K token context window, and ServiceNow’s own field guidance recommends keeping the agent count in a single use case to around 10 or fewer, since orchestration clarity degrades past that. Pricing has also shifted to consumption-based billing, so messy source data now shows up directly on the invoice instead of just in a CSAT score.
A custom agent built on an LLM reads a ticket the way a person would instead of matching it against a curated topic list. "I forgot my password," "my account is locked," and "need a password reset" all resolve to the same action without anyone authoring three separate topics for them. We covered the mechanics of one version of this in our guide on how to automate password resets in ServiceNow, but the pattern generalizes to any ticket type with predictable resolution steps and inconsistent phrasing.
We wrote a longer breakdown of the build versus buy tradeoffs for IT automation generally in our IT support automation guide. The short version, specific to Virtual Agent: it’s a reasonable starting point and a low ceiling.
HDI and MetricNet benchmarks put the fully loaded cost per ticket at $6 to $40+ across North American enterprises, with a median around $22. At 40% deflection on 50,000 annual tickets, that’s 20,000 tickets avoided, or roughly $440,000 saved a year at the median cost.
The gap is in how you get to that deflection number.
Mature Virtual Agent deployments reach 45 to 60% deflection, but only after significant tuning investment; one organization we reviewed went from 35% to nearly 60% only after a dedicated round of Now Assist tuning work. Implementation cost for an enterprise Virtual Agent rollout commonly runs 3 to 5 times the annual license cost in professional services and configuration alone.
Custom agent projects usually skip most of that services line. The logic lives in a small set of prompts and API calls instead of dozens of hand-built topics, so there is less to configure and less to maintain as ticket patterns shift.
Technically yes, but it’s rarely worth the switch. Most teams keep Virtual Agent as the chat surface users already know and route the ticket types it can’t resolve to a custom agent working behind the scenes.
Yes. Business rules, ACLs, and approval requirements apply regardless of what triggers the action. A custom agent still needs a scoped application with the right roles, the same as any other integration.
Support Team plugs into your existing ServiceNow and Microsoft 365 stack and resolves the ticket types Virtual Agent can’t, without rebuilding a single conversation topic.
See How It WorksFree 2-minute assessment. Get an industry-specific score and action plan — no call required.