Brazil now has dated notes from ServiceNow itself

ServiceNow's Brazil release notes are live in first-party product documentation, and both the new-features summary and the changes summary carry the stamp Updated September 23, 2026. The available-versions page records a release type of Feature Early Availability, a release date of 2026/09/24 and a status of Available to Early Availability customers. Until those pages appeared, anyone planning around Brazil had preview decks and undated community posts.

That matters because of what we could not print a few days ago. Our piece on the ServiceNow family release cycle recorded that the Brazil versioned path returned a not-found error, and that a community post pointing at a September 24 early availability carried only a relative timestamp. We declined to print the date on that basis. It is now first-party and dated, so it is quotable.

One thing the pages still do not give you is a version or build number for Brazil. None is published, so any runbook or risk register that wants one has to carry a blank for now.

Early Availability is a smaller door than it sounds

The status line reads Available to Early Availability customers, and that is the whole scope the documentation commits to. There is no second status describing a wider release, no date attached to one and no statement about which customers qualify or how one joins that group.

So the September 24 date belongs in your calendar as the day the release exists somewhere, not the day your instance can have it. An upgrade plan carrying a line that says Brazil is available from 24 September is wrong for almost every organisation reading this. The defensible phrasing for a steering committee is that the release entered Early Availability on a documented date and broader timing has not been published.

Your account team is the only route to a real answer about whether your instances are in scope. Ask before someone builds a fourth-quarter plan on a date the documentation does not support.

The Brazil pages sit at a different address from the older families

Brazil content resolves at the unversioned current-release documentation path. The Brazil-versioned path still returns not found. Zurich and Yokohama keep their versioned paths, so the current family and the older families now behave differently on the same documentation site.

Anything that hard-codes a versioned documentation URL is affected. That covers browser bookmarks, links pasted into a runbook, the reference column in a change record and any script that builds a documentation link from a family name. All of those keep working for Zurich and Yokohama and quietly do something else for Brazil.

The fix is small and worth doing before someone files a ticket about a broken link. Point Brazil references at the unversioned current-release path and add a note that the page will serve whichever family is current on the day it is read, which is the same discipline behind our method for reading change notes. A screenshot of that page in an upgrade plan describes one day only.

About 90 product areas changed and the weight is in the AI tooling

The changes summary covers roughly 90 product areas. The list takes in ITSM MCP Server, Incident Management, Service Operations Workspace for ITSM, Discovery, ITOM AIOps, CMDB, Authentication, Build Agent and Autonomous Engineer. Breadth at that scale is ordinary for a family release and tells you little on its own.

Where the new feature names cluster is the more useful signal. AI Agent Studio and AI Control Tower carry the densest set of named additions we could confirm, which matches where ServiceNow has been spending its product attention across its agent surface.

We are naming only features that read identically across two separate fetches. Live documentation shifts during a release window, and a name that shows up once does not belong in a planning document somebody else will act on.

Several of the new agent features exist to hold agents back

Under AI Agent Studio the confirmed names are Define security controls for MCP Servers, Create an external AI agent, Test access to an AI asset and Model Context Protocol Client. Under AI Control Tower, Control AI asset usage through policies and Add an Azure AI Foundry connection. AI Desktop Actions adds Execute adaptive desktop actions on macOS.

Three of those constrain what an agent can reach rather than creating another agent. Defining security controls for MCP servers, testing access to an AI asset and controlling AI asset usage through policies all point at the question a platform owner has been asking since the first agent went into production, which is what the thing can touch. A platform adding governance to capability it already shipped is a fair move, and it also tells you which came first.

Test access to an AI asset is the one to put in front of your security reviewer. Checking an agent's reach before it runs changes the shape of an approval conversation, and it sits alongside what we found when MCP servers turned out to run on existing roles and ACLs. The documentation gives names rather than behaviour, so nothing here is confirmed detail until you have the entry open.

The Authentication entries are the quiet ones

Authentication carries two confirmed additions, Policy-based login experience and SAML certificate expiry notifications. Neither will lead anyone's release summary, and both land on the surface every user and every integration passes through.

A change to the login experience reaches everybody at once and is the hardest kind of change to reverse halfway through a morning. Certificate expiry is the other one. Most platform teams have been through at least one outage that turned out to be an expired signing certificate nobody was watching, and a notification that lands before the expiry earns its place faster than most of the AI entries above it.

Open the changes summary, filter it to the product areas you actually run and read the Authentication entries in full before anything else. Then check the expiry dates on the SAML signing certificates in your own instances, because those dates are available today and do not depend on when Brazil reaches you. ServiceNow's new-features summary page is where to start.