Blog/ServiceNow Virtual Agent vs. Custom AI Agents: When the Built-In Tool Isn’t Enough
ServiceNowVirtual AgentAI AgentsIT Automation

ServiceNow Virtual Agent vs. Custom AI Agents: When the Built-In Tool Isn’t Enough

July 4, 20266 min readBy Brad McCorkle, Founder & CEO, Lesos AI

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.

What ServiceNow Virtual Agent Actually Does

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.

  • Topics are built and tested in Conversation Designer, one intent at a time
  • NLU models are trained per topic to catch phrasing variants of the same request
  • Virtual Agent is bundled with the ITSM, HRSD, and CSM product lines rather than sold as its own line item
  • Full NLU sits behind Pro Plus and Enterprise Plus licensing; Virtual Agent Lite ships without it
  • ServiceNow does not publish list pricing for Virtual Agent; every quote is instance-specific

Where It Hits a Wall

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.

  • No automatic learning from conversation logs; every gap requires manual topic authoring
  • Reporting is thin, mostly conversation counts and containment rates rather than root-cause analytics
  • Existing ACLs and business rules still apply, so a flow that works in a dev instance can get blocked in production by stricter roles or approval requirements
  • Cross-system logic, pulling from Microsoft 365, Azure AD, or a custom app, still requires separate Flow Designer or IntegrationHub work the bot cannot do inline

Now Assist AI Agents Change the Picture, Sort Of

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.

What a Custom AI Agent Adds

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.

  • Understands intent from natural language instead of requiring topic-by-topic phrase matching
  • Executes multi-step actions across ServiceNow and Microsoft 365 in a single flow: verify identity, reset a password via Graph API, update the ticket, close it
  • Improves with better prompts and examples instead of manually rebuilt conversation topics
  • Runs at whatever risk tolerance you design into it, since you control the logic instead of relying on a vendor’s orchestration layer

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.

The Real Cost Comparison

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.

When to Stick with Virtual Agent, and When to Build

  • Stick with Virtual Agent if your ticket types are few, phrasing is consistent, and you have staff who can maintain topics over time
  • Build custom if you’re chasing tickets with inconsistent phrasing, need actions across M365 and ServiceNow in the same flow, or have plateaued below 30% deflection
  • Consider a hybrid: keep Virtual Agent’s chat surface for simple FAQ traffic, and put a custom agent behind it for anything that needs real system actions

Frequently Asked Questions

Can I replace Virtual Agent entirely with a custom agent?

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.

Does a custom AI agent still have to respect ServiceNow permissions?

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.

Stuck Below 30% Deflection?

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 Works

How AI-ready is your organization?

Free 2-minute assessment. Get an industry-specific score and action plan — no call required.

Get My Readiness Score