Agent Script: Salesforce's Open Language for Deterministic Agent Orchestration

Agent Script: Salesforce’s Open Language for Deterministic Agent Orchestration

Salesforce open-sourced Agent Script at TDX 2026 to provide a structured alternative to fragile prompt engineering. The language introduces a deterministic specification where execution is decoupled from reasoning to ensure strict operational control.

Why This Matters

Traditional Agentforce topics rely on LLM interpretation of natural language instructions, which frequently fails to enforce strict step-by-step logic or verification gates in production. This non-deterministic behavior leads to skipped steps and premature transitions, whereas Agent Script moves control flow into a code-based specification that is testable, auditable, and decoupled from the runtime execution model.

Key Insights

Agent Script is a block-based, indentation-sensitive language similar to Python or YAML (Conor, 2026).
The language uses first-class variable support with explicit types such as ‘mutable boolean’ and ‘mutable string’ for state management.
Deterministic execution is enabled via ‘before_reasoning’ and ‘after_reasoning’ hooks that wrap LLM calls.
The @actions namespace allows direct integration with Apex, Flow, and MuleSoft API calls as first-class citizens.
Salesforce released a full toolchain including a Parser, Linter, and Language Server Protocol (LSP) for VS Code integration.

Working Examples

A minimal valid Agent Script configuration and system block.

config: agent_name: "Support Bot" default_locale: "en_US" system: instructions: | You are a Salesforce support agent. Your job is to triage cases and route them to the right team. Never share internal case notes with the customer. topic default: description: "General support entry point"

Implementation of reasoning hooks for identity verification and routing.

topic billing_support: description: "Handle billing disputes" variables: customer_verified: mutable boolean = False before_reasoning: run @actions.verify_customer_identity with [email protected]_email set @variables.customer_verified = @outputs.verified reasoning: instructions: | Help them with their billing question. after_reasoning: if @outputs.escalation_required: transition to @topic.escalation_confirmation

Apex invocable action that maps to Agent Script’s @actions namespace.

public class LookupAccountTier { @InvocableMethod(label='Lookup Account Tier') public static List<Result> execute(List<Request> requests) { List<Result> results = new List<Result>(); for (Request req : requests) { Result r = new Result(); r.tier = 'premier'; results.add(r); } return results; } public class Request { @InvocableVariable(required=true) public Id contactId; } public class Result { @InvocableVariable public String tier; } }

Practical Applications

Use Case: Case Triage Agent routes inbound support requests to specific product subagents like @subagent.mulesoft_triage based on deterministic variable checks. Pitfall: Relying on ‘ALWAYS’ or ‘NEVER’ prompt clauses results in fragile routing that is difficult to unit test.
Use Case: Financial service agents use before_reasoning hooks to execute mandatory @actions.verify_customer_identity before the LLM can access sensitive data. Pitfall: Allowing the LLM to decide when to verify identity can lead to accidental data exposure.

References:

On This Page