State Transitions: transition to @StateName
Example: transition to @UserBusy
What it does: This command immediately stops processing the current state’s instructions and transfers the conversation to the specified state (e.g., UserBusy).
Why it’s structured this way: It promotes modularity and reusability. Instead of repeating the same logic (like how to handle a busy user) in multiple places, you create a specialized state and transition to it whenever needed. This keeps your prompts clean and easy to maintain.
Variable Updates: update @variable_name to value
Example: update @disposition_comment to customer busy
What it does: This command silently updates a variable in the background with a new value. The user is not aware that this is happening.
Why it’s structured this way: It allows the agent to record information for logging, analytics, or later use in the conversation (e.g., @late_reason as “no job”). Keeping this action silent maintains a natural conversational flow without telling the user “I am now updating my records.”
Using Tools: call @tool_name
Example: call @date_validation_tool
What it does: This command pauses the conversation to execute an external function or API, such as validating data or querying a database.
Why it’s structured this way: It allows the agent to perform complex tasks that go beyond language generation, ensuring data is accurate and structured before proceeding.
Ending the Interaction: end_interaction
What it does: This is a flag that tells the system to terminate the call after the current turn is complete.
Why it’s structured this way: It provides a clean, controlled way to end the conversation. You will often see the structure first end_interaction and then say "...". This is crucial because it instructs the system to queue the call for termination before delivering the final sign-off message. This ensures the final words are not cut off and the agent doesn’t try to listen for another user response.