Route and Gate Conversations with Agent Script
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the role of start_agent as the router that runs on every conversation turn.
- Determine the appropriate transition type (LLM-based or deterministic) to meet specific routing requirements.
- Explain how an available when clause hides tools from the LLM and why that's more reliable than prompt instructions.
- Apply the required flow pattern to guarantee a prerequisite step.
Recall the Router You Edited
In the last badge, you opened the Agent Router in Script view and added an instruction so the agent would route to Experience Management when a customer provided their email and membership number. That Agent Router is the CC Service Agent's start_agent block—and it's worth understanding deeply, because it runs on every single message, no matter whether it’s the first message or fiftieth.
The router's job is to read the customer's intent and send the conversation to the right subagent. Check out this example of a router in Agent Script.
start_agent agent_router:
description: "Welcome the customer and route to the right subagent."
reasoning:
instructions: ->
| Welcome the customer to Coral Cloud Resorts and determine
the best subagent for their request.
actions:
go_to_experience: @utils.transition to @subagent.Experience_Management
description: "Helps customers explore experiences, book sessions,
and rewards loyalty members with resort credits."
go_to_faq: @utils.transition to @subagent.General_FAQ
description: "Answers common questions about the resort and amenities."Each item under actions is a transition exposed as a tool. The LLM reads the descriptions, decides which one matches the customer's request, and calls it. The quality of those descriptions is what makes routing reliable—which is why the next sections matter.
Two Ways to Transition
Agent Script gives you two syntactically different ways to move between subagents, and the difference is the whole game.
Option 1—LLM-Based Transition
Define it under reasoning.actions. The LLM reads it as a tool and chooses whether to use it. Note the @utils. prefix in this example.
reasoning:
actions:
go_to_experience: @utils.transition to @subagent.Experience_Management
description: "Helps customers explore experiences and book sessions."Option 2—Deterministic Transition
Write it directly in reasoning.instructions, behind a condition. It fires immediately when the condition is true, before the LLM reads anything. Note there's no @utils. prefix in this example.
reasoning:
instructions: ->
if @variables.LifetimeValue >= 50000:
transition to @subagent.VIP_ConciergeThat prefix difference—using @utils.transition to as a tool versus a bare transition to in instructions—signals two very different behaviors. Deterministic transitions guarantee routing. If the condition is met, the customer goes there, and there’s no LLM vote. LLM-based transitions are a suggestion the LLM can take or leave. Use deterministic transitions sparingly—only when you truly need guaranteed routing—and let the LLM choose the rest of the time.
One rule applies to both because transitions are one-way. When a transition fires, Agentforce discards whatever prompt was being assembled and starts fresh in the new subagent. Control doesn't bounce back.
Filter with an Available When Clause
Remember when you filtered the IssueResortCredit action so the LLM couldn't even read it unless the customer was eligible and hadn't already gotten a credit? That filter is called an available when clause. In Script view, it reads almost like a formula.
reasoning:
actions:
IssueResortCredit: @actions.IssueResortCredit
description: "Issue resort credit using the ContactId and provided amount."
available when @variables.isCreditIssued == False and @variables.LifetimeValue >= 25000When the condition of an available when clause is false, the tool disappears entirely from what the LLM can read. The LLM can't pick it, and most importantly—a persuasive customer can't talk the LLM into using it either. As you learned in the previous badge, even if a customer insists they deserve another credit, the agent physically can’t access the action.
That's why using an available when clause beats writing "never issue more than one credit" in your instructions. Prompt instructions are guidance the LLM usually follows. An available when clause is a hard gate it can't cross. For example, you can filter transitions the same way—hide go_to_order until a customer is verified.
go_to_order: @utils.transition to @subagent.Order_Management
description: "Handles order lookup, refunds, and updates."
available when @variables.verified == TrueThe Required Flow Pattern
Filtering removes options. Sometimes you need to do more—to force a customer through a required step before anything else can happen. Think of identity verification. The CC Service Agent shouldn't do anything for a customer until it knows who they are.
That's the required flow pattern, a deterministic transition at the very beginning of the router's instructions.
start_agent agent_router:
reasoning:
instructions: ->
if @variables.verified == False:
transition to @subagent.Identity_Verification
| Welcome the customer and determine the best subagent for their request.
actions:
go_to_experience: @utils.transition to @subagent.Experience_Management
description: "Helps customers explore experiences and book sessions."
available when @variables.verified == TrueIf verified is False, the transition fires immediately. The LLM never reads the subsequent welcome prompt, and the transition tools aren’t available. The customer lands in Identity_Verification and stays there until they're verified.
Placement matters. Put the deterministic transition first. Anything above it—logic, actions, prompts—runs before the transition fires, and then gets thrown away when the transition happens. That's wasted latency, and if you ran an action, you possibly wasted cost.
Approach | Use it when |
|---|---|
available when | You want to remove an option when conditions aren't met, the LLM still chooses among what remains. |
Deterministic transition (required flow) | You must guarantee a customer completes a prerequisite step, no LLM choice is involved. |
Write Descriptions the LLM Can Route On
Whether you're filtering or letting the LLM choose, routing quality lives in your subagent and transition descriptions. Vague descriptions produce inconsistent routing.
Too Vague
Vague descriptions make LLMs have to guess.
go_to_experience: @utils.transition to @subagent.Experience_Management
description: "Experience stuff."Specific
Specific descriptions let LLM route reliably.
go_to_experience: @utils.transition to @subagent.Experience_Management
description: "Helps customers explore experiences, look up activities and
sessions, book reservations, and rewards loyalty members."And keep the go_to_ naming convention that’s in the CC Service Agent (go_to_Experience_Management). It makes the script readable and signals to the LLM that the tool navigates to a subagent.
You can now route conversations deterministically, gate tools and subagents behind conditions, and force a prerequisite flow—the pro-code version of the action filtering you did in the Salesforce UI. In the final unit, you handle the hardest routing problem of all—keeping an agent on track across a long, multi-turn conversation.