Agent Script · MindBlaze

Picture a service agent with one non-negotiable rule: never discuss order details until the customer’s identity is verified. You wrote that rule into the topic instructions, in plain English, twice. In testing it held. Then a transcript lands on your desk where the agent skipped verification because the customer sounded rushed and the model decided being helpful mattered more than following orders.

Nobody misconfigured anything. That’s just what natural-language instructions are: suggestions a language model usually follows. For casual conversation, “usually” is fine. For refund limits, compliance disclosures, and identity gates, it isn’t — and this gap is exactly what Agent Script, Salesforce’s scripting language for Agentforce agents, exists to close.

This post covers what Agent Script actually is and its status as of May 2026, why prompt-tuned behaviour can’t guarantee policy, how the language splits work between the LLM and a deterministic runtime, what that does to testing, and where plain prompting remains the right tool.

What Agent Script is — and where it stands as of May 2026

Agent Script is a high-level, declarative domain-specific language for defining Agentforce agent behaviour. Salesforce introduced it in October 2025 alongside the Agentforce 360 platform announcements, under the banner of hybrid reasoning: let the LLM handle conversation and interpretation, while programmatic expressions enforce the business rules that must never bend.

It’s worth being precise about what kind of thing it is. Agent Script isn’t code that executes line by line at runtime. It compiles into an Agent Graph — a structured specification consumed by the Atlas Reasoning Engine, which we’ve unpacked separately in our look at how the Atlas Reasoning Engine works. You describe what the agent is — its state, actions, instructions, and conditions — and the engine executes against that specification.

The release timeline matters if you’re deciding whether to build on it now:

October 2025: announced in pilot, with Salesforce scheduling a public beta for November 2025 across customer editions, including Developer Edition.
December 2025: the Agent Script Recipes sample app shipped with more than 20 small, copyable examples.
February 2026: the redesigned Agentforce Builder — with Canvas and Script views for Agent Script — rolled out in open beta.
April 2026: at TDX, Salesforce open-sourced the Agent Script authoring toolchain — grammar, parser, linter, compiler, and language server — under Apache 2.0.

As of this writing in May 2026, Agent Script and the new Agentforce Builder are still in beta. Syntax and features are visibly evolving — the docs note that topics were renamed subagents in April 2026, and older examples use both terms — so check the developer guide and current release notes before you commit patterns to production. Salesforce’s product page says the language itself is included with Agentforce at no additional cost.

The core problem: prompt-tuned agent behaviour is probabilistic

Every Agentforce practitioner has lived this cycle. The agent misbehaves, so you sharpen the topic instructions. It behaves for a week. Then a differently-phrased utterance slips past the wording you tuned, and you sharpen again. You’re not fixing a bug; you’re negotiating with a distribution.

That’s not a criticism of the model. It’s what LLMs are. An instruction like “always verify identity before sharing order status” enters a prompt where it competes with conversation history, retrieved context, and the model’s own helpfulness training. Salesforce’s own framing of the problem is blunt: Agent Script exists so you can build workflows that don’t rely solely on interpretation by an LLM. The whole reason Agentforce Testing Center runs utterances in bulk is that a single passing conversation proves very little about the next one.

In practice this splits agent behaviour into two categories with very different tolerance for variance:

Judgment work — interpreting a rambling complaint, choosing a tone, summarising an order history. Variance here is often a feature. Two good answers can be worded differently.
Policy work — identity gates, refund thresholds, disclosure requirements, action sequencing. Variance here is a defect, and in regulated industries it can be a reportable one.

Prompt engineering keeps improving the first category. It can only ever make the second category more likely. This is the line Agent Script draws, and in our experience it’s the single most useful mental model when deciding how to build a given piece of agent behaviour.

Pipes and arrows: how Agent Script splits work between the LLM and the runtime

The language makes the judgment/policy split visible in the syntax itself. In Agent Script’s reasoning instructions, lines beginning with a pipe (|) are prompt text assembled and sent to the LLM. Logic introduced with an arrow (->) — conditionals, action calls, variable assignments — executes deterministically, top to bottom, before the model sees anything.

The other pillar is explicit state. Instead of trusting the LLM’s conversation memory to remember what’s happened, variables are typed and tracked by the runtime — mutable variables the agent updates, linked variables bound to sources like the session, and read-only system variables. Here’s the shape of it, adapted from Salesforce’s published examples:

variables:
   customer_email: mutable string = ""
   is_verified: mutable boolean = False
   order_id: mutable string = ""

reasoning:
   instructions: ->
      | Help the customer with their order.
      if @variables.order_id != "":
         | Their order ID is {[email protected]_id}.

Read that carefully and the model of execution becomes clear. The if isn’t a hint to the model — it’s evaluated by the runtime, and the second prompt line only enters the LLM’s context when the condition holds. Per the flow-of-control documentation, Agentforce resolves all of this logic first and the LLM only starts reasoning once it receives the fully resolved prompt.

That last point is easy to underrate. It means Agent Script is also a context-engineering tool: you decide programmatically which facts, constraints, and options the model is even allowed to see on a given turn. A rule the model never has the context to break is a much stronger guarantee than a rule it’s asked to respect.

The syntax is whitespace-sensitive and property-based — closer to a strict YAML dialect than to Apex. Small details bite: official examples use consistent three-space indentation, and shorter reasoning instructions produce more reliable results, per Salesforce’s own guidance. Treat long prose blocks inside | lines as a smell.

Deterministic actions, LLM-selected tools, and one-way transitions

Where Agent Script earns its keep is action execution, because it gives you two distinct modes with two distinct guarantees.

The first mode is deterministic invocation. A run statement executes the moment the code path reaches it — no model judgment involved. Inputs come from variables, outputs go back into variables:

run @actions.get_order
   with [email protected]_id
   set @variables.order_status = @outputs.status

The second mode exposes the same action as a tool the LLM may choose to call, with the ... marker telling the runtime to let the model fill that input from conversation:

actions:
   lookup_order: @actions.get_order
      with order_id=...
      set @variables.order_status = @outputs.status

Same action, completely different contract. In the first, the lookup will happen and will be chained exactly where you placed it. In the second, the model decides whether and when — appropriate when the customer might or might not want their order checked. You can also gate tools with conditions such as available when, so an action simply doesn’t exist for the model until the state allows it.

Conditional transitions complete the picture. The identity gate that our hypothetical agent kept fumbling stops being a plea and becomes a branch:

if @variables.is_verified == True:
   transition to @topic.order_status

Transitions are one-way: control doesn’t return to the previous subagent, and the next customer message starts again at the agent router. That constraint feels limiting at first. It’s actually the discipline that keeps flows analysable — every conversation turn has a defined entry point and a traceable path out.

Instructions for judgment, script for policy: a new division of labour

Once you have both tools, agent design stops being “write better instructions” and becomes an allocation decision. For each behaviour, ask: if this went wrong one time in two hundred, would anyone outside the team care? If yes, it’s policy — script it. If no, it’s judgment — prompt it.

Concern	Natural-language instructions	Agent Script logic
How behaviour is defined	Prose the LLM interprets	Expressions the runtime executes
Execution guarantee	Probabilistic — usually followed	Deterministic — always followed
State	Model’s conversation memory	Typed, runtime-tracked variables
Failure mode	Quiet drift, plausible improvisation	Lint errors and explicit branches
How you test it	Bulk utterances, judged outcomes	Assertable paths and variable states
Best for	Tone, interpretation, ambiguity, recovery	Gates, sequencing, thresholds, routing

Applied to a typical service agent, the sort we discussed in our Agentforce production lessons, the split usually lands like this:

Move into script: identity and eligibility gates, action ordering that must not vary, monetary thresholds, escalation triggers, which context each subagent is allowed to see, and any behaviour a regulator or auditor might ask you to demonstrate.
Keep in prompts: greeting and tone, interpreting vague requests, deciding which of three clarifying questions to ask, summarising, apologising well, and handling the conversational mess that no flowchart survives.

The most common mistake we see is treating this as all-or-nothing. Teams either stay instruction-only because script “looks like code”, or script everything and produce an agent with the charm of an IVR menu. The design centre of Agent Script is the blend — Salesforce ships it with natural-language authoring and a visual Canvas view precisely so admins and developers can meet in the same artefact.

How deterministic paths change agent testing

Testing is where the argument for Agent Script gets quietly compelling, because deterministic paths are assertable in a way prompted behaviour never was.

With an instruction-only agent, every requirement is tested statistically. You feed Testing Center a batch of utterances with the topic, actions, and response you expect, run them, and read pass rates — because the honest answer to “will it verify identity first?” is a percentage. With scripted gates, whole classes of question stop being statistical. Given is_verified == False, the transition to the identity subagent fires. Not usually. Every time. That’s a unit-style assertion about a path, not a batch experiment about a tendency.

The practical effects stack up quickly:

Static checking exists now. The open-source toolchain includes a parser, a linting framework with more than a dozen passes, and an LSP — so malformed logic, bad references, and unreachable branches surface at authoring time, before any conversation happens.
The probabilistic test surface shrinks. Your utterance batteries stop re-litigating policy and concentrate on what’s genuinely probabilistic: routing classification, slot extraction, response quality.
Agents become diffable. With Agentforce DX, the script lives in your DX project and goes through version control and code review like any other artefact. “What changed in the agent last sprint?” finally has a one-command answer.

None of this eliminates LLM-behaviour testing — the model still interprets, phrases, and chooses tools within the space you’ve defined. What changes is the shape of the risk. You’re no longer testing whether the walls hold; you’re testing how the agent behaves inside them.

Where prompting still wins — and why the answer is both

After all that, a correction of course: if your instinct is now to script everything, you’ve overcorrected. Conversation is genuinely ambiguous, and ambiguity is what the probabilistic machinery is for. A customer who types “it’s broken again and I’m done” needs interpretation, tone-matching, and a judgment call about whether to troubleshoot or escalate with grace. Scripting that produces something worse than either approach alone — a decision tree wearing an LLM as a costume. Salesforce’s own guidance pushes the same way: keep reasoning instructions short, and let the model do the conversational work it’s good at.

The deeper shift Agent Script represents isn’t syntax. It’s that agent behaviour is becoming an engineering artefact — specified, versioned, linted, reviewed, and partially provable — instead of a pile of carefully-worded hopes. That’s the same maturity curve every other part of the platform has already walked, from clicks-versus-code to CI/CD. Agents are simply walking it faster, and in beta, so expect the details above to keep moving even as the direction holds.

If you’re building on Agentforce today, the capability worth developing isn’t fluency in this month’s grammar. It’s the editorial judgment to look at any requirement and say confidently: this is policy, it goes in script; this is judgment, it stays in the prompt. Teams that can make that call quickly will ship agents that are both trustworthy where it counts and human where it matters — and they’ll spend their tuning time on conversations, not on begging a model to follow rule number seven.

Understanding the basics

What is Agent Script in Salesforce Agentforce?

Agent Script is a declarative, domain-specific language for building Agentforce agents. It combines natural-language prompt instructions for conversational work with programmatic expressions — typed variables, conditionals, deterministic action calls, and subagent transitions — for business rules. Scripts compile into an Agent Graph executed by the Atlas Reasoning Engine, an approach Salesforce calls hybrid reasoning. It can be authored in Agentforce Builder’s Canvas or Script views, or locally with Agentforce DX.

Is Agent Script generally available?

Not at the time of writing. Announced in pilot in October 2025 with a public beta from November 2025, Agent Script remained in beta alongside the redesigned Agentforce Builder as of May 2026. Salesforce open-sourced the authoring toolchain — grammar, parser, linter, and compiler — under Apache 2.0 in April 2026, but the runtime stays proprietary. Check the current Salesforce release notes for the latest status before building production dependencies on it.

Does Agent Script replace prompt instructions in Agentforce?

No. Agent Script adds a deterministic layer alongside prompts rather than replacing them. Natural-language instructions still drive interpretation, tone, and genuinely ambiguous conversation, where LLM flexibility is the point. Script takes over where outcomes must be guaranteed: verification gates, action sequencing, thresholds, and routing. Well-designed agents use both — deterministic logic decides what must happen and what context the model sees, while the LLM decides how to say it.

Working out where script should end and prompts should begin in your own Agentforce build? Talk to us — drawing that line is exactly what we do.

Agent Script: when deterministic control beats prompt engineering in Agentforce