Inside the New Agent Builder: How Agent Script Solves the Reliability Problem

"Chance is nothing real in itself, and, properly speaking, is merely the negation of a cause." - David Hume, A Treatise of Human Nature

In the first post in this series, I made the case that determinism, not intelligence, is what nonprofits should be demanding from their agents: the same inputs producing the same outputs, every time. I also promised a closer look at how the new Agent Builder actually delivers on that promise. This is that look. Hume gives us the right frame for it, because the legacy Builder's problem was never a shortage of intelligence. It was a shortage of causes. 

Too much of the agent's behavior depended on interpretation in places where the business process required discipline, and too much depended on the model inferring what probably ought to happen next when what the workflow actually needed was a gate, a sequence, or a rule.

For builders and architects, this gets close to the nerve of the whole thing: the value of intelligence in a system is not that it can sound smart, charming, or even unusually persuasive. The value is that it can support dependable habits of action when something real is on the line.

That is why Salesforce’s recent Agentforce shift matters more than some of the ecosystem chatter has quite known how to say. The problem was never simply whether agents could talk well. Plenty of them could. The problem was whether they could behave well when the conversation stopped being interesting and started becoming operational.

That is where a lot of us learned the hard lesson. In the earlier Agentforce era, you could build something that looked awfully impressive right up until it needed to do something in the same order, under the same conditions, for the same reason, every single time. That is a much less glamorous requirement than “intelligence,” but in actual system design it is often the more important one. 

This is often why I’ve joked about “us Luddites still working predominantly in Flow,” because say what you want about Ye Olde Flow; at least it has always allowed us, in its own stubbornly unromantic way, to determine what it is going to do and when it is going to do it. A Decision element is not trying to be insightful. An Assignment is not trying to be creative. A Record Update is not reading the vibes of the user’s phrasing and deciding that perhaps this time the sequence should be a little more adventurous. Flow has many shortcomings, Lord knows. But one of its great virtues is that it has long trained Salesforce builders to think in terms of gates, branches, required conditions, explicit paths, and repeatable outcomes. In other words: causes. Sequences. Rules. The very things many of us found ourselves missing once we began asking language models to carry operational responsibilities they were never especially well-suited to carry on their own.

Natural language models are very good at sounding like they understand. They are often very good at filling in gaps, smoothing over ambiguity, and carrying a conversation forward with remarkable fluency. But when a workflow carries real stakes, “pretty good” is not the same thing as trustworthy. In production, ambiguity does not stay abstract for very long. It turns into drift. It turns into inconsistency. It turns into support tickets, bad routing, missed steps, and users losing confidence in a system they were told would help them.

That is why determinism is the more important word here. Not because every part of an agent should be rigid, and not because conversational systems should stop being flexible. It means that the parts responsible for routing, validation, sequencing, and action execution should not be left to the mood of the prompt. They should be bounded, inspectable, testable, and repeatable.

For Salesforce builders, that is the real significance of the new Agent Builder. It is not merely that Salesforce added more “AI stuff.” It is that the platform has started to mature past the phase where we asked language models to carry responsibilities that were never really theirs to carry alone.

The Agentforce Studio Fix: From "LLM-Led" to "Code-Led"

The legacy Builder pattern was essentially to pass the LLM a giant blob of (well-written) instructions and hope it behaves deterministically as much as possible. Action sequencing was mostly inferred.

The model did most of the "thinking."

Salesforce's new pattern inverts this: run a script that encodes deterministic logic, and hand off to the LLM only when flexibility is actually needed. Identity verification, required field collection, action sequencing, security gates; these realities can now execute the same way every time, regardless of how the user phrases their request. The LLM handles conversational flexibility while the new Agent Script enforces the sort of predictable outcomes and outputs we have become so beautifully accustomed to in Flow and most of Salesforce's other declarative automations.

This is why the new Builder introduces Agent Script. It's not a nice-to-have. It's the architectural fix that makes determinism possible, and, therefore, makes production deployment more viable for NPOs.

What Actually Changes in the New Agent Builder Config UI

Legacy Agent Builder (in Setup):

• Topics configured through a wizard-style interface
• Instructions are a single natural language blob
• Action chaining requires the LLM to infer sequence from context
• No explicit state management; the model "remembers" (or doesn't)
• You have to create separate action metadata/libraries as additional configuration

New Agent Builder (in Agentforce Studio):

• "Canvas" view summarizes agent logic into readable blocks
• "Script" view exposes the underlying Agent Script for direct editing
• if/else conditions, variables, and deterministic action execution
• Topic Selector runs first as the routing gatekeeper- with conditional logic!
• Actions can reference Apex classes and invocable flows more directly than the legacy wizard approach
• Built-in testing with detailed interaction breakdowns
• Agent logic expressed as a single script (compiles to metadata for deployment)

For existing Agentforce users, you can be assured that the topics and actions you created in the legacy Builder are still accessible. When you add them to an agent in the new Agent Builder, you can customize them with Script view capabilities.

However, here's the migration reality as far as I can tell: simply porting old topics and instructions yields mediocre results. You need to rewrite and tune them for the Agent Script model. The old "blob of instructions" approach doesn't necessarily translate cleanly to the new architecture.

The New Salesforce Agent Builder Architecture: A Quick Mental Model

Before you start building, you need to understand the conceptual stack. The new Salesforce Agent Builder uses four core concepts:

Topic Selector = The front door. This runs first on every user input and classifies/routes the conversation to the appropriate topic. Critically, it can include conditional gating: only allow certain topics when isVerified = true, route unverified users to verification first, restrict sensitive topics based on user type. This is a major fix for "agent won't get into the right topic"-- you can now explicitly control routing logic.

Topics = Jobs the agent can do. Think of these as skill bundles. A topic like "Participant Benefit Management" groups related actions together and includes instructions that tell the LLM when and how to use them. Each topic has a name, description, and reasoning instructions that guide the agent's behavior.

Actions = The actual tools. These are flows, prompt templates, or Apex invocable actions that do something concrete: query records, create records, call external APIs, etc. In the new model, Agent Script directly references Apex classes and invocable flows; no intermediate "action library" metadata to manage.

Agent Script = The control layer. This is Salesforce's new language for defining deterministic behavior alongside LLM reasoning. You can use if/else logic, set variables, chain actions in sequence, and control exactly when the LLM gets to "think" versus when the agent follows a strict path. The agent logic is expressed in a single script that compiles to deployable metadata.

Here's the key insight: The script handles deterministic logic; the LLM handles natural language. Security checks, identity verification, required field validation, action sequencing– these produce the same result every time. Conversational flexibility, natural phrasing, gap-filling; that's where the LLM earns its keep.

The art is knowing the rhythms of when to emphasize one or the other when translating real business requirements in the Builder.

Conclusion: The Determinism Dividend

Let's return to where we started: determinism. The idea that given the same inputs, you get the same outputs. Every time.

Since Agentforce was introduced at Dreamforce 2024, the Salesforce ecosystem has been learning what agentic AI can and can't do reliably. The lesson is now clear: LLMs excel at understanding intent, generating natural language, and filling gaps in incomplete information. They struggle with (and shouldn't be trusted solely for) repeatable logic, security decisions, and multi-step processes where sequence matters.

The new Salesforce Agent Builder doesn't solve this by trying to make LLMs smarter. It solves it by changing the question. Instead of asking "how do we make AI so that it understands weird user inputs correctly every time?", Salesforce asked "how do we discipline AI so that it better serves us rather than the other way around?"

Agent Script is Salesforce’s answer to this question. It's a boundary-drawing tool. It lets you say: here is where the machine follows rules, and here is where it gets to be creative. The creativity serves the conversation. The rules serve the mission. 

For nonprofits, this matters more than it does for most industries, and it is worth repeating the stakes I laid out in the first post. The populations you serve should not have to absorb the cost of errors. A benefit disbursement logged incorrectly isn't a minor data quality issue; it's someone's groceries, or bus fare, or medication access. A recurring gift paused when it should have been resumed isn't an inconvenience; it's a donor relationship at risk. A grant application routed to the wrong reviewer isn't a workflow hiccup; it's weeks of delay for a community organization that budgeted around your timeline. In part one, these were the reasons to wait. Now they are the reasons to build.

The good news: you can now build for it. The new Agentforce Builder gives you the tools to encode your business logic explicitly, to gate sensitive operations behind verified states, to chain actions in guaranteed sequences, and to document your agent's behavior in a way that survives staff turnover and audit scrutiny. Your Agent Builder implementation can finally match the rigor your mission demands.

The question is no longer "is Agentforce ready for nonprofits?" The question is: "are you ready to define what 'every time' means for your organization?"

Start there. The technology will follow.

If you missed the first post making the case for why determinism matters for mission-driven organizations, you can catch up here. Have you opened up the new Agent Builder yet? Did Agent Script change how you think about what belongs to the script and what belongs to the model? I'd genuinely like to hear how other builders are drawing that line. Reach out to Arkus on LinkedIn or through our website contact form with questions, agent stories, or topics for another series.