- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 hours ago
AI Agent Advisor reads the records your teams have already closed, groups them into recurring problems, estimates what each one costs you, and matches it to agents and tools that already exist on the platform. This guide covers what it does, what it needs before it will run, how to read what it produces, and the issues that come up most often.
Choosing what to automate first usually takes weeks of workshops and produces a shortlist nobody can defend with numbers. AI Agent Advisor answers the same question from your operational data instead, and it answers three things:
AI Agent Advisor lives inside what used to be called Now Assist Center, now AI Admin Center. Documentation and older articles use both names. Same application, new label.
AI Agent Advisor generates candidate agents from raw data. Whether that becomes a real roadmap or a pile of duplicate, poorly named agents depends entirely on whether someone reviews each opportunity before it becomes a build. Every opportunity is a candidate requiring review, not a decision already made.
AI Agent Advisor is for discovering where to start with automation. Process Mining is for diagnosing why an existing process is underperforming.
Out: intent clusters
Out: solution blueprint
Out: draft AI agent
Matching runs primarily on tools—the specific capabilities each agent exposes—because agent descriptions tend to be broad. Agent proficiency descriptions are a secondary signal. Each resolution step is matched to the most relevant tools first, then the agents those tools belong to are surfaced.
Three consequences:
Run against a clone with representative data to replace weeks of discovery workshops, and to verify that the out-of-the-box tools serve your organization.
Run against a clone of production to get a prioritized automation backlog within hours, and start agent creation from generated drafts rather than a blank form.
Review results regularly to identify new opportunities as your data shifts. Feed output into adoption plans and roadmaps, then re-run and compare coverage over time to track improvement. This is the window most teams skip.
Everything that has to be true before a run will succeed. The most common cause of a failed analysis is a condition in this section that nobody checked.
Patch and application dependencies change between releases. Check the required applications table in the troubleshooting guide for current values rather than relying on a version number in any article, including this one.
Access problems are almost always a single missing role.
sn_na_center.nac_adminsn_na_center.adminor
sn_na_center.usersn_agent_miner.app_adminagent-miner-svc-account user for executions to run. Also the role to extend to provide access to more tables.The third sits on a service account rather than on a person, which makes it easy to overlook. If executions never start, check it first.
Two conditions gate everything, and together they explain most failed runs.
Any table derived from the task table is supported, including custom tables and custom fields.
If you cannot assemble 500 qualifying records with populated work notes, that result is information rather than a dead end. It indicates that record-keeping practice needs attention before agentic automation will land well anywhere, which is a more valuable conversation to have early than a list of opportunities would have been.
AI Agent Advisor runs automatically once installed, and then again every 90 days. An Execute Now button on the settings page runs it immediately.
The setup form is a single page covering the table and fields to read, the run frequency (30, 60, or 90 days), a record filter, and the savings inputs. The product documentation covers the walkthrough in full, so rather than repeat it, here are the four things worth knowing that the documentation does not emphasize:
Execution progress displays stage by stage, and a failure at a given stage points to a specific class of problem. This makes the progress panel the fastest diagnostic available, and it is not documented elsewhere.
Stage one expands into six sub-checks—skill licensing, raw data, filtered data, data with ACLs, point-of-view extraction, and machine-learning solution table access—and each carries a Detail message explaining what it found. When a run fails, open the chevrons and read which check stopped rather than guessing. Note that the raw, filtered, and access-controlled record counts are verified separately and each can be smaller than the one before it, so the remedy depends on which of the three actually stopped.
Review the opportunities using the signals in section 4, then hand off. The path depends on solution type:
The handoff pre-populates the agent; it does not lock it. You still own triggers and channels, security controls, instruction refinement, naming against your own standards, any step flagged as unmatched, and evaluation. You will also need to decide whether the agent communicates over text chat or voice—voice agent tools are included during matching, and Voice Agent is available as an option when you generate.
Install before you generate. Matched tools are only added if the associated agent is installed. If the opportunity page prompts you to install an agent and you proceed without doing so, the tool will not be added.
Editing a step re-runs the opportunity. The interface states it directly. Read the example records, decide every change you want, and apply them together rather than adjusting one step at a time.
When an agent is generated, a dataset is also created containing all the records identified as having an intent matching that opportunity. Open the automated evaluation tool and the dataset is already selected, so no manual preparation is needed. This lets you validate that the agent resolves the tasks that triggered the cluster in the first place, using real records, before committing to a production deployment.
The strongest opportunities are recurring, repeatable problems. The weakest ones can look identical in the list, so this section is about telling them apart.
Each row carries the generated name, its status, the solution type, the source data source, estimated annual cost and time savings, an estimated deflection rate, and the total issue count. Two of those columns do most of the work: Solution type and Total issues.
A shipped agent already covers this. Install, review, and activate. Lower effort and lower risk, and the natural place to start.
Nothing off the shelf covers it. AI Agent Advisor has produced a specification, but the build is yours. Higher effort, and where the design work sits.
A list dominated by custom entries tells you your recurring problems are specific to your organization. That changes the work from adoption to development, and it should change your estimate.
ServiceNow's guidance on sequencing is direct: focus on the opportunities with the greatest volume of records for the highest return. Volume indicates how frequently an issue has occurred, and therefore how much of it is left to automate.
Opening an opportunity gives three tabs: the resolution steps, the example records behind the cluster, and the matched agents. Each step shows its matched agent or tool, a confidence score for how well it fits, and an explanation of why that match was selected. Together these are what let you overrule a match intelligently rather than on instinct.
Treat a low confidence score as mandatory review, not automatic rejection. The match may well be right, and the explanation will usually tell you whether it is. A zero on the matched agents tab is similarly informative rather than broken—it means no existing agent covers this and you are looking at a genuine custom build.
Review the example records within a cluster to confirm the generated intent accurately represents the record group. A cluster driven by an outage, a seasonal spike, or a single bad release can show high volume without representing a recurring pattern, and it will sit high in the list looking like a strong opportunity.
If the records read like the same problem happening repeatedly for the same reason, it is a real candidate. If they cluster around one date range or one root cause since fixed, it is not.
Nothing is lost by leaving an opportunity alone. It stays in the list and keeps resurfacing on subsequent runs, with its record count growing as more matching records accumulate. That growth is a signal in itself: a problem climbing the list over successive runs is getting worse.
Re-running does not simply append to previous results. Each run reflects the current state of your data, so an opportunity you have addressed should shrink or disappear as those records move out of the window, while new patterns appear alongside whatever remains open. Deprioritizing is therefore a cheap, revisitable decision, and you do not need a separate register of rejected opportunities.
The Savings projections panel takes two inputs, each with a recommended range shown inline: hourly labor cost in USD (recommended 15 to 30 per hour) and active handling time rate (recommended 10% to 25%), the share of a record's total open time actually spent working on it. The formulas are stated in the interface:
Estimated time saved = Active handling time rate x Total open hours
Estimated cost savings = Total open hours x Active handling time rate
x Hourly labor costThe panel shows a worked example: for 10,000 total open hours at 10% and 15 per hour, that is 1,000 hours and 15,000.
The input is total open hours, not record count. Two opportunities with identical record volume produce very different savings if one sat open for days and the other closed within the hour.
So a low-volume problem whose records sit in a queue for a long time can outrank a high-volume problem that gets closed quickly. Neither ranking is wrong—they answer different questions. But if you read a savings figure as a recurrence measure, you will mis-sequence your backlog. Read Total issues as a separate signal.
These values are defaults until you change them. Take the time to tailor them to your organization. The active handling time rate is the one most often misread: it is a share of open time, not an estimate of minutes per record, and moving it from 10% to 25% multiplies every figure on the page by two and a half.
Abstract guidance on clustering is hard to act on, so here is what a strong result and a weaker one look like side by side.
A service desk has 1,400 closed incidents over the last quarter, loosely tagged under access issues. Mine clusters 340 of them into a tight group. The intent comes back consistently as a user locked out after password expiry, and the resolution steps in the work notes are near-identical across the group: verify identity, trigger a reset, confirm access restored.
Match maps that cluster almost entirely to the existing tools on an out-of-the-box agent covering password reset, with a high confidence score on each step. High volume, near-complete match, low build effort—a strong first candidate.
Now the contrast. A second cluster holds 60 records around a niche vendor-integration failure, and three of five resolution steps come back unmatched. Same analysis, same run, very different verdict: fewer records and substantially more to build. Still a legitimate opportunity, just a later one.
Those two clusters sit in opposite corners of the same grid. Two variables decide where an opportunity belongs: how often the problem recurs, and how much of the solution already exists. Read Total issues for the first and Solution type for the second.
(custom build needed)
(pre-built available)
The data source is marked Failed to generate, and stage one reads Checking instance readiness - Failed pre flight checks with no later stage started.
The submission itself succeeded—you may even have seen a confirmation that the mining job was submitted—but the run stopped before any analysis began. Expand the sub-checks to see which one failed, and use the Learn more link on the panel. Most commonly this is record volume, so check the filter's record count first.
The filter panel shows Number of records found: 0, and every run for that data source fails.
The filter is not matching anything on that table. This happens most often when a condition set is reused from another data source: state values and field names differ between tables, so a filter that returns thousands of records against one table can return none against another. Rebuild the conditions against the table's own values and confirm the live count before saving.
The run fails early, or the record count is below 500.
The minimum applies to the records inside your filter, not the records in the table. A filter scoped to a short recent window on a low-volume table will fail even when the table itself holds far more. Configure the record filter to increase the number of included records, and confirm the records have populated work notes or comments—volume alone is not sufficient. See KB3144183.
Every readiness sub-check passes green, then the run stops at Analyzing root causes and intents with an extraction error naming the POV extractor and a record count against the 500 minimum:
Analyzing root causes and intents - Error: [PovExtractor] execute ::
Extraction failed Error: Check POV records with mandatory fields failed.
147 out of 4930 records have mandatory fields issue (minimum required: 500).
Check data quality or modify mandatory fields configuration.This is the most instructive failure in the product, because it shows that passing pre-flight is not the same as having extractable data. All six readiness checks cleared, including the POV Extraction Check, and there are nearly 5,000 records in scope—yet extraction still could not assemble 500 usable ones.
The cause is field-level rather than volume-level. Records are present, but the fields extraction depends on are not adequately populated across enough of them. The message names both remedies itself: check data quality, or modify the mandatory fields configuration. In practice that means confirming that the free-text fields selected on the data source are genuinely filled in across the record set, and reconsidering the field selection if they are not. A table where most records carry a short description but little else will produce exactly this error.
Note that the count in the message is reported against the 500 minimum, so read that figure rather than the total in scope—the total tells you nothing useful here. KB3144107 covers extraction failures, and KB3144108 covers the closely related case of extraction returning too few records despite a large source set.
The run stops at Creating automation opportunity groups.
Readiness and extraction passed, so the clustering step itself could not form groups. Start with record volume and narrative quality inside the filter. The error message is generic, so the useful detail is in the execution logs on the settings page. KB3144186 covers this specifically.
A run displays In progress indefinitely and new runs will not start.
Only one execution can be in progress at a time, so a stuck run blocks everything behind it. KB3144105 documents the supported cancellation procedure. Two points from it are worth knowing in advance: the execution record's status must be set to Failed or new executions will not trigger, and the interface may continue to display In progress until the execution summary is updated as well.
A custom AI agent opportunity opens, the tabs and the step controls render, but the resolution steps themselves sit on a loading indicator and never appear.
The opportunity exists and its example record count is populated, so the cluster was formed; it is the step content that is not returning. Re-running the mining job for that data source is the practical first move, since it regenerates the opportunity and its steps. If the steps still do not load after a clean run, capture the opportunity and raise it with Support rather than continuing to re-run.
All stages complete, empty results.
Typically extraction returning nothing usable despite a healthy raw record count. The records exist, but no usable content came out of them. Review narrative content quality and the fields selected on the data source. See KB3144189.
The run reaches Matching AI Agents and stops.
Matching depends on AI Search. Either it is not enabled or indexing has not completed. Confirm both before re-running rather than retrying blind. Indexing that never completes is documented separately in KB3144192.
A tool visible in the match results is not attached to the generated agent.
The source agent is not installed. The platform flags which agent is needed. Once it is installed you can return and add the tool to the generated agent manually.
A pre-built opportunity looks ready, but the activate button is disabled.
The required plugin is not installed, and a banner above the agent card says so with a link to Application Manager. Install the plugin and return to the opportunity.
No option to add another task-derived table as a data source.
Support for all tables derived from the task table requires application version 1.3.2. If that version is not available to upgrade to, move to the latest patch version for Zurich or Australia and try again. See KB3144102.
AI Admin Center opens but the AI Agent Advisor configuration does not.
Check sn_na_center.nac_admin first. If executions are failing rather than the interface, check sn_agent_miner.app_admin on the service account instead. See KB3144098.
Error logs are on the AI Agent Advisor settings page. Review the troubleshooting guide first; if the answer is not there, log a case with Support. The full article list is in section 7.
The return does not come from building the agent. It comes from how much that agent actually gets used against a real, recurring problem.
An agent built against a one-off spike has a ceiling on its value however well it is tuned, because there is nothing left to automate once the spike passes. An agent built against a genuinely repeated operational problem keeps paying out every time that problem recurs. That is why picking the right use case matters more than almost anything else in this process—and it is exactly the job the volume ranking is doing, surfacing problems that keep happening rather than ones that happened once and got noticed.
Once you have picked a real recurring pattern, the built-in savings estimate is a reasonable number to prioritize with. It is not the number to present as final, because it is driven by whatever inputs were left in the savings panel.
Take the 340-record password-reset cluster from the worked example in section 4. Suppose those records sat open for an average of ten hours each—3,400 total open hours. At a 10% active handling time rate, that is 340 hours a year, and at a loaded cost of 30 per hour, roughly 10,200. A useful sanity check falls out of that arithmetic: at a ten-hour average open time and a 10% rate, you are claiming about one hour saved per record. If that does not sound plausible to the people who work these records, the inputs need revisiting before the estimate goes anywhere.
That is a meaningful, defensible number once your own figures are in. But value scales with usage, not with the estimate. The more the agent is actually invoked against that same recurring pattern, the more the figure compounds. The estimate at discovery time is a projection of that; it is not proof of it.
A few things worth doing once an agent from this process goes live:
An agent that gets built, evaluated, and then never checked again is a sunk cost with an unproven claim attached to it. An agent tracked against the original opportunity—same records, same baseline, real usage data—is the difference between a project and a repeatable practice.
That tracking discipline compounds beyond the agent itself. The more consistently you can show what the last opportunity actually returned, the easier it is to justify prioritizing the next one—which is what turns a sequence of individual builds into a programme with its own momentum.
This is a generative AI capability and its output is probabilistic. Clusters, intents, resolution steps, and estimates are all evidence to be reviewed by people who know the work, not conclusions to be deployed. Keep a person in the loop, particularly where the automation touches something consequential.
AI Agent Advisor tells you what to automate and how much of it already exists. Whether the estimate it produces is reliable enough to act on is a judgment made at discovery time, and it stays a judgment unless someone keeps measuring after go-live.
It answers the first question in an AI programme: where do we start? It answers it from evidence rather than opinion, and it produces a draft agent and a test dataset along the way. It does not answer the second question—whether what you built actually works. That is the evaluation loop, and the dataset AI Agent Advisor generated is where that loop begins.
Your data already indicates what to automate first. This is how you ask it, and the review you do afterwards is what makes the answer worth having.
Support for GCC and for domain-separated environments differs from standard instances. Confirm the current position with ServiceNow before planning a deployment in either, and check the availability documentation for regulated and self-hosted environments.
AI Agent Advisor follows the same data-handling model as other Now Assist capabilities: prompts and responses are processed in memory rather than stored in ServiceNow data centers, and temporary data is discarded once the interaction concludes. Data sharing for model improvement is a separate, optional programme with an opt-out available in Now Assist Admin.
Detailed architecture, data flow, and regional processing specifics are published in ServiceNow Support articles, which require Support access to view. The Now Assist Responsible AI, Data Handling and Security article is the index to them. If data residency or retention specifics bear on your compliance position, review those articles at the start of a deployment and raise anything they do not cover with Support.
- 73 Views
