An expert practitioner’s guide to the new Watson Assistant

The new Watson Assistant marks a significant milestone in the evolution of IBM’s virtual assistant. Authoring and runtime changes allow business users to both build virtual assistants and manage their lifecycle.

Photo by Pierre Bamin on Unsplash

Experienced Watson Assistant users may wonder where features such as intents and entities have gone in the new experience, and how some conversational patterns that were closely tied to them can now be achieved in Actions. This article outlines how concepts such as intents and entities map to the features in the new experience, and how the authoring experience is now linked directly to lifecycle management.

The new experience

Existing Watson Assistant users will notice two striking differences when first opening the new experience:

• The user interface has been redesigned, with all authoring being done in the context of an assistant as opposed to a skill
• Actions is the now primary authoring experience (as opposed to Dialog in the classic experience)

After observing how some Watson Assistant users struggled to understand many core concepts, the team decided that users should not focus on skills and assistants separately. Many users did not fully grasp how these two elements were related, and as a result missed out on powerful features like version control.

The team decided users should only need to focus on an assistant, as well as the content and integrations associated with that assistant. When you launch the new experience, you are asked to create an assistant, not a skill. For users familiar with the existing experience, it may look like skills have been removed, however they still exist “under the hood”.

The assistant in the new experience is automatically configured with an Actions skill, and optionally can be configured for a Dialog skill. The Web chat integration is also automatically configured and can be used to preview the assistant’s capabilities. The assistant can also be configured to have additional integrations such as voice, SMS, WhatsApp, and Slack.

Lifecycle management

A significant aspect of the new experience is the promotion of content versioning (“skill versioning” in the original experience) to allow for better lifecycle management.

In the classic Watson Assistant experience, users needed to understand that a skill had to be attached to an assistant, and only after that was complete the skill could be versioned, with the assistant being configured to use different versions of the same skill. This pattern let the author achieve a development-to-production lifecycle for their content/skills.

The need to understand so many connected concepts made mastering lifecycle management quite complex. The publish model in the new experience allows users to create versions of their content more intuitively.

The content authoring lifecycle

Version control

When you create an assistant in the new experience you are actually creating an assistant and two environments (draft and live). An environment is analogous to a phase in the content promotion lifecycle, and is always attached to a parent assistant.

As you author your content, the system continuously saves the changes in the draft environment. The user has the option to publish these changes, saving that version of the content.

Publishing creates a new version of the content that can then be assigned to the live environment. Any further changes to content are automatically saved in the draft environment, but the published version will remain unaffected by those edits.

If a user wishes to test their most recent changes, they can use the Preview page to share and test their draft content. This process lets the author continuously create and test content. Once they’re happy with the assistant, users can promote it to the live environment.

Actions

The other major feature of the new Watson Assistant is Actions, a new way to author virtual assistants. Conceptually, an action can be thought of as a series of steps an end user takes in order to complete a task, such as ‘transfer money’ or ‘open account’. An action is an amalgamation of several Dialog concepts. Actions are comprised of:

• End-user phrases, which trigger the action
• Steps, which contain the assistant’s responses
• Customer responses, which the system uses to collect information from the end user

Feature parity with Dialog

These new concepts map directly to existing concepts from Dialog. When you create an action, you enter an example phrase that starts the action. Example phrases train the system to recognize end-user requests. These examples create an intent that is linked to the action. When the assistant recognizes that intent, it automatically routes the end user to the associated action.

The steps within an action map to dialog nodes. Each step can set context, output text, or output other media to the end user. Steps can also be configured to collect information from the end user using a customer response, which maps to a dialog node with an associated entity in the Dialog skill. Experienced Dialog users will likely notice a familiar pattern upon inspection of the customer response types:

Customer response types in Actions

The list of customer response types aligns almost exactly with the list of system entities in the Dialog skill, plus Options (illustrated above), Regex, and Confirmation, which lets the assistant know when a user responds ‘Yes’ or ‘No’.

Building a flow

Let’s use a real-world example from Dialog and examine how it maps to an action. Imagine a banking chat interface where a user wants to transfer money. We want to build this flow:

The flow as it appears to the end user

To build this flow in Dialog you would have done the following:

1. Create a #transfer_money intent, and add some example phrases such as ‘I want to transfer some money’
2. Create a @transfer_type entity with ‘Domestic’ and ‘International’ as values, along with various synonyms
3. Create a @confirmation entity with ‘Yes’ and ‘No’ as values, along with various synonyms
4. Enable sys-number or sys-currency as a system entity
5. Create a dialog branch with the following structure:

Dialog: the flow organized in nodes

Experienced Dialog users will know the above tree is not very forgiving. If at any stage in the conversation the user fails to enter expected input, the session will end up in the Anything else node. There is no built-in validation of the input at the @transfer_type node. If the end user enters ‘checking’ as the transfer type, the system will try to process that, fail, and end back at ‘Anything else’. Also, authors must remember to save the entity value as a variable so that it can be recalled later to output to the user.

In Actions, none of these issues are a concern as the system automatically takes care of input validation and variable assignment. Plus, the authoring experience is more consolidated.

Authoring an action

Let’s go through how the above flow would be accomplished in an action:

1. Create a new action with examples such as ‘transfer money’ or ‘I want to transfer some money’ (we recommend adding at least five example phrases)
2. At the first step in the action, add an assistant response asking for the type of transfer to be used, then add an ‘Options’ customer response with ‘Domestic’ and ‘International’ as values
3. Create a second step that prompts for the amount of money, and add a ‘Number’ customer response
4. Create a third step that simply outputs the variables entered in steps 1 & 2 of the action, and add a ‘Confirmation’ customer response to confirm that the information is correct
5. Create a 4th step with conditions: if the response given for step 3 is ‘Yes’, then output some text stating that the transfer is complete
6. Create a 5th step with conditions that checks if the response from step 3 is “No”, in which case you will want the assistant to ask if the user wishes to start over
7. Create a 6th and 7th step with conditions that check whether the user responded ‘Yes’ or ‘No’ to step 5, again asking if they want to start over
8. Select Re-ask previous step(s) from the And then menu for when the user wants to start over (this option maps to “jump to” in Dialog), and print a message and end the action if they don’t

Actions: the flow organized by steps

The 7 nodes in the Dialog skill can be translated into 7 steps in Actions. However, what the graphic does not show is the fact that Actions has automatic validation handling and automatic assignment of variables. In the case of steps where the user is prompted to enter some info, the assistant knows that each step is trying to collect a value and will not allow the conversation to continue until the requested information is provided:

The assistant prompts the user to enter a valid response type

While in this case the number of steps is equivalent to the number of nodes, the functionality of the Actions implementation is superior in terms of edge cases it automatically covers, and the simplicity of the build experience.

You will discover as you work with Actions that custom entities (or options) created at a given step cannot be reused on subsequent steps. For example, ‘Domestic’ and ‘International’ from step 1 cannot be used again in another step to collect the same information.

From a tooling perspective, all customer responses can only be used at one step. For situations where a broader, more general “entity” is needed, you may consider using Shared responses. These allow authors to share an entity across multiple steps or actions.

Shared responses have many of the same attributes as entities, with the added benefit of providing a data type to the system, allowing variables to be assigned custom data types. In our use case we can create a ‘transfer type’ shared response that will have two values, ‘Domestic’ and ‘International’. This shared response results in a ‘data type’ being created that can be assigned as the data type of user-defined session variables. Once the data type is assigned to a variable, the user can then easily condition on the values of the shared response when used in the steps of an action.

Summing up

We are sure that, armed with these various concept mappings, Dialog practitioners can quickly make sense of Actions, taking advantage of its consolidated authoring experience and the powerful runtime features it allows. Get up and running with Actions by switching to the new experience today.

Thanks to

Venkat Ganesh

,

Burak Akbulut

,

Andy Stoneberg

, and

James Walsh

for their assistance in reviewing this article.