Atura Context Engine

When you have a favourite lunch spot that you visit often, the people there get to know you - what you like and what you order often. In fact, they will usually greet you by name and know what you are going to order when you walk in the door. They'll also know you prefer sandwiches over pies, so when you say "I'll have the roast chicken" they know you want a roast chicken sandwich and not a roast chicken pie. This level of engagement makes the exchange feel personal - and means you are more likely to return.

An AI assistant should do the same. Not only should it build a relationship with the end user, by greeting them by name for example, it should learn over the course of the conversation and be able to recognise context from a conversation. You wouldn't expect the waiter at your favourite lunch spot to start talking about oven temperatures when you ask for the roast chicken. They should know that you were talking about lunch, not cooking instructions. An AI assistant should be the same. And to do this, it requires a way to recognise context. This is where the Atura Context Engine comes in.

The Atura Context Engine is built on top of the Microsoft Bot Framework, so a fair question is: "what does Atura's Context Engine provide over and above the MS Bot Framework offering?"

The following are key features of the Atura Context Engine which clearly highlight the Atura advantage. Each is elaborated upon in more detail across the Atura documents collection.

  • Consultant/agent takeover capability - allows the AI assistant to be paused and a real human to take over the conversation.
  • Unit testing flows - makes unit testing full conversation flows simple and facilitates a TDD approach to AI assistant writing.
  • Forms engine - allows the use of the powerful and flexible ATURA FORMS ENGINE.
  • Root coordinator dialog - creates a consistent way to generate "Root" dialog that branch off into other dialog.
  • Flexible NLP engine - allows the use of an alternative NLP engine, wip.ai or IBM Watson for example, not just Microsoft LUIS.
  • Helper dialogs - a collection of dialogs that assist with complex tasks such as handling waiting for external web service calls that take more than 15 seconds to complete for example.
  • Auto-publishing to a service bus - automatically sends conversations to a service bus for further processing by external systems.
  • Auto-archiving of conversations - all conversations are saved for reporting and analytics purposes.

Different Types of Context

The Core Atura assistant keeps track of different types of "context", including:

  • things mentioned during a conversation
  • who the user is
  • the specific AturaDialogContext class

Keeping Track of Things Mentioned in a Conversation

When a user's chat message arrives at the Bot web service, Atura deserializes the previous conversation state by leveraging the mechanisms provided by the MS Bot Framework. These include:

UserData

A key/value store with data specific to the user. The assistant can use this store when it needs to store any "global" value that may be needed in future. For example, the type of investor the user is (Financial Planner, Individual Investor etc.) or the encrypted security token (which is used for Client API calls).

ConversationData

A key/value store with data specific to the conversation , not the user. Used in the same way as UserData, but data is visible to all users in the conversation.

Dialog Fields

A "dialog" is a container for conversation state. From a technical perspective, a dialog is simply a C# class that is a subclass of the Bot Framework's "Dialog" class. The dialog class must be serializable and can contain fields and methods just like any other C# class.

The user's message is sent to the dialog where processing should resume, which is not necessarily the root dialog. Imagine the following dialog chain: the user wants to be contacted back and was prompted for his/her email address:

RootMenuDialog → ContactMeBackPleaseDialog → EmailAddressEntryDialog

At this point there are three dialogs in the chain. Once a message arrives that contains the user's email address, the EmailAddressEntryDialog will "close" and processing will resume at the ContactMeBackPleaseDialog.

When processing resumes at a dialog, the ContactMeBackPleaseDialog for example, any fields in the dialog are deserialized. They keep their values, even between multiple request/response round-trips between the assistant and user. This gives the impression that the dialog lives in memory and keeps its field values, whereas in fact Atura uses the Bot Framework's serialize/deserialize dialog mechanism.

Keeping Track of Who the User Is

There are many ways to identify a user, depending on the channel being employed. For example:

  • The Facebook Messenger channel will send FirstName, LastName, ProfilePicture and PSID (Page-Scoped User ID).
  • The Directline channel has no way to know who the user is, and so relies on the bot asking the user to log in , or the hosting web page to pass some information about the user already logged in to the website. Refer to the SECURITY SECTION for more details on the login process.
  • Other channels will send different identifiers.

It is up to the AI assistant to store the necessary information in the UserData store and use it where necessary - in user greeting messages "Welcome back \<firstName\>!" for example. The most accurate way to identify a user is with login to the Client API, and then keeping track of different IDs that relate to the user (Facebook PSID, WhatsApp ID etc.) in a database.

Keeping Track of the AturaDialogContext

The last kind of context, the AturaDialogContext, is an Atura-specific class that helps developers build bots on the MS Bot Framework, while taking advantage of the Atura features mentioned at the start of this document. It is tracked in code. The rest of this document focuses on the AturaDialogContext and associated helper classes, and how to use them to build AI assistants using the Atura Core.