Agent Script Is a Control-Flow Language

When an Agent Should Reason and When It Should Follow a Path

An agent can improvise its language without being allowed to improvise the business process.

That distinction is easy to lose when a conversational agent is described as a single intelligent worker. A lead-routing request may sound open-ended to a person, but the business still has a known sequence: identify the lead, validate required facts, apply routing policy, assign ownership, create follow-up work, and record what happened.

Before AI, Salesforce teams expressed that sequence with fields, validation rules, Flow, Apex, queues, assignment rules, approvals, and explicit screens. The path could be inconvenient, but its control points were visible.

Agent Script makes the new design more interesting because it puts natural-language reasoning and programmatic control in the same workflow. Salesforce describes logic instructions as deterministic and prompt instructions as language sent to the LLM. That makes Agent Script more than a prompt file. It is a control-flow language for a hybrid program.

The architectural question is not whether the agent should be flexible. It is:

Which decisions may be interpreted, which transitions must be explicit, and which actions require proof before the conversation continues?

This is the third post in AI-Native Architecture on Salesforce. The previous post separated the platform’s interface and agent surfaces. This post examines the control flow inside the agent runtime.

Salesforce Before an Agent Chose the Path

Consider a lead arriving from a web form.

A Flow might normalize the form fields, validate the country, look up the account, and assign the lead to a queue. Apex might call a service that checks territory or regulatory restrictions. A human might review a high-value lead before an owner is assigned. A task and notification might be created after the record update commits.

The interaction did not need to understand a sentence such as “Please find the right person for this prospect.” The application received a record and ran named automation. Missing fields caused validation errors. A rule selected a queue. An approval paused the process. The business could point to the metadata and code that owned each decision.

The path was explicit even when the implementation was distributed across Salesforce surfaces.

Today: The Agent Can Interpret the Request

An agent changes the entry point. A seller can say:

Route this lead to the best owner, but check whether the company is regulated and ask me before sending anything.

The agent may need to identify the lead, ask for missing information, decide which subagent or action is relevant, and explain the outcome. This is where model reasoning is useful: language is incomplete, context is conversational, and the user may express the same intent in many ways.

The business path still needs explicit structure.

Salesforce documents Agent Script as combining deterministic logic with LLM reasoning. Logic can set variables, run actions, branch, and transition. Prompt instructions can give the model the information and language instructions it needs to respond. Actions can be called explicitly or exposed as tools for the LLM to choose.

Those are different control modes:

Control mode	Best use	Risk if overused
Explicit logic and transitions	validation, sequencing, policy gates, state changes	rigid interaction or unnecessary branching
Model reasoning	interpreting intent, asking a useful question, summarizing, ranking candidates	variable behavior at a consequential boundary
Human decision	exceptions, accountability, irreversible or sensitive work	slow throughput and unclear escalation if not designed

The model should have room where language and ambiguity are the problem. The program should take over where order, authority, or business invariants are the problem.

A Lead-Routing Path as a Hybrid Program

Use a small example:

request
  -> identify the lead
  -> ask for missing information if needed
  -> validate territory and regulatory status
  -> classify the routing reason
  -> calculate the allowed owner or queue
  -> assign, create task, and record evidence
  -> if an outbound message is requested, confirm and check consent before sending

The first and fourth steps may benefit from reasoning. The second step may use reasoning to ask a natural question, but the definition of “missing” should come from a deterministic check. Territory and regulatory status should come from authoritative actions, not from the model’s guess. Assignment should run only after the policy result is known. The outbound message should be a separate capability with its own confirmation and consent rules.

An illustrative shape is enough to reveal the boundary:

start_agent
  -> load lead context
  -> if required fields are missing, ask for them
  -> run verify_territory
  -> if restricted, transition to compliance_review
  -> run calculate_route
  -> run assign_lead and create_follow_up_task
  -> verify committed assignment
  -> if notification is requested, confirm and check consent before notify_owner
  -> summarize assignment and notification status separately

This is not a claim about the exact syntax of a production script. It is a design test. If the team cannot say which lines must run every time, the agent does not yet have a trustworthy control flow.

In this example, confirmation gates the outbound message, not the assignment. A business that also requires approval for ownership changes should add a separate gate before assignment. If notification is declined or fails, the committed assignment remains a completed step, and the response should say so.

Reasoning resolves the request. Explicit logic owns policy and assignment, while outbound messaging follows its own confirmation and consent gate.

What Agent Script Executes Before Reasoning

Salesforce’s flow-of-control documentation makes the execution boundary concrete. The runtime resolves reasoning instructions in order, executing logic and assembling prompt text before sending the resolved prompt to the LLM. Writing a policy in prompt text and running a validation action in logic therefore give different guarantees.

Salesforce’s action-chaining pattern also lets one action’s output become a variable used as the next action’s input. For the lead-routing example, the verified lead identifier and policy result should be explicit inputs to route calculation. The design still needs an action contract that rejects stale or invalid state at assignment time; guaranteed ordering alone does not establish authorization or transaction safety.

Subagents Are Boundaries, Not Magic Workers

Salesforce documentation now uses subagents for the concept older material called topics. The terminology change is useful to note, but the architectural question is more important than the label.

A subagent can represent a bounded responsibility such as lead qualification, compliance review, or owner assignment. It can have its own instructions, variables, actions, and transitions. That makes it a useful reasoning and control boundary.

It does not automatically become a durable business process. A subagent transition may change the current reasoning path without creating a long-lived workflow record, an outbox, or a compensation plan. If the process must survive a user leaving, an integration retrying, or an approval waiting overnight, the durable state still belongs in an explicit workflow or data model.

Use a subagent to organize agent behavior. Use Flow Orchestration, a record-backed state machine, an event process, or an external coordinator when business work has to survive time and failure.

What Should Remain Explicit?

The following responsibilities should not depend on a model remembering an instruction:

• whether required data is present;
• which record or customer is in scope;
• which source is authoritative for a fact;
• whether a policy allows the proposed action;
• whether a confirmation or approval is required;
• which steps must happen in order;
• whether an action is safe to retry;
• what counts as a committed result; and
• when the agent must stop and hand off.

The model can explain a denial, ask for a missing value, summarize evidence, or choose among low-risk retrieval tools. It should not be the only place where a denial rule or a side-effect precondition exists.

This is not an argument for writing every conversation as a giant decision tree. Excessive explicitness makes the system hard to change and can force natural language into brittle branches. The goal is to draw the line around consequential state transitions.

Failure Modes

The prompt describes a rule but does not enforce it

“Never route restricted leads” is useful guidance, but it is not a policy gate if the action can still run with an unverified lead. The action should recheck the condition.

The model is asked to remember sequence

If assigning an owner before validating territory creates a compliance problem, expose the sequence as logic. A tool description is not a transaction plan.

A transition is mistaken for durable state

Moving from one subagent to another does not by itself create recovery after a timeout. Persist business state when the process must resume.

Every tool is available everywhere

An action copied into several subagents can drift in description, inputs, or confirmation behavior. Define a capability contract and test each exposure.

The agent reports intention as completion

“I routed the lead” may mean that the model selected an action, not that the record committed. Return the actual record state and any pending external work.

A Control-Flow Review Checklist

Question	Design evidence
What may the model interpret?	examples of acceptable ambiguity and expected clarifying behavior
What must run deterministically?	validation, policy, action order, and invariant checks
Where is state held?	variables for the session; records or workflow state for durable work
What happens on a failed action?	explicit branch, retry policy, human handoff, or terminal error
What needs confirmation?	side effects, sensitive changes, external messages, and irreversible work
What proves completion?	committed record state, external acknowledgement, or reconciliation status

Agent Script is valuable precisely because it allows these modes to coexist. The team should use that capability to make the boundary visible, not to hide a deterministic process inside a conversation.

Build It Once

Write a control-flow card for one Salesforce operation before exposing it through a conversation:

operation:
record_scope:
model_may_interpret:
required_facts_and_sources:
deterministic_action_sequence:
action_inputs_and_output_variables:
policy_and_approval_gates:
session_state:
durable_state_and_resume_point:
failure_retry_and_handoff:
committed_result_and_verification:
optional_external_work_and_status:

For lead routing, bind the operation to a verified lead ID, calculate an allowed owner from authoritative policy inputs, and keep notification status separate from assignment status. Record which action can be retried and which state must be rechecked before a retry.

Review that card against three cases: a missing territory, a restricted lead, and a notification timeout after assignment commits. The first should trigger clarification without assignment, the second should stop or hand off, and the third should report the completed assignment and unresolved delivery separately. A useful conversation and a correct state transition need separate evidence.

What the Platform May Absorb Next

The platform may eventually generate more of the control flow from capability definitions, policy metadata, and observed outcomes. It may infer a useful route through standard actions, preserve context across channels, and coordinate more of the handoff between agents and workflows.

That future does not remove the need for explicit boundaries. It raises the value of typed actions, declared side effects, versioned policies, durable state, and outcome evidence. The more of the path the platform can assemble, the more important it becomes to show which pieces were selected, which were enforced, and which remained uncertain.

Will the Term Survive?

Terminology durability: Agent Script and subagent are current Salesforce terms and may evolve with the builder and runtime.

The durable idea is hybrid control flow: model reasoning inside a program that makes authority, state, sequencing, and completion explicit.

Where It Fits in the Map

This post extends the series from the agentic surface to the internal boundary between interpretation and execution:

intent
  -> model interpretation
  -> explicit state and transition
  -> authorized capability
  -> deterministic side effect
  -> verified outcome

The next post asks what information should enter that path. A useful context is not the largest profile available; it is a decision-ready view.

Sources

• Salesforce Developers: Agent Script Language Characteristics
• Salesforce Developers: Agent Script Flow of Control
• Salesforce Developers: Agent Script Reference: Actions
• Salesforce Developers: Agent Script Pattern: Action Chaining and Sequencing

More in This Series

• Post 01: How Salesforce Applications Evolve with AI
• Post 02: What AIforce and Agentforce Add to Salesforce
• Post 04: What Does an Agent Need to Know Before It Acts?