hello@audit9.com
Creating a custom Agentforce agent now looks quite different from the experience Salesforce admins and architects first encountered. This is more than a redesigned interface: Salesforce has introduced a new authoring model combining natural-language configuration, structured logic, version control and integrated testing.
Since the week of 13 July 2026, new agents can only be created in the new Agentforce Builder within Agentforce Studio. Existing agents built in the legacy builder continue to operate and can still be edited, but the new builder is now the route for creating agents and receiving the latest capabilities.
Here are the main changes teams need to understand.
The new experience is centred on Agentforce Studio, which brings agent creation, testing and monitoring into one workspace. Its Explorer provides a consolidated view of an agent’s subagents, actions, variables, data sources and connections.
The builder has two ways to edit the same configuration:
Preview supports conversational testing, while the Console identifies errors and warnings. Built-in Agentforce assistance can also help create, refine and troubleshoot the agent.
This makes the builder suitable for both declarative and pro-code development without separating them into different agent configurations.
Salesforce began renaming agent topics as subagents in April 2026. Although the terminology change did not alter their basic functionality, the new name better describes their role in the new architecture.
A subagent owns a defined area of work. A service agent might contain separate subagents for identifying a customer, checking an order, processing a return and escalating a complaint. An Agent Router interprets the request and selects the appropriate route, after which the agent can move between subagents as the process develops.
Designers therefore need to think beyond a collection of isolated topics. Each subagent should have a clear purpose, appropriate actions and explicit transition conditions. Overlapping responsibilities make routing harder to predict and test.
One of the most important additions is Agent Script, the language behind the new Agentforce Builder. It combines natural-language reasoning instructions with programmatic expressions for business rules.
A language model remains useful when an agent must understand a request, interpret context or formulate a response. Important business decisions, however, should not depend entirely on how the model interprets a prompt on a particular occasion.
Agent Script can define conditional logic, retain values in variables, control transitions between subagents and specify the order in which actions run. It also lets teams identify where the model can reason flexibly and where it must follow a deterministic path.
For example, a model may recognise that a customer is requesting a refund. Structured logic can then require the agent to verify the order, check its status and compare the value with an approval threshold before running the refund action. Higher-value cases can be routed to an employee.
This hybrid approach provides conversational flexibility while keeping important business controls predictable.
The legacy reasoning engine generally classified a request into one topic and repeatedly reasoned about the next action. In the new builder, the agent operates through a graph of subagents connected by transitions.
Variables carry state along this path. Instead of repeatedly inferring the same information from the conversation, the agent can retain values such as whether the customer has been authenticated, which account is in context or whether approval is required.
This can make behaviour easier to understand and reduce unnecessary reasoning. It does not, however, remove the need for good process design. Teams must still define clear responsibilities, transitions and failure paths.
The new builder introduces a clearer release lifecycle. Work starts in an editable draft, where changes can be saved and tested without immediately altering the live agent.
When the draft is ready, Commit Version creates an immutable version that can be activated. Further changes require a new draft rather than editing the committed version.
The lifecycle is therefore straightforward:
This distinction reinforces an important point: saving an agent is not the same as deploying it to production.
Preview shows which subagents and actions the agent selected, while debugging information helps explain how it produced a response. Simulation mode can test behaviour without allowing the interaction to update organisational data.
This visibility matters because a plausible final answer does not prove that the correct path was followed. Testing should confirm that the agent selected the intended subagent, used the correct data, ran only authorised actions, retained variables correctly and followed required approval steps.
Teams should also test incomplete requests, alternative wording, unauthorised users and attempts to push the agent beyond its approved scope—not only ideal conversations.
The new builder stores its human-readable Agent Script in an AiAuthoringBundle, including a .agent file that can be managed through Salesforce DX. This makes agent changes easier to compare, review in source control and include in a CI/CD process.
Local subagents and actions can also be associated with a particular agent version, reducing the risk that a change to a shared asset unexpectedly affects several agents. Organisations using automated deployments should review their metadata and package configuration rather than assuming the legacy process will remain unchanged.
Existing agents are not replaced automatically. Salesforce provides an Upgrade to New Builder action that creates a new version in Agentforce Studio and converts the original configuration to Agent Script. The legacy agent remains unchanged and available during validation.
A controlled migration should follow these steps:
Separating migration from redesign makes problems easier to diagnose. If both happen together, it becomes difficult to determine whether a changed result came from the conversion or the new design.
The new Agentforce Builder provides more control, but it does not replace architecture and governance. Teams must still define the business outcome, authorised users, trusted data sources, permitted actions and situations requiring human judgement.
Deterministic logic is valuable for permissions, validation, transaction order and decisions with material consequences. Model reasoning is useful where genuine flexibility is required. The aim is not to turn every instruction into code, but to apply stronger control where inconsistency would create risk.
The new builder could support a clearMDM Data Steward Agent using separate subagents to review potential duplicate records, recommend a resolution and escalate uncertain matches to a human data steward. Each subagent would have a defined role while remaining part of one coordinated data-quality process.
Testing a clearMDM agent could include checking that it uses governed match results, does not merge records without the required approval and routes low-confidence recommendations for human review.
Before committing and activating a custom agent, confirm that:
The new Agentforce Builder changes custom-agent development from a mainly prompt-led configuration exercise into a more structured software lifecycle. Agentforce Studio, subagents, Agent Script, graph-based execution and committed versions give teams greater control over agent behaviour and production changes.
For new projects, this means designing a coordinated workflow rather than a loose collection of topics and instructions. For existing projects, migration should be treated as a tested release—not simply an upgrade button.
The new tooling makes reliable agents more achievable, but reliability still depends on clear processes, trusted data, governed actions and disciplined testing.
