What's New in Now Assist for Creator: July 2026 Store Release
Web access from the chat panel, playbook generation, and cleaner update set management in Build Agent.
Table of contents
- Overview
- The road to here
- Fetch a page from Build Agent
- Search the web from Build Agent
- Search or fetch, and when each fits
- Build playbooks with Build Agent
- More newly supported metadata types
- Cleaner update set management
- Resources for builders
- Getting started
- What's next
Overview
The July 2026 store release is live, and it builds on the June release. This one brings two headline capabilities to Build Agent, web access from the chat panel and playbook generation, alongside a set of updates that make the day to day development experience smoother.
The road to here
If you are new to Build Agent, here is the short version. 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 with Test Agent, in-app agents, the MCP client, and semantic search.
June built on that with flow automation in Build Agent, update set visibility from chat, broader file upload, wider MCP partner support in Studio, and a suggestion of adding test automation after the build cycle. If you missed the June store release post, it is worth a read. This month’s update set improvements pick up directly where June’s update set visibility left off.
Where it started as a conversational agent for a handful of metadata types, Build Agent now spans more than sixty across the data model, server logic, UI, integration, security, automation, and testing. The July release, below, adds to that in a few focused ways.
Not sure what Build Agent can do?
The most reliable answer to what is supported, and where the current limits are, is Build Agent itself. Ask it directly in the chat panel. It reads the documentation for the SDK version on your instance, so it tells you what applies to you rather than what was true at some point in the past.
Context
Fetch a page from Build Agent
What's shipping: Build Agent can now read a specific web page. Hand it a URL and it retrieves the page, converts it to something it can work with, and can distill just the part you ask about rather than the whole thing. It reads HTML, JSON, XML, and plain text.
Why it matters: Some of the most useful context lives at an address you already have: an API reference for a service you are integrating, a docs page for a pattern you are following, a data feed you need to understand before you map it.
What this means for you: Ingesting, referencing or storing dynamic data is simple with Build Agent. Paste the API docs for a service you want to connect to and ask Build Agent to pull out the authentication method and the headers it needs, then build the REST Message from that. Point it at a data feed and have it read the shape before it builds the transform map. The fetch capability can be used as a testing or starting point to shape your data lookup consistently, systematically and in a governed secure matter.
Build an Agent that reads an API via web fetch, then imports the data and creates automation logic to retrieve data on a regular schedule.
Context
Search the web from Build Agent
What's shipping: Build Agent can now search the public web. Give it a question and it comes back with an answer and the sources behind that answer, rather than a page of links for you to sort through.
Why it matters: Build Agent already draws on what it knows: the Fluent documentation, what it can read on your instance, and its bundled knowledge. Web search is what it turns to when a question runs past the edge of that, an error message it has not seen, a third party service it does not have docs for, or a platform behavior newer than what it was trained on.
What this means for you: The answers that would have sent you to a browser tab come back in the conversation while preserving context of your current build session. Ask how another platform handles OAuth, or what a community thread recommends for a pattern you are working through, and keep building from the reply.
Turning on web search
Web search is off by default. Turn it on under Now Assist Settings, on the General tab, with the Enable web search toggle.
Build Agent answers a general question about redundant APIs based on web search results.
Search or fetch, and when each fits
Most of the time Build Agent reaches for these on its own. When it hits a gap its existing knowledge cannot fill, it decides whether to search for what it needs or fetch a page it already has, the same way it decides which of its other tools to use. You can also be explicit: ask it to search for something, or hand it a URL to read. The simple version of the split is that web search is how it finds something, and web fetch is how it reads something it has found.
The two often work as a pair. Integrating with a third party service, Build Agent might search for how that service handles authentication, land on the reference page from the results, then fetch that page to read the exact endpoints and headers before it writes the integration.
|
Web search find it You give it a question. It returns a synthesized answer with the sources it drew on. Best when you do not know where the answer lives. Queries are capped at 256 characters. |
Web fetch read it You give it a URL. It returns the page content, or just the part you ask for. Best when you already have the page and need to read it closely. Reads pages up to 2 MB. |
Worth knowing
Both tools reach public content only over HTTPS, so neither can read pages behind a login, including your instance UI. Neither pulls from live data feeds such as stock tickers or dashboards, and Build Agent treats whatever comes back as reference material, not as instructions.
Looking ahead
Today Build Agent reaches for these as it builds. In the future we would like it to run the lookups more proactively, so keeping information current becomes part of the workflow rather than a manual step.
Automation
Build playbooks with Build Agent
What's shipping: Build Agent now supports playbooks. Describe a guided, multi step process in the chat panel and Build Agent generates the playbook, the stages, and the activities for you. It handles more than linear checklists: parallel work that runs at the same time, conditional routing between paths, scheduled and record based triggers, approval chains, values passed between steps at runtime, and agentic steps that put AI agents and skills to work inside the process, orchestrated by the playbook itself.
Why it matters: If your organization runs on structured business processes, this is a practical way to digitize and standardize them without building each one from scratch in the platform. Playbooks organize tasks and activities into logical stages that guide a person through a record lifecycle in the Agent Workspace.
What this means for you: A process you already understand becomes a working playbook you can refine, rather than a blank canvas you configure by hand. Build Agent generates it in draft, so nothing goes live until you activate it on the instance.
If you are weighing a playbook against a Flow, the difference is who the work is for:
Reach for a playbook
Reach for this when: the process is something a person sees and works through, with forms, checklists, approvals, and guided steps in the Agent Workspace.
Reach for a Flow
Reach for this when: the automation runs in the background with no one watching, the invisible work that happens between the steps.
Playbooks are built from a library of activities, grouped by what they do:
|
Interactive Steps a person works through: instructions, record forms, knowledge articles, and checklists. |
Automation Background steps: create or update records, send email, and wait for a record to meet a condition. |
Approvals Route to a manager, to named approvers, or through a sequential multi level chain. |
|
Branching Decision steps that route to one path or fan out across several, inside a stage or between stages. |
Display Show a filterable list of records for the person to act on. |
Build Agent is direct about what it can build as code and what still needs Workflow Studio to finish. Rather than leave you guessing, it tells you exactly when to switch and hands you the link.
|
Buildable as code generated by Build Agent The standard agent facing workflow: forms, checklists, emails, record updates, approvals, conditional routing, record and scheduled triggers, and editing an existing playbook to redeploy it. |
Finish in Workflow Studio a few niche pieces Questionnaire and manual activities, variants, custom permissions and launcher configuration, public access playbooks, and custom process types. Build Agent scaffolds what it can and points you to Workflow Studio for the rest. |
Getting started with playbooks
Attach an XML file from a Business Process Model and Notation (BPMN) system to your Build Agent session. Build Agent reads the file and uses it as the blueprint for your playbook.
A playbook generated by Build Agent from a BPMN file, showing stages and activities.
More newly supported metadata types
What's shipping: Alongside playbooks, this release adds four more metadata types Build Agent can generate: connection and credential alias templates, data lookup rules, REST messages with their HTTP methods, and user criteria.
Why it matters: The more metadata types Build Agent understands, the more of an application you can describe and generate in one place, rather than switching to manual configuration for the pieces it could not reach before.
What this means for you: You describe and generate these the same way you already work with tables, flows, and other metadata.
|
Connection and credential alias templates The setup form and default values a user sees when configuring an Integration Hub spoke connection. |
Data lookup rules Auto-populate field values from matching conditions, without scripting. |
REST message and HTTP method Reusable outbound integrations with a base URL, shared authentication, and named operations. |
|
User criteria Reusable audience rules that gate who can see a catalog item, knowledge article, or portal content. |
History
Cleaner update set management
Two changes in this release make the record of what you built easier to review, and both build on the update set visibility that shipped in June.
Improved checkpoint and update set management
This update changes how Build Agent handles checkpoints and update sets, so the history reads more like something a person would write.
|
Before harder to follow at merge time Checkpoint 0 created an update set, and update sets carried system generated names that were hard to scan. |
Now a cleaner, readable history Checkpoint 0 no longer creates an update set, Checkpoint 1 becomes the base update set for all subsequent changes, and update sets use human readable names. |
The names come from the change summary Build Agent writes as it installs, so an update set reads as something like “Added priority validation business rule to Incident table” rather than a system generated identifier. The result is a cleaner history that is easier to review when you are ready to merge changes to another environment.
Update sets with human-readable names in the Build Agent chat panel.
Consolidated update sets
What's shipping: Consolidated update sets capture the changes Build Agent generates and any changes you make manually in the same session together, in the same scope.
Why it matters: When a session mixes generated work and hand edits, it is easy to lose track of what ended up where. Keeping both in one scope means the full picture of the session is in one place.
What this means for you: The experience is available directly from the chat panel, so you do not need to navigate away to find what was modified.
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 June store release, that post has the full picture on flow automation, update set visibility, broader file upload, and the end of build ATF prompt.
Getting started
Build Agent runs in the ServiceNow IDE and ServiceNow Studio. To use this release you will want to be on Australia Patch 4 OR Zurich Patch 11 or later.
As a reminder, you can 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. Everything described here is on the standard Build Agent entitlement, and the Build Agent - Trial path PDIs are subject to a separate release cadence.
What's next
A few directions we are working on for the releases ahead. Making Build Agent more configurable, so teams can shape it to their scenarios with packaged skills, and rules that apply at the organization or personal level, alongside a wider choice of models. And moving Build Agent from generating artifacts toward helping plan the work, breaking down requirements and steps before the building starts, with update set management coming to ServiceNow Studio. The larger arc is Build Agent maturing from an AI coding assistant into something closer to an AI software engineering teammate. These are directional rather than commitments, but they are where our attention is going.
A note on the name
At Knowledge 2026 we introduced Otto, the new name for Now Assist. Over the coming months you will see Now Assist rebrand to Otto across the platform, reflecting where we are heading with agentic development. We will share more as that lands. For now, everything in this post is the same Build Agent you already use.
If you build something with this release, 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 July 2026. Australia GA, July 2026 store release.
