This code pattern is part of the 2020 Call for Code Global Challenge.
There are scenarios where a user wants to have a conversation involving multiple domains. For example, when I want to travel to a place, I want to query for the weather and book a cab or flight. I might have to end up switching between two different bots — a weather bot and a travel bot. What if I could just have one interface bot that redirects my messages to a specific bot and gets answers to me? This developer code pattern showcases an implementation of this approach.
Typically, chatbots are designed to cater to domain-specific queries from humans. For example, a weather bot can handle messages such as:
What is the weather forecast for today? What will be the high temperature tomorrow? Will it rain in the evening?
A travel bot can handle questions such as:
Book a cab Book a flight What is the flight duration between Bengaluru and Mumbai?
A user must switch between bots to ask questions related to different domain bots. There can be several bots, and expecting a user to switch between bots can be unreasonable.
The solution is to have an agent bot (or an interface bot) and a few other bots that can handle queries for a specific domain (let’s call these specific bots). The agent bot knows about the specific bots and also about which domain each of them can handle. When user initiates conversation with agent bot, the agent bot will understand the intent of user query, and it will redirect the user query to a specific bot. Subsequent requests from user are redirected to specific bot. When the conversation with the specific bot is over or when the specific bot is not able to handle the request, the control is given back to agent bot, which will then redirect the messages to appropriate bot.
This approach provides a seamless experience for the user. It can be used by organizations that provide a host of services to their customers, such as financial services, tours and travel agencies, and news agencies.
Advantages with this approach are:
- Plug and play the bots
- Modular approach facilitates bot composition
- Create new services by composing two or more bots
- Easy to maintain, make changes, add/remove functionalities
- Easy to troubleshoot issues
- Transparent to user
This code pattern uses a Watson™ assistant bot for building bots and a Node.js application as an orchestration layer.
When you have completed this code pattern, you will understand how to:
- How to configure a bot to make it an agent bot
- How to configure a specific bot to return control to the agent bot
- How to build an orchestration layer to stitch the agent bot and specific bots
- User accesses web application and types in a message. Node.js application, an orchestration later, sends user message to agent bot.
- Agent bot determines the intent of the message and responds with the specific bot details, to which the message needs to be redirected.
- Node.js application sends message to the specific bot (Weather Bot in this case). Specific bot responds. Conversation continues between user and specific bot.
- When the conversation with specific bot is over, user message is sent to agent bot to determine intent.
- Node.js application sends message to the specific bot (Travel Bot in this case). Specific bot responds. Conversation continues between user and specific bot.
Find the detailed steps for this pattern in the README. These steps will show you how to:
- Create a Watson Assistant service instance on IBM Cloud.
- Download the code from GitHub.
- Create bots by importing files from the Git repo.
- Configure and deploy the application on IBM Cloud.
- Run the application.
- Add bots, if required.