I recently came across this question on the API.AI forum:
Now, this can be a little ambiguous, so the forum member clears it up with a followup comment:
Do you need a webhook?
So, the first question is: do you absolutely need a webhook to solve this problem? Put another way, can you avoid using a webhook?
If you frame the question as “How can I avoid using a webhook?” the answer becomes a bit clearer.
Split the entity
I have come to realize an interesting thing about API.AI – there is actually a tradeoff between the number of entities you are willing to create and the complexity of the eventual webhook code you will be writing.
To put it another way:
In the same thread, someone mentions that it is not possible to do this without using webhooks. In a sense, that is correct. But only if the original poster didn’t want to modify the way they defined their entities.
Defining Two entities
The thing I love about this example is that it is really a very simple way to frame this problem but it is not so simple that it becomes contrived.
So I start by defining two entities in the agent:
Defining the intents
Now that we have defined the entities, let us define two intents: one for handling MacOS, and the other for handling Windows.
The intent for email problems on Windows is very similar:
I have used the template mode here because it helps with stricter enforcement.
Testing the agent
Now, you can do a whole lot more than tamely replying with “Call Apple support” etc. For example, each intent could set different output contexts, and you can have entirely new conversation branches based on that. Or you could also simply create followup intents under these two intents and let API.AI do some of the grunt work for you.
For this simple example, we know now that if the bot responds with the appropriate response, we have achieved our goal of avoiding a webhook. The GIF below shows the web demo. And note that you should be able to replicate the results below by simply creating a new agent and adding the entities and intents I have shown (if you cannot do that for some reason, leave a comment on this post explaining what you see).
Extending this to the general case
This is why entity design for your chatbot is usually explicitly tied to intent design. If you wish to have a chatbot that you can reason about very clearly, I would suggest splitting your entities like this up to the point where you can have logical groupings (but don’t overdo it).
Of course, this means you would sometimes have more duplication in your intents. It is a tradeoff, but even if you don’t wish to split the entities like I am suggesting here, you should keep this option as another tool in your toolkit.
- Tips for learning Dialogflow CX
- Dialogflow CX vs ES: First look
- Seven ways to integrate a Dialogflow chatbot into your website
- Dialogflow Zobot: Selection Triggers the next intent
- Dialogflow Architecture
- Dialogflow Python webhook tutorial
- Dialogflow training
- Dialogflow vs Lex vs LUIS vs Watson vs Chatfuel
- Convert your WordPress website into a Dialogflow FAQ chatbot
- When NOT to use follow up intents in DialogFlow