Last updated: 1 Oct 2020
If you didn’t know, the folks at Google recently introduced Dialogflow CX, which is meant for developing large or very complex agents. The older version of Dialogflow has been renamed to Dialogflow ES (short for Essentials), and is more suited to develop small and simple agents.
You can also find a comparison chart on this page.
What my peers think
There was the usual hype and self-congratulatory tweets when CX was released, but I am more interested in the opinions of my peers.
It didn’t take me long to confirm what I was already thinking.
Here is a tweet from Allen Firstenberg, who has been working with Dialogflow for quite a while (and is one of the folks who regularly answers Dialogflow questions on StackOverflow).
I second that view. As it stands today, Dialogflow CX is far, far from “typical beta quality”. Dialogflow CX should still be in the lab and should not have been made public till end of 2020 at least, I think. 🙂
Here are the limitations which are already listed on the Dialogflow CX page.
While I am not a fan of knowledge connectors as it stands today, the rest are important requirements.
Till date I have directly worked only on English language chatbots. But enough people use my BotFlo app (which creates an FAQ chatbot from a CSV file) in non-English languages that I presume there is a fairly large user base for Dialogflow in non-English languages too.
The system entity extension allows you to add names which aren’t already understood by Dialogflow.
The History tab lets you quickly check whether a given bot is being actively used, and the Training data import is of course a simple way to make your agent smarter.
Here is more proof. See how many of these have the “beta” lab icon.
That’s nearly all the features in Dialogflow CX. 🙂
No working built-in integrations
Yes, there are telephony integrations, but that’s a pretty small fraction of all Dialogflow use cases.
Now contrast this with using Dialogflow ES for your website, where there are 7 types of integrations!
I have created a tutorial explaining how to create a custom integration for Dialogflow CX.
Let us look at the important technical differences in Dialogflow CX. In my view, Dialogflow CX is also something of a paradigm change in how we approach conversational AI, but more on that in a future article.
Also, the list of items below is only a preliminary list based on what I have seen so far. The actual list of differences is likely to be much larger.
Visual State Machine
People who comment on Dialogflow CX sometimes say “Finally Dialogflow has a visual builder”.
This statement is obviously incorrect. Dialogflow has always had a visual builder, in fact that was its biggest differentiator. Here is what a reader wrote to me in Nov 2018 about the LUIS/MS Bot Framework when compared to Dialogflow.
Remember that this was November 2018. Already there was a comparison between the visual builder in Dialogflow ES and the other bot frameworks (by the way, things have evolved today).
What has changed is that Dialogflow CX introduces a Visual State Machine. It is a concept which does three things in my view
- it makes Dialogflow even more powerful for modeling conversational AI
- it makes the learning curve steeper for non-programmers (and programmers, probably)
- it will soon force other bot frameworks to evolve in the “state machine” direction or be left behind
To hedge my bets, I am going to add a clause here. It is also possible that Dialogflow somehow doesn’t execute properly on this vision and botches everything. And everyone decides conversational AI is just too hard in practice, and the entire industry loses interest and moves on to the next thing 🙂
No input and output contexts
The visual dialog builder I talked about in the previous paragraph was powered by the concept of input and output contexts. In fact, that is how followup intents allow you to “move the conversation forward” and allow for followup messsages/questions from your user. Dialogflow CX completely eliminates the concept of the input and output contexts in favor of the Visual State Machine.
Slot filling incorporates retry handling
If you have been following my material, you know that I actively discourage using slot filling in Dialogflow ES.
But this was because there was no thoughtful retry handling*, and thankfully that has now been changed.
Session level parameters
When you collect user input, you need some way to keep track of what information they provided in prior steps (conversation turns). By default, Dialogflow ES encouraged people to use a large context lifespan for this purpose, which caused problems with managing the conversation flow. Which is why I recommended people use a context lifespan of 1 and create dedicated session variables to keep track of user input. Session level parameters are now built into Dialogflow CX automatically.
This is a complex topic all by itself. For now you should understand that you can reuse intents in Dialogflow CX, which will allow you to manage more complex flows without too much duplicate data entry.
Let us now look at what is probably the most interesting aspect of Dialogflow CX. 🙂
There is no free tier, and the paid tier costs $20 per 100 chat “sessions”. Not per 100 requests, and it is an important distinction. A session is a group of up to 40 requests. However, after 40 requests, it starts a new “session” and will cost you 20c more.
There is some confusing terminology in the documentation which makes it sound like console usage would count towards your quota, but I think a session is explicitly defined as a conversation between an end-user and a Dialogflow agent, so I suppose console usage isn’t considered a “session”. From what I have seen till now, I haven’t been billed for the tests I have done inside the console. 🙂
Also, I believe that if you used two different sessionIDs in back to back API requests, that automatically becomes two different sessions and costs 40c. So that’s certainly something worth thinking about as you build your custom integrations (i.e. consider reusing the sessionID if it works and also makes sense for your use case).
18 September 2020: This is the page where I got this information, but it looks like it has already been updated since my last screenshot. Notably, the section about a conversation Session has been deleted, so remember that this is still a Beta product and all these things (including documentation) are subject to change 🙂
So this has a couple of implications:
Even if you are new to Dialogflow and don’t have to worry about migration, you probably want to start with Dialogflow ES, if only to see how far you can go with ES before migrating to CX.
Sorry, my earlier calculation (see below ⬇ ) was completely off!
Thanks to David Osborne for pointing this out in the comments.
Let us consider the pricing for text requests. CX costs at least 0.5c per request, and ES costs at most 0.002c per request. That is, CX is at least 250 times more expensive as of today.
Let us consider the pricing for text requests. CX costs at least 0.5c per request, and ES costs at most 0.2c per request. That is, CX is at least 2.5X more expensive as of today.
So CX is potentially only 2.5X more expensive.
- This means my original calculation and resulting tweet (see below) wasn’t accurate
- But the ES free tier was so generous – maybe too generous – that very few bots actually incurred any cost. When the denominator tends to zero, even a small numerator drives the ratio towards infinity!
- Google is a for-profit business, and they should charge enough to keep the business or business unit commercially viable. Offering an overly generous free tier doesn’t help, and possibly kills future innovation too.
- But, they also need to take more responsibility for support once they start charging. In the case of Dialogflow support, it has usually been “you get what you pay for”.
I don’t envy the folks who are in charge of deciding on and setting these prices. 🙂
CX is really geared towards use cases where you can be quite certain there will be a lot of back-and-forth in the conversation, as it will be really expensive for one-and-done FAQ bots. That’s basically what it says in the documentation, except that the documentation says “small” and simple vs “large” and complex. For the use case where you have a LOT of intents in your one-and-done FAQ bot, it can also be a “large” but simple bot.
Update Sep 16th: A couple of clients mentioned that the pricing seems quite high, so I asked the Google developer evangelist about it on Twitter.
Here is the official explanation:
I realized that the order of the tweets makes it a little hard to read, so here is the actual sequence, which you can notice in the timestamps.
Is Dialogflow CX an improvement over Dialogflow ES?
Short answer: On a purely technical basis, yes.
Long answer: it depends on a few factors. It is still early days, but there are three aspects which already stand out with Dialogflow CX.
How complex is your bot?
If your bot is not very complex, Dialogflow ES will do just fine.
On the other hand, if you are already using the Mega Agent feature, you should definitely look into Dialogflow CX.
For one, the Mega Agent feature has some limitations.
Second, if you need a Mega Agent, you already have a complex bot.
Exception: you have a “simple” bot which uses only slot filling to do its entire work. But it also frequently enter into loops. In that case, you will get the benefit of retry handlers if you use CX.
Who are the end users?
From the pricing, and the learning curve involved, it would seem that Dialogflow CX is best suited for internal facing bots.
Internal facing bots have three major benefits you don’t get with external facing bots
- easier training for the end user
- no expectation of spam (and thus unnecessary costs and wasted effort)
- much higher probability of compliance – where the end user follows the suggestions from the bot
If your bot is external facing, you will probably be better off starting with a ES bot and only migrating to CX once your bot gets sufficient usage.
If you are on a tight budget, CX isn’t a good option. As of date, there isn’t a free tier, and there are no built-in integrations for non-telephony bots. This means you need to hire a developer to not only build out the integration, but also to maintain it as the API is still in Beta and might change over time.
What if Dialogflow ES is deprecated in the future?
I think there was something of an “official” take on this from the tweet thread before:
Obviously, if you are building a telephony integration, just ignore everything I have written in this article and consider using Dialogflow CX.
For the others, it would be best to wait and watch for a few months.
*Looping blindly and indiscriminately with bigger and better prompt variants does not count as thoughtful retry handling 🙂
- 3 ways to pass parameters between intents in Dialogflow ES
- Do this when Dialogflow ES matches the wrong intent
- How to bulk upload intents from a CSV file in Dialogflow
- How to move bot from Dialogflow CX to Dialogflow?
- Understanding Dialogflow service account roles and their use cases
- Course Discounts
- How to debug Dialogflow Python webhook using ngrok
- EU VAT MOSS Tips for online course creators
- How to integrate Dialogflow into your Flutter app
- Get your DialogFlow agent to initiate the conversation before user types a message