Make agents predictable: store facts in variables, gate subagents and actions with conditions, and put exact values into prompts with template expressions.
Core concept: Deterministic logic
An LLM on its own can treat the same request differently each time. For anything with a business rule, you want the opposite: the same conditions should always lead to the same behaviour. That is deterministic logic.
The exam objective names three tools for it: variables, filters (conditions) and template expressions. In the new Agentforce Builder they are written in Agent Script; in the legacy builder they live in the Context panel. The ideas are the same.
Understanding agent variables
Variables feeding actions (script view): (1) an action input taken from the VerifiedCustomerId variable, so the agent doesn’t ask again, (2) the same variable reused by another action.
Variables are the agent’s memory. They hold facts so the agent doesn’t have to rely on what the LLM remembers from the conversation.
Use a variable in instructions to tailor a reply.
Use it in a condition to decide whether something may run.
Bind it to an action input so the agent doesn’t ask again.
Store an action output in it so later steps can use the result.
Variables: Quick reference guide
Variables in Agentforce Builder: (1) a custom Boolean, isVerified, that the agent sets once the customer is verified, (2) context variables filled automatically from the Messaging Session, (3) create your own variable.
Kind
Where it comes from
Can the agent change it?
Context (legacy builder: $Context)
Supplied by Salesforce, for example from the Messaging Session: channel, language, verified user
No, read-only
Agent variable (Agent Script: @variables)
Declared in the script with a type, such as boolean, string or number
Yes when declared mutable; set by actions, logic or the LLM
Conversation / custom (legacy builder)
Created in the Context panel
Yes
Variables can also be set by an external system through the Agent API when it starts a session, for example to pass a customer ID from your website.
Applying agent filters
Filters in the agent script: (1) the verification subagent is available only while isVerified is False, (2) case, account and reservation subagents become available only once isVerified is True.
A filter is a checkpoint. If its condition is false, the agent can’t use the subagent or action at all, whatever the user says.
In Agent Script, write it as available when @variables.is_verified == True on the tool or transition.
In the legacy builder, build it from a variable, an operator and a value, and attach it to a topic or action.
Typical uses: identity verification, eligibility, channel- or role-specific actions.
Template expressions
A template expression places a value into text at run time. In Agent Script, {!@variables.first_name} inside a prompt line inserts the stored name exactly. The LLM sees the value; it doesn’t have to guess or remember it.
If the question says the agent must use an exact value (an order number, a tier, a verified name), store it in a variable and insert it with a template expression.
Before you move on
Variables remove reliance on LLM memory.
Context variables are read-only and come from the session.
Filters (available when) hide subagents and actions until a condition is true.
Template expressions put exact values into prompts.
