Best Practice: Using variables with LLMs and ZVA

Ever tried to prompt and get the LLM to gather details from the customer and then use that to make decisions? Has it ever failed? That’s because your architecture for how variables and LLMs interact might need a refresh. 

Best practice 1: Always use a tool to set the variable and then actually map it to a real global custom variable. Yes, it takes longer in the beginning but it’s worth it for the consistency in experience. 

Best practice 2: Create a set of 10 “backup” custom variables for you to use as placeholders while you build. You can then come back and rename them to the correct value they represent or exchange them with a new variable. This helps keep you in the habit of actually mapping to a variable field, saves time while you build, and let’s you be more creative with your UX design. Keep a list of what you used the “backup” variables for and always go back and rename them or make new variables to switch out. 

Best practice 3: Don’t just prompt a reference to a variable. Actually insert the variable reference in your prompt by using the “insert” button or “/.” This will separate your variable as an actual slot to be filled versus more tokens of text. You will get more consistent results and better debugging capabilities for when the variable is not saved or used as expected. 

Best practice 4: When in doubt, use a string-type variable. We have many different variable types, but when you are collecting information from a user try to use string-variables and make decisions off their values to better anticipate customer errors and still get them to the correct spot. For example, instead of using the boolean field for a “yes/no” or “true/false” question, simply prompt the criteria in the tool and give the agent the values to populate based on the conversation. For example: You can use a boolean field type for “New Customer” where true = new customer and false = current customer. A better way to do this is to create a variable that is a string-variable type and list “new” for new customers, “current” for current customers and “unknown” if unknown. This allows for edge-cases, failures and ensures that no customer is left unserved because your boolean variable was too strict in constraints. 

Best practice 5: When reylying on context to fill in a variable - the probability of hallucination exponentially grows. Tool on the contrary has significantly lower probability of hallucination. The general guidance is to rely less on context. additionally tool ensures the value is saved in that specific variables memory space. Additionally - when you prompt variable slots/namespace instead of using a tool and referencing the variable with the “insert” feature, your customer context goes through stages of processing. When relying on context and specifying a variable outside of the tool - the LLM does not know the item with the namespace is actually a variable - it will not go and write into the memory assigned to the variable.

Hopefully this helps you to create a more robust, consistent, and error-handling savvy AI virtual agent experience!