Top features in Brazil release Part 2

sachinbhasin11 · yesterday

Part 1 covered how Brazil turns requirements into built, tested work through Autonomous Engineer and Build Agent. This part covers what keeps that speed safe:

isolated environments to build in;
faster diagnosis when automation misbehaves;
tighter permissions on reusable processes;
broader test coverage;
governance over the external tools your agents can reach.

1. Developer Sandboxes: isolation without the wait

Developer Sandboxes let admins and delegated developers request and manage individual sandboxes on top of a single development instance. Parallel streams of work stop overwriting each other mid-development.

New in Brazil

Sandbox pooling. Developers claim a pre-created sandbox from a pool instead of waiting for one to be provisioned.
Automatic update set source configuration. Moving work between a sandbox and the base instance needs less manual setup.

Caveats

Pooled sandboxes can be stale. The pool refreshes every 24 hours, so a sandbox may briefly lag behind the base instance. Verify app versions and configuration before you start work.
URLs are random. Sandbox URLs are randomly generated and no longer match the display name. Teams that bookmark or script against sandbox URLs will need to adjust.
A feature has been removed. Data generation profiles and templates are no longer available in Developer Sandboxes from Brazil. If your sandbox setup relied on them, you need a replacement.
Short-lived by design. Sandboxes are not a replacement for non-production instances. They are meant to be short-lived, and they work best with ServiceNow Fluent and ServiceNow IDE rather than update sets alone.
Licensing. This is an entitled capability, and installation goes through your account manager.

Example use case

Two developers work on the same application. One is changing the request experience; the other is changing approval and integration logic. Each works in their own sandbox, tests separately, and promotes through the automatically configured update set sources.

2. Flow Troubleshooting Agent: start from a diagnosis, not raw logs

Debugging a flow usually means digging through execution details, trigger conditions, data values, business rules, ACLs and integrations. The Flow Troubleshooting Agent does that groundwork for you:

summarises what the flow does, step by step;
traces the data each step consumes and produces;
flags missing or invalid values;
detects conflicts with business rules or configuration;
returns evidence-based recommendations, with links to the records it flagged.

Scenarios documented for Brazil

Approval recipients that are missing or unresolved
Gaps in approval audit history
Business rules conflicting with the approval engine
Triggers that don’t fire as expected
Role or permission issues on triggers
Mismatches between configured trigger conditions and the actual data changes

How to use it

Enable it. Create the system property com.glide.hub.flow.launch_troubleshooting_agent.
Launch it. You can start it from a flow execution record (which gives it the full flow context), from a problem record, or from anywhere Otto is available.
Mention “flow” in your prompt. The word “flow” is what routes the request to this agent.

It is part of the new Lux-based Flow Designer UI, which you opt into. It also has a companion: an enhancement to the Flow Debugger that lets you adjust a running flow to reproduce intermittent edge cases.

Architect’s take

Treat the agent’s recommendation as a strong hypothesis, not a fix. Validate it before you change production logic.

3. Playbooks and test automation: governance built in

Playbook updates in Build Agent (Brazil)

Playbook-related records consolidated into a single XML update set
Runtime permissions at both playbook level and individual stage level
Outputs for nested playbooks
On-demand launcher configurations
Optional activities
Agentic fields on supported activities (requires the AI Agent plugin)

Testing updates

Test Agent covers lists. It now generates list and related-list test steps, not just form steps. This matters because filters, related lists and role-based visibility are often where access-model bugs hide.
Every work item gets tests. Each Autonomous Engineer agent pack includes Test Agent, so tests are generated for every completed work item.

Example use case

A case-management playbook has four stages: triage, investigation, escalation and closure. Analysts handle triage and investigation, while only managers can escalate or close. Stage-level permissions let you model that segregation of duties directly in the playbook. You then generate list-level test coverage before release.

4. AI Agent Studio

If you build agentic solutions, Brazil adds:

UI validation for agentic processes and generative AI skills;
testing in the playground’s AI-native mode;
widgets for tool outputs;
issue tracing and suggested optimisations directly from result pages.

The value here is less about building more agents and more about understanding how the agents you already have behave.

5. Governing MCP connections

Build Agent can now reach external MCP servers, so it is no longer a contained assistant. Brazil’s AI Gateway helps with this:

Agent-to-MCP traffic is routed through the gateway instead of going direct.
Authentication, policy enforcement and observability of tool calls are centralised in one place.
Before MCP tools are activated, the gateway scans them for threats such as tool poisoning.

Even with the gateway in place, settle these questions before adoption:

How is each MCP server authenticated?
Which tools does each server expose to agents?
What data can leave the instance?
How are permissions mapped and enforced?
What is the fallback if the MCP server is unavailable?
How are prompts, responses and actions audited?

Decide before you scale

Area	Decide up front
Design	App scope and ownership; which existing artefacts to reuse; table and data-model choices
Security	Roles and ACLs; domain separation; integration credentials; MCP authentication and permissions
Quality	Review of generated scripts and business rules; error handling and retry behaviour; ATF and UI coverage
Release	Update set contents; rollback plan; mandatory human checkpoints; entitlements and regional or regulated restrictions

Closing thought

Across both parts, Brazil’s message is consistent: planning starts from a reviewable plan, building happens in isolation, and validation is broader. The tooling takes on more of the work, but accountability for the outcome stays with the developer and the architect.