What's New in ServiceNow Otto for Creator, formerly Now Assist for Creator: August 2026 Store Release
Skills and rules, background scripts, sandbox support, and test maintenance in Build Agent.
Table of contents
- Overview
- The road to here
- Set your standards once with skills and rules
- Run and roll back scripts from the chat panel
- Build in an isolated sandbox
- Keep your tests alive as the app changes
- Also in this release
- Resources for builders
- Getting started
- What's next
Overview
The August 2026 store release is live. July was about new things Build Agent could do. This one is mostly about Build Agent fitting the way your team already works: your standards, your environments, your tests, and the work you would otherwise step out of the panel to finish.
That shape came from what you told us. Teams running Build Agent on real work kept hitting the same set of walls, and this release goes after them.
A note on the name
With the August 2026 store release, Now Assist for Creator begins its transition to ServiceNow Otto for Creator, the new ServiceNow AI experience brand for creator and developer workflows. Product entitlements are unchanged, and you should continue to check your entitlements to determine access to specific capabilities. If the chat panel starts saying Otto instead of Now Assist, that is why.
The road to here
Build Agent arrived with Zurich as a conversational developer agent in the ServiceNow IDE, expanded to ServiceNow Studio through the spring, and reached Australia GA in May. June brought flow automation and update set visibility. July added web access and playbook generation. Build Agent now spans more than sixty metadata types across the data model, server logic, UI, integration, security, automation, and testing.
In the July post we said we were working on making Build Agent more configurable, with packaged skills and rules that apply at the organization or personal level. That is what shipped this month, and it is the biggest of the four things below.
Standards
Set your standards once with skills and rules
What's shipping: Two kinds of instruction you can write for Build Agent, stored as records on the instance. Rules load into every session automatically. Skills stay out of the way until you or Build Agent invokes one by name. Both are plain text, up to 65,000 characters, and both carry an Applies To setting that decides which sessions use them: the whole instance, one application scope, or just you. The Build Agent settings panel now has tabs for General, Skills, Rules, and MCP, and both live there.
Why it matters: Today every instruction you give Build Agent lasts exactly as long as the chat. Tell it your table naming convention and it follows it, until you open a new chat or reopen ServiceNow Studio and you are establishing it from scratch again. Same story for wanting generated tests in Automated Test Framework (ATF) format, or never wanting choice lists on a table, or wanting it to look for an existing script include before writing a new one. None of that is hard to say. It is just that saying it is on you, every time, and a teammate who does not know to say it gets different output than you do.
What this means for you: A rule is written once and applies to every prompt after that, in every session, for everyone it covers. Nobody re-establishes context at the start of a chat, and the output stops depending on whether the person driving remembered the right preamble.
|
Rules always on Loaded automatically into every session, so they apply to every prompt without being asked for. Keep them short and behavioral: naming conventions, required fields, organizational standards. |
Skills on demand Available but dormant until you or Build Agent invokes one by name. This is where a longer procedure belongs: a security review, a scoping routine, an audit you want occasionally rather than constantly. |
Some of you solved this already by keeping a markdown file in the project in ServiceNow IDE and pointing Build Agent at it. That worked well enough, but it was a workaround. If you keep a rules file for an AI coding tool outside ServiceNow, this is the same idea, with the file replaced by a record and a scope.
Two rules worth writing on your first day:
reuse_before_create
Check for existing artifacts before generating new ones.
Before creating a table, field, business rule, script include, flow, or
UI action, search the instance for something that already covers the
requirement. Prefer extending an approved existing artifact over
creating a near-duplicate. If a close match exists, tell me about it
and wait before proceeding.
naming_convention
Use our application prefix.
All tables and fields you create use our approved prefix followed by
the application short name. Match existing naming in the app you are
working in rather than introducing a new pattern.
The second one is boring, which is the point. Most of the rules that earn their place are.
A skill looks different, because it holds a procedure rather than a preference:
security_review
Audit the app for access control and risky patterns.
Review the current application and report on tables with missing or
overly broad ACLs, client scripts using GlideRecord, scripts running
with elevated privileges they do not need, and roles granted more
broadly than the workflow requires.
For each finding, give the artifact name, the risk in one sentence, and
the change you recommend. Do not make changes. Report only.
Nobody wants that firing on a session where they are renaming a field. As a skill, you ask for it when you want it.
A few things worth knowing
Rules are not free, because every active rule spends context on every turn, so ten deliberate rules will serve you better than forty. Instance scope covers every session on the instance, including everyone else's, so keep your own preferences at the Me level and save instance rules for decisions the team has actually agreed on. Creating skills and rules requires the admin role.
Left side authoring a new Build Agent Skill. Right side, defined and enablement custom rules in the Build Agent settings panel.
Execution
Run and roll back scripts from the chat panel
What's shipping: Build Agent can now generate and run a server-side script during a build session, using the new run script tool. Before anything executes you get an approval prompt showing the script it wrote, its stated intent, and the application scope it will run in. Scripts run in the scope of the app you are building by default. The new rollback script tool reverts a run afterward.
Why it matters: Until now Build Agent produced metadata and left the rest to you. Plenty of real work sits on the other side of that line. Backfilling a field across existing records. Reshaping data mid-build so the next step has something to work with. Creating something dynamically that no other tool reaches.
What this means for you: Fewer trips out to a background script window in the middle of a build. Executing generated code on your instance is not something to ask for on trust, which is why the approval prompt shows you the script, the intent, and the scope before anything runs.
One limit worth stating plainly
Rollback covers scripts Build Agent ran in the current session. It is not a general undo for your instance.
The approval prompt shows the generated script, its intent, and the scope it will run in.
Environments
Build in an isolated sandbox
What's shipping: Build Agent now runs inside Developer Sandboxes. Each sandbox gives you isolated metadata, admin access in a protected environment, and Git integration, so changes leave through source control rather than by landing on a shared instance.
Why it matters: Agentic development goes better when the agent has room to try things, and room is expensive on a shared development instance. Three people and one agent on the same instance turns into a running conversation about who is touching what. Admin access has been its own blocker, for teams that wanted to put Build Agent in front of more of their developers than they could reasonably grant admin to.
What this means for you: You can let Build Agent work harder and review the result as a diff rather than supervising it in flight. When you asked how to run concurrent development with Build Agent, the answer we gave was already sandboxes plus Git. It is now a supported one rather than a suggestion.
Testing
Keep your tests alive as the app changes
What's shipping: Test Agent now maintains your test suite as the application changes. Tests that no longer map to anything get removed, and tests that partially match get revised. Alongside that: UI testing for browser-level behavior such as multi-step navigation, a prompt after each development action asking whether to generate tests for what you just built, and test execution and troubleshooting from the ServiceNow SDK.
Why it matters: Test capacity looks different at every organization. Some of you have a dedicated test team, some have one person who knows ATF, some have nobody and it falls to whoever built the thing. What tends to hold across all three is that demand for automation grows faster than the capacity to write and maintain it, so tests end up trailing the build instead of moving with it. Coverage gets written at a point in time, the application keeps changing, and the suite slowly stops describing the app. A suite that no longer matches the code is worse than no suite, because it fails for reasons nobody trusts.
What this means for you: Testing happens in the same session as the build, so coverage keeps pace with the code rather than catching up to it later. If you have testers, less of their time goes to maintenance churn and more goes to the cases that need judgement. If you do not, you still get coverage on what you just built.
Settings you turn on
Automatic maintenance runs on Sync ATF tests with app in Build Agent, and UI test runs on Run UI ATF tests in Test Agent. UI tests do not run automatically during updates, since they take long enough to interrupt what you were doing.
Build Agent asks whether to generate tests after a development action.
Also in this release
Smaller changes, each worth knowing about.
- Model version switching in the chat panel. Change the model version in Build Agent without navigating out to the table on the ServiceNow AI Platform. Opus 4.8 is newly supported, and the defaults moved: Gemini 3.5 for Google, GPT 5.5 for Azure OpenAI. Changing the model provider itself still happens in the admin console.
- MCP tool visibility. Expand any connected server in the settings panel to see the tools it exposes and what each one does. Four new servers this month: AWS DevOps, Box, Postman, and Sentry.
- Knowledge base access as a metadata type. Build Agent can now work with the configurations that control who can read, contribute to, or manage a knowledge base and its articles.
- A reorganized settings panel. General, Skills, Rules, and MCP are now separate tabs.
Conversation handoff from ServiceNow Otto
If you are talking to ServiceNow Otto elsewhere on the platform and the conversation turns into something you want to build, Otto can now hand it over. It writes a handoff record holding a summary of the conversation and a reference to the full transcript, and ServiceNow Studio opens Build Agent with that summary pre-filled as an editable prompt.
Nothing runs on its own. You read the prompt, change what you want, and submit it. The full transcript is attached to the session, so the details the summary left out are still available. You need access to both ServiceNow Otto and Build Agent, and you need to be working in ServiceNow Studio.
Resources for builders
The Build Agent Best Practices Guide covers how to structure prompts, ground the agent in your instance, and get reliable results on real work.
The Prompting Guide works from a simpler premise: ask Build Agent to teach you.
And if you missed the July store release, that post has the full picture on web fetch and search, playbook generation, and update set management.
Getting started
Build Agent runs in ServiceNow Studio and the ServiceNow IDE. Everything described in this post requires Australia Patch 5, which is worth saying once here rather than under each feature.
Creating skills and rules requires the admin role. Creating AI agents and skills now requires Build Agent - Prime.
You can still try Build Agent without an entitlement. The Build App - Trial store app gives each account 100 prompts per month, and personal developer instances come with Build Agent activated, with 25 prompts per instance per 30-day cycle. PDIs are kept at the latest Build Agent version, so what you try there matches what you get on a production-track instance.
What's next
September will be one of our most ambitious launches yet, with Build Agent being able to assist with implementations, new model support, improvements to ServiceNow Studio and Build Agent showing up in new regulated customer environments. These are directional rather than commitments, but they are where our attention is going. Stay tuned!
If you write a rule that earns its place, tell us about it. Drop a comment below, and let us know what is working and what you want next. That feedback is what shapes the roadmap.
Published August 2026. Australia GA, August 2026 store release.
