Agent Script Pattern: Enforce Business Rules with Filters

Use available when to control which subagents or actions are available to the LLM. If the conditions aren’t met, the LLM can’t access the subagent or reasoning action (also described as a tool in the developer guide).

Why Use This Pattern 

When your business conditions aren’t met, this pattern allows you to hide the subagent or action entirely, simplifying the LLM’s decision-making and enforcing business rules about feature availability. Without filtering, customers might convince the LLM to use features that aren’t allowed. Or, the LLM might make reasoning errors during complex workflows and prolonged conversations, due to prompt noise and context drift. See Required Subagent Workflow for a related pattern.

Pattern Examples:

  • Only enable the create_return action when the order is within the return window and verified—otherwise, hide it completely from the agent.
  • Only enable the escalate subagent for verified customers during business hours.

Filter Subagents 

Control which subagents are available based on whether the user is verified.

Filter Subagents by Verification Status
1start_agent agent_router:
2  description: "Welcome the user and determine the appropriate subagent"
3
4  reasoning:
5    instructions: ->
6      | Select the best tool to call based on conversation history and user's intent.
7
8    actions:
9      go_to_order: @utils.transition to @subagent.General_Info
10          description: "Gives general information about products."
11      go_to_order: @utils.transition to @subagent.Order_Management
12          description: "Handles order lookup, refunds, order updates."
13          available when @variables.verified == True
14      go_to_escalation: @utils.transition to @subagent.Escalation
15          description: "Handles escalation to a human rep."
16          available when @variables.verified == True and @variables.is_business_hours == True

In this example:

  • All users can access General Info.
  • Verified users can be routed to the Order Management.
  • Escalation requires verification and valid business hours.

Filter Actions 

Make actions available only when business rules are satisfied.

Filter Actions by Eligibility
1reasoning:
2  instructions: ->
3    | Refer to the user by their name {!@variables.member_name}.
4      Show the user their order summary: {!@variables.order_summary}.
5      If the user wants to make a return, confirm their order ID and
6      call {!@actions.create_return}. If returns are not eligible,
7      explain why.
8
9  actions:
10    create_return: @actions.create_return
11      available when @variables.order_return_eligible == True and @variables.order_id != None

Keep in mind that the LLM can call any available reasoning action, even if you don’t explicitly tell it to.

Note

Tips 

  • Protect against customer manipulation: Filter business-sensitive features. Don’t only rely on prompt engineering.
  • Use parentheses when nesting and / or conditions: Using parentheses makes it clear which operations are evaluated first, and keeps your script maintainable.

Related Topics