Conditional Templates
Conditional Templates allow you use saved values from API Calls to change the instructions on a given task.
GenerativeAgent uses the conditional templates to render API and Prompt instructions based on the conditions and values in each template.
Conditional Templates must be referenced in Jinja2 templating language conditional statements. Head to the Jinja Documentation to dive further into Conditional Statements
Write Conditional Templates
Conditional templating supports rendering based on the presence of some data in an API Response Model Action.
This data is pulled at run-time from the input model context (list of ModelActions) and stored in reference variables that can be used in Jinja2 conditional statements.
If you want to render based on ModelActions that are not API Responses, it will require further help from your ASAPP Team.
Write a Conditional Template:
- Identify the Function and the keypath to the value from the API response you would like to conditionally render on.
- Add a reference var to a list of reference_vars on the Function in the company’s functions.yaml. It should include name and response_keypath at minimum, with the response_keypath format being response.<your_keypath>. You can optionally define a transform expression with val as the keypath value to be transformed . Note that these reference vars are used across the company’s Tasks, so the name parameter needs to be unique.
- Leverage the conditional in two places by pulling from vars.get(“my_reference_var_name”): In a Task, you can add Jinja2 conditional statements in the prompt_instructions and define conditions for each of the TaskFunctions, so they only render when it evaluates to True. Conditions on TaskFunctions are optional, and functions will always render in the final prompt if there are no conditions provided. In a Function, you can add Jinja2 conditional statements to the Function’s description
Use Case Example - Mobile Bill
What this use case example accomplishes is to make GenerativeAgente behave as follows:
- If CPNI compliance is unknown, only render the identity API without its description about checking the response field “data[‘cpniCompliance’]”, and render in the prompt_instructions that tell the LLM it must first confirm the customer is CPNI compliant.
- If a customer is not CPNI compliant, only render the identity API with its description about checking the response field “data[‘cpniCompliance’]”, and do not render in the prompt_instructions that tell the LLM it must first confirm the customer is CPNI compliant.
- If a customer is CPNI compliant, do not render the identity API and render the APIs that require CPNI compliance instead, and do not render in the prompt_instructions that tell the LLM it must first confirm the customer is CPNI compliant.
Was this page helpful?