Agent Script: why business rules don't belong in the LLM

Credit limit checks, warranty eligibility and price approvals belong in Agent Script logic, not in the judgement of the language model. Since February 2026 the new Agentforce with hybrid reasoning is generally available: logic instructions execute as code, and the LLM is only called where you write prompt instructions. Use that split deliberately. A rule the model interprets can take a different path on the same input, and “the agent decided” does not hold up in an audit or a dispute with a dealer. Let the rule decide, and let the LLM understand the request and explain the result.

What is hybrid reasoning in Agent Script?

Hybrid reasoning means one agent combines deterministic logic with LLM reasoning. Salesforce Architects describes the earlier Agentforce model plainly: the LLM made every decision at runtime, “with no guaranteed path through the workflow”, so identical inputs could take different routes. The architecture guide on hybrid reasoning1 sets one rule against that: “if you can express a decision as code, it should be written as logic.”

Agent Script is the declarative language that implements this. It has two kinds of instructions. Logic instructions, such as conditions and action calls, run as code with no LLM involved. Prompt instructions are natural language for the model, and each one triggers an LLM call. A compiler turns the script into an Agent Graph, and the Atlas Reasoning Engine executes it as a state machine. According to the same guide, the new Agentforce has been generally available since February 2026.

For existing agents this is not optional for long. Salesforce wrote in July 20262 that development on the legacy builder is frozen and that new agents can only be created in the new builder. There is no end date yet, but every new agent you commission is an Agent Script agent.

Why do credit limits, warranty and price approvals not belong in the LLM?

Because these are decisions with a right answer. A dealer is over the credit limit or not. A machine is under warranty or not. A discount needs approval or not. I see four reasons to keep them out of the model.

Audit and disputes. A dealer whose warranty claim was rejected will ask why. The guide calls non-deterministic execution an audit gap, and I agree. A rule in code gives the same answer on Tuesday as on Monday and can be traced. Agent versions are also stored as metadata: the AiAuthoringBundle3 keeps versioned folders, so you can show which rule version was active.

The rule already lives somewhere. In manufacturing, the credit limit and the exposure sit in SAP or proALPHA. Warranty terms sit in Manufacturing Cloud or in the ERP. Price conditions sit in the ERP or in CPQ, a choice covered in customer prices: SAP conditions or Salesforce Pricing?. An agent should read the result of that system, not rebuild the rule in a prompt. Two places with the same rule drift apart, and the prompt version is the one nobody tests.

Cost and latency. The guide states that “every unnecessary LLM call adds latency, cost, and variability” and that a simple conversation used to need at least three LLM cycles. Each calculation you move into logic is one less place where the model can go wrong.

Untrusted input. Dealer portals, warranty forms and emails are written by people outside your company. If a rule depends on the model’s reading of free text, that text can push the model. I cover this in prompt injection through dealer portals.

How Agent Script enforces a rule

Four building blocks matter for a decision maker. Your partner should be able to show you where each rule sits.

• Conditionals in the reasoning block. According to the Agent Script docs4, if and else are evaluated before the prompt reaches the LLM, and only the matching instruction is sent. The model never sees the branch that does not apply.
• available when. A condition on an action. When it is false, the action is completely hidden from the LLM5 and cannot be called. That is the gate for “create order” or “approve claim”.
• before_reasoning and after_reasoning. before_reasoning runs deterministically at the start of every parse, for authentication, entitlement checks and loading context. after_reasoning runs after the model, for checks and transitions. A parse happens on first entry, after every tool call and on every user turn.
• Escalation. @utils.escalate hands the conversation to a human service rep6 through Omni-Channel.

A simplified sketch of a credit gate for spare part orders, in plain words:

Three details in the guide are worth asking your partner about.

For developers

Gate variables, the guard and is_displayable

• Code sets the gate variables. If the LLM sets them, "you've reintroduced the variability the gate was designed to prevent."
• The guard matters (if @variables.credit_checked == False). Without it the ERP lookup in before_reasoning runs on every parse, so several times per turn, and every run is an ERP call.
• is_displayable ends the loop. Such an action ends the reasoning loop as soon as its output is shown, and after_reasoning is skipped. A check placed there then never runs.

Worked example: a dealer agent for spare parts and warranty

Assume a machine builder with SAP, Sales Cloud, Service Cloud and a dealer portal. The numbers are assumptions to show the method. The agent handles 800 spare part orders and 150 warranty pre-checks a month, and it touches credit limit, warranty and price approval.

Credit limit. SAP credit management decides. A MuleSoft API returns a flag per dealer, as described in Agentforce and SAP order status. The agent reads it once per session and gates the order action. Assume 4 percent of dealers are blocked at any time: for them the model explains that credit management has to release the order and offers to forward the request. It never sees an order button.

Warranty eligibility. Assume the rule is 24 months from installation or 5,000 operating hours, whichever comes first. The model’s job is to collect the serial number and the fault description from free text. A Flow or Apex action then reads the asset warranty and returns eligible, not eligible or data missing, plus a reason. The model words the answer. If the installation date is missing, the result is “data missing” and the case goes to a person, not to a guess. How Manufacturing Cloud models the warranty is in warranty claims from dealers, and the Winter ’27 agent for this check in the warranty claims adjudication agent.

Price approval. Assume dealers may get up to 8 percent extra discount on spare parts without approval. Above that, the agent does not negotiate. A Flow starts the approval for the sales manager, and the model tells the dealer that the request is with sales. The threshold sits in one place, maintained by sales, not in a sentence in the prompt.

What remains for the model is the part it is good at: understanding “the hydraulic pump on our machine from 2023 leaks again” and turning it into a serial number lookup and a fault category.

What stays with the LLM?

More than it sounds. The model recognises intent, fills required inputs from free text, summarises a case for a technician, explains a rejection politely in the dealer’s language and decides when a conversation needs a human. Gartner recommends using agents when decisions are needed7 and automation for routine workflows. I read that the same way: the judgement about what the dealer wants belongs to the model, the rule that follows belongs to code.

Agent Script is also not always the right place for the rule itself. If the rule has many variants, such as warranty terms per product family and part, it belongs in the data model or in the Business Rules Engine, which the Manufacturing Cloud page8 lists for claims, rebates and quoting. The script then calls it. If the ERP owns the rule, the script calls the ERP. Agent Script decides when a rule is checked and what happens with the result.

List every decision before your partner builds

Before your partner starts building, I would go through these steps:

1. 01

   List every decision

   Collect every decision the agent touches and mark the ones with a right answer.

2. 02

   Name the owning system

   Record for each rule where it lives: ERP, Manufacturing Cloud, Business Rules Engine or Flow.

3. 03

   Define the gates

   Which action is available under which condition, and which code sets the variable?

4. 04

   Define "data missing"

   Its own result that goes to a person.

5. 05

   Test the rules like code

   With cases on both sides of every threshold, as described in testing Agentforce agents before go-live.

This is the part of an agent design I review on the client side as part of Salesforce architecture, because it decides whether the agent can be audited later. Whether your process is ready for an agent at all is covered in Agentforce for manufacturers: start now or wait.

Sources8

1. 1architecture guide on hybrid reasoning (opens in a new tab)architect.salesforce.com
2. 2July 2026 (opens in a new tab)salesforce.com
3. 3AiAuthoringBundle (opens in a new tab)developer.salesforce.com
4. 4Agent Script docs (opens in a new tab)developer.salesforce.com
5. 5completely hidden from the LLM (opens in a new tab)developer.salesforce.com
6. 6hands the conversation to a human service rep (opens in a new tab)developer.salesforce.com
7. 7when decisions are needed (opens in a new tab)gartner.com
8. 8Manufacturing Cloud page (opens in a new tab)salesforce.com