The friction was doing part of the reviewing
ServiceNow's write-up of the reworked AI Agent Studio, posted on the ServiceNow Community by Victor Chen, describes a short path from idea to running agent. Agent Advisor mines instance data for opportunities, shows the records it analysed with an estimate of time and cost saved, generates resolution steps, and offers single-click agent creation from there. The stated aim is to compress time to first agent for technical and non-technical builders alike.
The build experience sounds good, and the review discipline around it needs writing down now, because the old friction was doing part of that job. When creating a ServiceNow agent meant cloning a shipped one, adding each tool on a separate screen, and finishing the build before a test could start, someone usually asked what the agent was for and who owned it during the wait. On one screen with one click, those questions get asked only if someone decided in advance to ask them.
Ask which records Agent Advisor counted
The post says Advisor displays the analysed records next to the estimated savings. Our first review question is whether those records are the ones you would have chosen. An opportunity mined from incident history reflects categories and assignment groups as they were recorded. Most instances carry a catch-all category, a couple of groups that reassign everything they receive, and resolution notes that say fixed. The generated steps inherit all of it.
Before the click, open the analysed set as a list and read twenty records with the lead of the group that will own the outcome. If Advisor's generated steps match what that group does on a busy afternoon, you have a candidate. If they match what the knowledge article says the group does, you have a knowledge article to fix first. The same rule applies to configuration items, which we covered in what a CMDB needs before an agent reads it.
Read the node canvas for writes, then for identity
The post describes the whole agentic solution as an interactive node map, with tools and agents added or removed without leaving the view. For a reviewer that is the most useful thing in the release, because one picture shows everything the agent can call. Read it twice. The first pass is for which nodes write, and to which tables. The second is for whose identity each call runs under and which roles that identity carries.
The post does not describe how role checks apply node by node, and that is the question we would put on the review sheet. A tool that creates a change request under a service account holding more roles than the requester is an escalation, however tidy the canvas looks. We made the same point about ServiceNow's MCP servers running on your existing roles and ACLs, and it holds when the tools are drawn as nodes.
Decide what the test panel proves
Side-by-side build and test is the change teams will use most. The post says builders no longer finish the build before testing. They open a test conversation panel next to the configuration, run interactions, and iterate straight away. That loop catches prompt problems and obvious tool mistakes early.
What it cannot tell the reviewer is how the agent behaves on the records nobody typed into the panel. So the question is which test cases exist in writing, outside the builder's head. We'd want a short set: the three most common incident shapes for that group, one request the agent should decline, one where the requester lacks the role, and one where a tool call fails partway through. The post lists auto evaluation among upcoming features, which suggests ServiceNow sees the same gap. Until it ships, the test set is yours to write, and our agent readiness check is a fair place to start.
Extending a shipped agent moves the upgrade question
The post says builders can add or remove agents and tools on out-of-the-box agents to change their behaviour without cloning. That direction is the right one. Cloned agents are how an instance ends up with four versions of the same resolver and nobody sure which is live. The review question has moved rather than disappeared, though. It is now what you added to the shipped agent, and what happens to those additions when the shipped agent changes on the next patch.
Record the additions somewhere other than the canvas. A short note on the agent record, or in the update set description, listing each added tool with why it was added and who asked, is enough. The post also says chat and voice agents are configured as distinct types from the start. An extension made to a chat agent is therefore a chat decision, and the voice version gets its own review.
Write the page before the patch lands
The post puts general availability at Zurich Patch 13, Australia Patch 6, and Brazil EA1 and above, with the Otto AI Agents plugin at version 9.0.8 or later. If your instance sits behind those levels on September 4, you have a window before the one-click path arrives, and that window is the time to agree the review page with whoever runs platform governance for you.
One page beside every agent created from an Advisor opportunity: the owner, the records Advisor counted, the nodes that write and the identity they run under, the test cases that exist in writing, anything added to a shipped agent, and where the pause control sits. It costs the builder an afternoon. Take it to the next agent design review and find out which question the builder cannot answer yet.
