What's new in ServiceNow Otto for Creator
September 2026 store release, with Brazil Early Availability following on September 24
Overview
The September store release is available now on Zurich and Australia. Brazil Early Availability has moved to September 24, so the two features that need it arrive later this month.
The August release was about Build Agent fitting the way your team works. This one is mostly about it already being there: no manual upgrades, ServiceNow IDE folded into Studio, and a way into Studio from the platform pages you were already on.
Brazil Early Availability is covered at the end, if that is the part you are waiting for.
Table of contents
- Upgrades happen without you
- Studio changed shape
- A route into Studio from the platform
- Playbooks
- Also in this release
- Coming September 24: try Build Agent with nothing to install
- Coming September 24: Autonomous Engineer
Available now on Zurich and Australia
Brazil instances get these too when Brazil Patch 0 arrives on September 24.
Operations
Upgrades happen without you
What's shipping: Instances running Brazil Patch 0 or later, Australia Patch 5 or later, or Zurich Patch 12 or later, with Build Agent installed now receive new versions automatically when they are published to the ServiceNow Store.
Why it matters: Build Agent ships monthly, so keeping current meant a manual Store install every month. In practice, most instances ran whatever version they installed once.
What this means for you: On a qualifying instance, new versions arrive on their own.
Worth knowing
The Build Agent app is what auto-upgrades. The ServiceNow Otto for Creator package installed over it does not, so a paid install still has a piece you manage by hand. And upgrades run on a scheduled job, so an instance can take up to a day to land a new version.
Experience
Studio changed shape
What's shipping: ServiceNow IDE is now part of ServiceNow Studio. Two surfaces became one. Build Agent also runs faster in it and keeps context across conversations.
Why it matters: Studio and the IDE overlapped, and which one you opened determined what you could access. Pro-code work meant the IDE. Anything else meant Studio. Anyone doing both kept two windows open.
What this means for you: Your Build Agent history is one click away and persists, so picking up Tuesday's work on Thursday doesn't mean re-explaining it. If you were in the IDE, your work is now in Studio, next to the metadata editors. If you were in Studio, the source files are there too. Nothing to switch to.
The layout changed with it. Studio opens on a prompt box, with the model and mode pickers right there and cards underneath for your recent apps, recent chats, and plans in progress. A rail of icons runs down the left, and the top one is Conversations. Open it and your Build Agent history is there: a New conversation button, your plans, then every past conversation with how long ago you touched it. It reads like any chat tool you already use.
The same rail holds the rest of Studio. Apps opens the tree for whatever app you are in, grouped by Automation, Data, Integrations, Server Development and User Interface, each with a count of what sits underneath. Search, Files and Collections are below it. Collections is what Bookmarks became, and it groups apps, files and lists into folders you can organize by story, epic, or whatever the work actually is.
Source control tracks changes and deployments together now, so you can see what changed, compare versions, and move work between environments from one place. You'll get a guided tour of some of the changes to ServiceNow Studio as you access it after your upgrade your instance and plugins.
Worth knowing
The panel names changed too, so runbooks and training material with screenshots are stale.
ServiceNow Studio has converged with ServiceNow IDE and can toggle to use Autonomous Engineer.
Access
A route into Studio from the platform
What's shipping: An Open in Studio entry point now appears in four places on any table that extends sys_metadata.
Why it matters: You are on a Business Rule form, or in its script editor, and the next thing you want is Studio. There has been no way to get there in context, so it meant navigating to Studio separately and finding the record again.
What this means for you: One click from where you already are, and Configure menus land you on the right filtered list for what you were looking at.
- On the form itself, so a Business Rule, Client Script or UI Policy record opens in Studio directly
- In the script editor toolbar, for tables that use it
- In the form's right-click Configure menu, where Business Rules, Client Scripts, UI Policies, Table, Dictionary, Security Rules, Notifications, Flow Designer Flows and All each open the equivalent filtered list in Studio
- In the same set of items on any list's Configure menu
These sit alongside what you already use, so nothing you rely on moves. You need access to ServiceNow Studio for them to appear, and both an instance property and a per-user preference can switch them off:
glide.ui.open_in_studio_button.enabledThe checks run asynchronously, so this does not slow down form load.
Any of the configure options will open in Studio
Coverage
Playbooks
What's shipping: Six changes to what Build Agent can do with playbooks.
Why it matters: A playbook is not one record. It is a process definition plus its stages, its activities, and the wiring between them, spread across a lot of records. Generating the pieces and leaving you to connect them is not much of a saving. And if a playbook cannot express a conditional step, or a stage that only one team can advance, you end up building two or three playbooks to cover what should have been one.
What this means for you: A generated playbook arrives closer to finished. One update set file means you review, version, and promote the whole thing as a single object.
- Consolidate all records for a playbook into a single XML update set file
- Generate runtime permissions at the playbook level and the stage level
- Generate and configure the Set Playbook Outputs activity for nested playbooks
- Configure agentic fields on form-based and record-based activities, when the AI Agent plugin is active
- Generate on-demand playbook launcher configurations
- Define activities as optional
Optional activities and stage-level permissions are the two that change how you model a process at all. A workflow that branches by condition, or hands off between teams, is one playbook now. It used to be two or three.
Requirement
The agentic fields work only applies when the AI Agent plugin is active, so check that before you ask for it.
Also in this release
Smaller changes, roughly in order of how many people they touch.
- Three more metadata types. Build Agent can now work with Service Catalog dependent questions, transition conditions, and UI styles. The catalog one is the useful one: a variable can reference another variable, so a generated catalog item can narrow later questions based on earlier answers. That dependency wiring is most of the work in building a catalog item anybody would actually use.
- Parameterized ATF tests. Pass a data set to a test step and the test runs once per row. No more near-duplicate tests per scenario.
- ATF test suites. Group tests and run the suite in one go, with status and any errors reported back in the chat panel.
- List step coverage. Test Agent can now generate tests that use list and related list steps, including validating related list visibility and applying a filter to a list. Generated coverage had been form-shaped, which left the list view untested even though plenty of configuration shows up there.
- A configurable activity bar. Choose which panels show in Studio and hide the rest.
- Domain separation. ServiceNow Fluent supports domain separation on records and APIs. Set the
sys_domainfield, usesys_overridefields, and generated apps behave correctly in a domain-separated instance. There are edges, below. - Box MCP server. Box joins the MCP servers Build Agent can connect to. Setup runs through Workflow Data Fabric, AI Control Tower approval, and Personal Integrations before the server is usable.
- Two new models. Azure OpenAI GPT 5.6 Sol and Anthropic Claude on AWS Opus 5.
Worth knowing about domain separation
Build Agent will not configure domain separation itself. That is a platform admin task with a plugin behind it. Standalone tables that do not extend a domain-separated parent still need manual setup afterward, and ATF tests run in one domain context, so testing across domains means running them in each one.
Coming September 24: Brazil Early Availability
Deferred from the original store release date. These two need Brazil Early Availability and are not backported.
Access
Try Build Agent with nothing to install
What's shipping: When Brazil Early Availability lands, Build Agent (Trial) is installed by default on those instances. No Store install and nothing to request. Open ServiceNow Studio and it is there.
Why it matters: Trying Build Agent used to require a Store install, and a Store install requires an admin. If you were not one, that was usually where it ended.
What this means for you: If Build Agent has been on your list and never made it past the install step, that step goes away on the 24th. Bring something real and small, the table you keep meaning to clean up or the business rule nobody wants to touch, and see how far it gets.
Worth knowing
The trial will give your instance 100 user interactions on a rolling 30-day window. Interactions age out as they pass the 30-day mark, so capacity comes back a bit at a time. There is no reset date to wait for. The count is per instance, not per person, so on a shared sandbox you and your team are drawing down the same 100. The paid version removes the cap.
Adjacent
Autonomous Engineer
Coming soon is a new product alongside Build Agent called 'Autonomous Engineer' which starts from business requirements. It reads your instance, plans the work as a sequence of items with acceptance criteria, and once you approve the plan, it builds and tests them in the background.
Autonomous Engineer runs on Build Agent and uses the same skills, so the standards and rules you have already set up carry over. To access it, you'll need the new AI Workflow Factory SKU and the Brazil Early Availability release, so a Build Agent entitlement on its own will not get you there.
The two serve different purposes. Build Agent is what you want when you are building with the agent in front of you, changing course as you go. Autonomous Engineer suits work you would rather hand off, where the scope is clear enough to write down, and nobody needs to sit and watch it happen.
We will have a lot more to say about Autonomous Engineer soon. We expect teams to use both, as appropriate for their goals and tasks. This community hub is focused on ServiceNow Otto for Creator, so we will reference some of the new content when it comes to Autonomous Engineer. If it sounds like it fits how your team works, your ServiceNow account team can walk you through the required entitlement and help enable it for your instance, as it currently sits behind a feature flag (meaning the Product team needs to enable it).
Wrapping up
Everything outside the Brazil section is on Australia Patch 6 and Zurich Patch 12 today, so most of this release is available without waiting.
And if you have not tried Build Agent at all, September 24 is the date to watch. A Brazil Early Availability instance will have it sitting in Studio, waiting for a prompt.
Building something with Build Agent this month? Tell us in the comments what worked and what got in your way. That is genuinely what shapes the next release.
Published September 2026
