Using Intents to structure multi-turn conversations

What are Intents on Hu:toma AI? 

Intents are a way for a user to communicate their desired action to our system.   Intents can be expressed by a user in multiple ways and these are grouped together in the User Says section of an intent. 

To use a simple example:  Imagine someone wants to book a flight, “booking a flight” is their intent. How might they express that and tell our system that’s what they want to do? 

A user might say.

User Says

“I want to book a flight” or “Can I check flights”.  You would write these in the User Says section of the intent.  

Now in order to start a search for flights on most booking platforms, more information is required. For instance, where you’re looking to travel to.   


In order for a user to communicate where they’re looking to travel to the system will need to recognise Airport names.  In order to do this you would create an Entity category called “Airports” and within that you would add the individual Airport names, these are called Entities on Hu:toma AI.   

To instruct the system to look for Airport names with the User Intent we must make it mandatory.   

If a user doesn’t add the Airport name in their intent then the system will prompt for it.  

You can define the prompt, how many times the system should prompt, whether the intent is required, and an intent label so the entity can be identified. 

In our example we’re also looking to capture further information about the desired flight, “Where is the user flying from?”,  “For how many passengers?”, “on what date do they want to travel?”, and "is it a single or return journey?"

You can see how we have set up ours here: 

Now in the scenario where this is a one way journey we have now collected all the information we need but in the scenario this is a return journey we also need to capture the date of the return flight. In order to do this we need to branch the conversation.

Clear on Entry

Clearing on entry allows you to remove any entity value that has been stored in memory prior to entering the intent.  This means the bot will prompt for an answer even if it has until this point stored a value for this entity in memory.  To use this feature simply drop a tick in the checkbox.  

In this scenario if the box were ticked then even if there had a been a value stored for airport_destination then it would be cleared and the prompt still asked

Entity Persistence - choosing how many interactions an entity remains in memory

You may want to choose how long a particular entity that has been detected from the conversation remains in memory.   If you don't add a value it will by default be kept in memory forever unless it gets cleared by the "Clear on Entry" function of when the intent or another that uses this entity value is triggered.  

Alternatively you can choose the number interactions that this remains in memory by entering a value into the field.  An interaction is one response from a Hu:toma bot.  

Follow-up Intents

The way we do that is by creating additional intents.  

One for One Way journey & a second for a Return journey.  

We then need to link the Intents together,  we do this by using Follow-up intents 

We set the conditions which must be true to enter the follow-up intent.  

In our example the variable is book_flight.journey_type

If the variable equals One way then we move to “one-way journey” intent 

And if the variable equals Return then the user should be taken the “return journey” intent. 

Now we need to set up the additional intents. 

If a user is looking for a one-way-journey then we have all the info required and we should return a response like “We’ll start searching for single flights you” 

For a return journey we need to capture the date of their return journey.  We do this by creating another required entity.  This time using a pre-built system entity category

Once this has been captured we then tell the user “We’ll start searching for return flights for you”

We must add a dummy User says into each of the one way and return intents.  This intent shouldn’t be called directly by a user without first going through the conversation flow above. 

But what if you a user were to say your dummy User says then the intent would be called directly.   

How do we prevent that?

Context out

Here we can set the context of a conversation once an intent has been triggered.  

For instance here we use booking_started and set it to true once the intent has been triggered.  

Now return to the “One way” intent and look for the conditions section. 


Conditions gate an intent from being fired.  Unless these conditions are met then the intent cannot fire. 

In ourscenario we want to add a variable to the conditions of all the intents that are below the initial “book a flight”.  So both, one_way_journey and return_journey.

We set the variable booking_started must equal true in order for the intent to fire. 

You can also add a fallback response to indicate to the user that they cannot start the intent because previous intents have yet to be triggered.

Reset Context

Once a follow up intent has been triggered, it is important to reset the context of the conversation.

Otherwise once the full conversation flow had completed a user would be able to trigger intents further down the flow without entering via the top intent, meaning our user would be able to consistently jump to the return_journey intent without asking to book a flight and passing all of the relevant flight info to our system.   

How would you pass this information to a third party service or your own flight booking service?


You would do this through creating a Webhook. A webhook is essentially a bridge between our system and your custom business logic or 3rd party. When an Intent is fulfilled, the URL you specify will be called automatically passing the information captured from the conversation with the user including recognised entities.  

What did we just build?

As you build your bot you can test your bot whenever you like in the chat window to the right of the page.  Below the chat window are the chat logs in JSON format which you can use to debug your bot build and ensure you know which intents are firing, which entities have been extracted.  

Here's a screenshot of the conversation flow that we've just built taken from the chat window.  

How did we do?