Google Dialogflow has introduced Dialogflow CX in December 2020. It is a powerful tool to build virtual agents. So Now Dialogflow has 2 versions one is Dialogflow ES(Older Version) and New is Dialogflow CX. So Now we have basic question arises what is a difference between Dialogflow versions(CX vs ES).
Dialogflow ES supported a flat structure of intents and implicit controls for conversation flows, mainly using contexts. This approach didn't scale well for building, understanding, and maintaining large agents with complex conversation flows.
Dialogflow CX addresses these issues by providing conversation flow controls in a more explicit and structured way. CX follows graphical structure which allows designing of complex conversation flows.
A new visual builder makes building and maintaining agents easier. Conversation paths are graphed as a state machine model, which makes conversations easier to design, enhance, and maintain.
Console overview: https://cloud.google.com/dialogflow/cx/docs/concept/console
One of the main features of the CX is the Reusable Intents. Fulfillment is decoupled from intents, making intents a truly reusable component for multiple different conversational flows.
In Dialogflow ES intent is tightly coupled with the fulfillment so it's too difficult to reuse it.
Separate flows let multiple teams work simultaneously. With Flows, you can partition your agent into smaller conversation topics. Different team members can work on different flows, which make Virtual Agent development very easy for the more complex conversation flow. Also It has versioning support at the flow level so you can run multiple versions based on your environments. In short, It allows modularization of bot for ease of management.
For example, If you are creating an Agent for the Restaurants booking then it may create flows like order confirmation, order booking, Get Customer Details etc. So Here you can give the individual flows to different teams and speed up the development of the virtual agent.
For more information regarding Flows: https://cloud.google.com/dialogflow/cx/docs/concept/console
A state-based data model allows us to reuse intents, intuitively define transitions and data conditions, and handle supplemental questions.
You can set conditions for each flow. A conditional trigger determines how the route will occur. For example, if a parameter equals a specific value, or if all parameters have been filled then route to the specific page or flow. I'll cover this topics in details for upcoming blog with some examples.
In Dialogflow CX thwy have come up with mainly 3 types of parameters.
Dialogflow Stores all the captured parameter through out the session so you can use the specific parameters in further flow. This feature in not available in the Dialogflow ES but you can do it via setting the long output context in Welcome intent.
Intents use parameters to extract data provided by end-users when intents are matched. The following data is used to define an intent parameter. Due to the short-lived life span of intent parameters, Dialogflow recommended to use the session parameters.
For each page, you can define a form, which is a list of parameters that should be collected from the end-user for the page. It's kind of similar to the ES Slot fillings.
For more information regarding parameters: https://cloud.google.com/dialogflow/cx/docs/concept/parameter
Note: I'll create a separate blog to explain the dialogflow parameters with examples.
Now that we have explored the newest features of Dialogflow CX, let’s look into the comparison between Dialogflow CX vs ES.
|Category||ES Agent||CX Agent|
|Editions||Dialogflow Essentials Edition||Dialogflow CX Edition|
|Definition||This is the standard agent type that is suitable for small to medium and simple to moderately complex agents. Intents are the building blocks of conversation design, and contexts are used to control conversation paths. The ES agent type is summarized in Dialogflow ES basics.||This is an advanced agent type that is suitable for large or very complex agents. Flows and pages are the building blocks of conversation design, and state handlers are used to control conversation paths. The CX agent type is summarized in Dialogflow CX basics.|
|Agents per project||1||100|
|Recommended agent size||Up to medium size agents||Up to very large|
|Recommended agent complexity||Up to moderately complex agents||Up to highly complex|
|Integrations||Many different telephony as well as text based integrations are available. Dialogflow ES supports telephony integrations with Genesys, Avaya, etc. Also possible to integrate with many popular conversation platforms like Google Assistant, Slack, Facebook Messenger, Kommunicate, and Google-contributed open-source integrations.||Telephony integrations are available only for Avaya, Voximplant, Audio Codes and text based integrations are available for Dialogflow Messenger, Facebook Messenger and Line. The support for the rest of the platforms is not available yet.|
|Language Support||Language support available for multiple languages.||Language support available for fewer languages than DF ES.|
|History feature||The History page shows a simplified version of the conversations your agent has engaged in. These logs are chronological and intended to be an overview of how users interact with your agent.||Not available in DF-CX|
|Agent building blocks||Flat structure of intents||Graph structure of flows and pages|
|Conversation control||Linear conversation paths that simulate nonlinear paths using intents as nodes and contexts to control paths||State machine model with explicit conversation control using pages as nodes and state handlers to control paths|
|Console user experience||Mostly text forms||Visual graphs showing conversation paths and text forms for configurations|
|Intent reusability||Intents are coupled with fulfillment, events, and responses; specific to a conversation state, so difficult to reuse||Intents are simplified to remove this coupling and made highly reusable|
|Webhook Error handling||Errors quietly ignored by agent, passed to API caller if present||Explicit error event handling built-in to your agent|
|Parameter scope||Can be scoped to intent, context, or event||Can be scoped to intent, form, or session|
|Pricing||Pricing is more granular More economical. For Text: Production-ready quota $0.002 per request, For Audio input: Production-ready quota $0.0065 per 15 seconds of audio, For Audio output: Production-ready quota $4 to $16 per million characters||Pricing is simplified 2.5 - 3 times higher than DF-ES For Text: 1200 requests per minute $20 per 100 chat sessions, For Audio input/output: 600 requests per minute $45 per 100 voice sessions|
In conclusion, DialogFlow CX is an improved version of the Dialgoflow ES. CX has resolved all major drawbacks of the Dialogflow ES like improvement in slot filling, event handlers, parameters etc. But still it come up with the very high pricing rate as compare to ES. Based on my opinion both version has it's prons and cons. If you have very complex conversation flow then I suggest to go with the Dialogflow CX otherwise for simple flows Dialogflow ES is good enough.
Thanks for reading this blog and Hope🤞 you liked it. I'm planning to create a series of blogs for Dialogflow CX concepts(Deeper Dive into Dialogflow CX).
Please FOLLOW me on twitter to get notify for my upcoming blogs regarding Deeper Dive into Dialogflow CX.