The new Agentforce Builder: what changed now that the legacy builder can't make new agents

If you tried to spin up a new agent in the last few weeks and couldn’t find the New Agent button where it used to live, you didn’t lose your permissions. Starting the week of July 13, 2026, Salesforce removed the ability to create new agents in the legacy Agent Builder in Setup. New agents now get created in one place only: Agentforce Builder inside Agentforce Studio. The old builder still opens, your existing agents still run, and you can still edit them, but the door to new work closed, and it’s not reopening.

That’s a bigger shift than the missing button suggests. The new builder isn’t a reskin of the old topics-and-actions screen. Underneath it is Agent Script, a different authoring model with a different metadata shape, a different deployment story, and a different mental model for how you reason about what your agent will do. Teams that treated the cutoff as a UI change are finding out, usually mid-build, that the thing they knew how to do fast in the old builder now works differently. This post is the orientation I wish more people had before the deadline: what the new builder is, how its pieces fit, what changed under the hood, and how to move a legacy agent across without a big-bang rebuild.

Two builders, and why there were ever two

For most of Agentforce’s first year, you built agents in what’s now called the legacy builder: the Agent Builder screen in Setup, where you assembled topics, wrote classification and scope instructions in prose, and attached actions. It was declarative, approachable, and probabilistic: the agent’s behaviour came almost entirely from natural-language instructions the reasoning engine interpreted at runtime. That’s fine for a FAQ deflection agent and fragile for anything with rules, which is the whole reason Agent Script exists.

The new Agentforce Builder shipped to beta in the Winter ‘26 timeframe and reached general availability in February 2026. It’s a purpose-built authoring workspace in Agentforce Studio, and it’s where Salesforce is putting every new capability. Agent Script, Agentforce Voice, per-subagent model selection, and multi-agent orchestration among them. None of those are coming to the legacy builder. That was the tell, months before July: when a vendor stops back-porting features to the old tool, the old tool is on a timer.

The legacy builder didn’t break. It stopped being the place new capability lands. The July 13 cutoff just made official what the feature list had been saying since spring.

So the honest framing for August 2026 is: you’re on the new builder now whether you planned the migration or not. New agents have no other home, and every legacy agent you still run is frozen at its current feature set until you move it.

What the new builder looks like

The new builder is organised around a few surfaces that are worth naming precisely, because the vocabulary matters when you’re reading the docs or debugging with a colleague.

Explorer. The left-hand navigator for the agent’s elements: its subagents, actions, variables, and connections. This is how you move around a non-trivial agent without scrolling through one enormous document.
Canvas. The document-style editor. If you’re a low-code builder, this is where you live: you edit subagents and actions as structured, natural-language text, with typeahead and inline tooling that surface the resources you can reference. It reads like a document and behaves like a form.
Script view. The same agent, shown as Agent Script, the actual language your configuration compiles to. Pro-code builders write here directly, with syntax highlighting and real-time validation. Canvas and Script are two views of one underlying artifact, not two separate agents; a change in one is a change in the other.
Preview. The test panel. You type an utterance and watch the agent respond, and, this is the part that changes how you debug, you get a summary of the agent’s reasoning and behaviour for each message, not just the reply. When an agent picks the wrong subagent, Preview is where you see it choosing, which is far more useful than staring at a wrong answer and guessing why.

The two-view design is the point. The old builder made you choose between “clicks” and “code” at the tool level. The new one lets a declarative builder and a developer work on the same agent from the surface each prefers, and that’s new. If you’ve read our piece on why agents keep picking the wrong topic, the Preview reasoning summary is the instrument you always wanted for that problem. It shows the classification decision instead of leaving you to infer it.

Topics became subagents, and other renames that aren’t just renames

Beginning in April 2026, what the old builder called topics are called subagents. It’s tempting to file that under cosmetic, but the rename tracks a real change in how the pieces compose. A subagent is still the unit that groups related instructions and actions and gets selected by intent, but in the Agent Script world it behaves more like a callable unit of the agent than a labelled bucket of prose. When a customer asks about an order, the agent detects intent and transitions to the subagent that can identify the customer before it hands over anything order-specific. The routing you used to hope the classifier got right is now something you can express and, crucially, test.

The other vocabulary you’ll meet immediately: your agent’s entire configuration (subagents, instructions, action references, connections) is stored as an AiAuthoringBundle (the “authoring bundle”). That’s the metadata component. When you Save and Commit Version, the builder snapshots that bundle and compiles the Agent Script down into the lower-level metadata the reasoning engine consumes. Think of it as infrastructure-as-code, but for agents: the bundle is the source you version, and the compiled output is the runtime artifact.

The deployment story is different, and better

This is where the change stops being about a UI and starts affecting your release process. In the legacy world, moving an agent from sandbox to production meant hunting down a scattered set of metadata types and hoping you got the whole graph, the hard part we wrote up in the metadata map nobody hands you.

The authoring bundle tightens that up. Because the agent is a coherent metadata component, pro-code teams can work the whole lifecycle from a Salesforce DX project:

# Author locally in a DX project, then deploy the authoring bundle to a dev org
sf project deploy start --metadata aiAuthoringBundle:Local_Info_Agent

The lifecycle Salesforce documents is three clean stages:

Develop. Author the Agent Script (in the builder’s Script view, or in VS Code against a DX project) to define the agent’s subagents, instructions, and logic.
Publish. Deploy the authoring bundle to a development org, which creates the runnable agent metadata from your script.
Deploy. Migrate that metadata to production through your normal release pipeline.

The reason this matters: agents are now a source-controllable, reviewable, promotable artifact like any other. You can diff a change, put it through a pull request, and deploy it with the same discipline you’d apply to Apex. That’s the release maturity the sandbox-to-production problem was always missing, and it’s a direct consequence of the bundle model, not a separate feature you have to bolt on.

How to migrate a legacy agent without a rebuild

You do not have to rewrite a legacy agent from scratch. Salesforce provides an in-place upgrade path, and for most agents it does the heavy lifting.

The flow: open Agentforce Studio, select your legacy agent, and choose Upgrade to New Builder. The upgrade converts the agent’s configuration (subagents, actions, system messages, connections) into Agent Script automatically and lands it in the new builder. What was prose-and-clicks becomes an authoring bundle you can then evolve with Script view, per-subagent models, Voice, and everything else the legacy builder will never get.

A few things I’d hold onto before you run it:

Do it in a sandbox first. The upgrade is a conversion, and conversions surface assumptions. Run it against a copy, exercise the agent in Preview and in your test suite, and confirm behaviour matches before you touch the production agent. This is exactly what a disciplined sandbox strategy is for.
Re-verify grounding and actions, don’t assume them. The upgrade migrates references, but the reasoning that selects an action can behave subtly differently once it’s expressed as script and routed through subagents. Test the paths that touch data or take an action first, because those are the ones where a subtle change has consequences. The pre-launch discipline in our Agentforce setup checklist applies to a migration just as much as a new build.
Treat it as the moment to fix what was fragile. If an agent was already flaky at picking topics or over-scoped in what it could do, the upgrade is your opening to tighten it. Convert the vague prose rules that were “probably” working into deterministic Agent Script expressions where the workflow can’t tolerate probably.
Sequence it against your roadmap. Legacy agents keep running, so you’re not forced to migrate everything this week. Prioritise the agents that need a new-builder-only capability (anything that wants Voice, per-subagent models, or multi-agent orchestration) and leave stable, feature-complete legacy agents until you have a reason to touch them.

If you’re still running Einstein Bots, note that this is a different problem with a different answer: bots don’t “upgrade,” they get rebuilt as agents. The Upgrade to New Builder path is specifically for agents already built in the legacy Agentforce builder.

What gets easier, and what doesn’t

Two honest caveats, because the migration is a real project and not a button.

The new builder lowers the floor for collaboration and raises the ceiling for control: a declarative builder and a developer editing the same agent from Canvas and Script is a workflow the old tool couldn’t offer, and the bundle-based deployment is a clear win for release governance. Preview’s reasoning summary alone will save you hours the first time an agent misroutes.

What doesn’t get easier: the thinking. Agent Script gives you deterministic control, but only if you use it, a migrated agent that’s still all natural-language instructions is just as probabilistic as it was in the legacy builder, now in a nicer editor. The value comes from deciding which parts of the agent’s behaviour must be rules and expressing those as deterministic logic, and that’s design work no tool does for you. And per-subagent model selection is powerful precisely because it’s a decision: which model for which job, at what cost, is now yours to get right.

The takeaway

The July 13 cutoff wasn’t the end of the legacy builder, your old agents keep running, but it was the end of it as a place to do new work. Every new agent, and every legacy agent you want to move forward, now lives in Agentforce Builder on top of Agent Script, as an AiAuthoringBundle you can version, review, and deploy like code. Learn the surfaces (Explorer, Canvas, Script, Preview), understand that topics are now subagents, and treat the Upgrade to New Builder path as a sandbox-first migration you sequence deliberately, starting with the agents that need what only the new builder offers. Do that and the cutoff is a non-event. Ignore it and you’ll discover the missing New Agent button at exactly the moment you’re trying to ship.

Understanding the basics

What is the new Agentforce Builder?

Agentforce Builder is Salesforce’s next-generation agent authoring workspace inside Agentforce Studio, generally available since February 2026. It replaces the legacy Agent Builder in Setup for creating new agents and is built on Agent Script. It provides an Explorer to navigate an agent’s elements, a document-style Canvas for low-code editing of subagents and actions, a Script view for writing Agent Script directly with syntax highlighting and validation, and a Preview panel that tests utterances and shows a summary of the agent’s reasoning for each message.

Can I still use the legacy Agentforce builder?

Existing agents built in the legacy builder continue to run and remain editable, but starting the week of July 13, 2026, you can no longer create new agents there: the New Agent button was removed, and new agents must be created in Agentforce Builder in Agentforce Studio. No new features are planned for the legacy builder, so capabilities like Agent Script, Agentforce Voice, per-subagent model selection, and multi-agent orchestration require the new builder.

How do I migrate a legacy agent to the new builder?

In Agentforce Studio, select your legacy agent and choose Upgrade to New Builder. Salesforce automatically converts the agent’s configuration (subagents, actions, system messages, and connections) into Agent Script and lands it in the new builder. Run the upgrade in a sandbox first, re-test grounding and actions in Preview and your test suite, and prioritise migrating the agents that need a new-builder-only capability.

What is an AiAuthoringBundle?

The AiAuthoringBundle (authoring bundle) is the metadata component that holds an agent’s entire configuration (subagents, instructions, action references, and connections) authored as Agent Script. When you save and commit a version, the builder snapshots the bundle and compiles the script into the lower-level metadata the reasoning engine runs. Because it’s a coherent metadata component, you can author it in a Salesforce DX project, deploy it with the Salesforce CLI, and promote it through your release pipeline like any other source-controlled artifact.

Migrating a fleet of legacy agents, or standing up your release pipeline for authoring bundles before the migration gets messy? Talk to us. Getting agents from a sandbox to production cleanly, and keeping them deterministic where it matters, is exactly the work we do.