Since I started tracking chatbots in mid-2014, I’ve seen many exciting domain-specific use-cases that are genuinely very useful. Some of my favourites are:

Working on Nexmo’s Chat App API has also given me a unique perspective on a variety of interesting use-cases explored by businesses. I’m delighted by the tonnes of domain-specific chatbots shipped daily because we are ‘unconsciously’ sharing the task of creating the ultimate chatbot that can handle these diverse tasks. Unsurprisingly in the ongoing chatbots arms race; no chatbot on the market today is based on Artificial General Intelligence i.e. there is currently no chatbot that solves all problems and understands every type of task (Facebook is rumoured to be working on ‘M’ that attempts this). Those available mostly use a variety of Machine Learning (ML) techniques with intricate pattern matching logic to understand user interactions in specific domains. The broad reason is simple; General AI is hard; heck it is referred to as Hard AI in some circles. Hence, the task of a generic chatbot is a huge ask!

Just to be clear, handling ambiguity for domain-specific bots is equally a non-trivial task. However, the complexity explodes exponentially when handling multiple domains. Other requirements also increase as more domains are factored in. For instance, dataset needs differ across the travel and restaurant booking verticals. Domain-specific knowledge (that no single person is a custodian of) for each vertical also comes in handy when building a truly intelligent chatbot. Summarily, ignoring the fact that our AI is not quite there yet [1], the task of creating a truly generic bot requires a lot of diverse expertise which is beyond the capabilities of any small team.

All the same, all hope is not lost, we can continue building chatbots for specific domains thereby tackling some of these complexities concurrently. This helps us experience humanity at its best; the age old act of ‘division of labour’ where everyone focusses on an area of competence. In simple terms we are splitting tonnes of intricate and domain-specific Natural Language Processing (NLP) problems and individual teams are having a go at each task. To be honest, this is the fastest practical way of solving such genuinely difficult problems on a large scale. This will speed up the realization of even more expert chatbots in other interesting areas like; Medical Diagnosis, Legal Advice, Language training, Mock Interviews, Educational chatbots etc.

At the end of the day what we have is a variety of sophisticated chatbots solving specific problems efficiently.

The Dream of A Meta Chatbot — A chatbot ‘router’

I’ve been fantasizing with the idea of a meta-chatbot for a few weeks — it is basically a chatbot that is knowledgeable about other chatbots. It can be thought of as a chatbot intermediary that receives requests on behalf of other chatbots and routes them appropriately. The reasoning behind this is simple, as more bots hit the market, we start having several bots that are really good at very niche verticals. The immediate implication of this is that we will have an enormous bot fragmentation problem; for instance, I can imagine having different bots for domains as closely related as Hotel reservation and Travel booking. The current trend by big players to launch botstores (Kik opens Chatbot store, Facebook to announce chatbots in F8) will further accelerate the fragmentation. At this early stage this is not a big deal but after a while, we will have a phenomenon similar to the ‘app fatigue’ we are currently facing. Users will be hesitant to add a new chatbot as a ‘contact’ for every mundane task that needs to be completed. I can imagine adding a chatbot to get my laundry sorted and yet another chatbot to get ‘expert’ advice on getting flowers for a significant other; we will be hit by another type of fatigue probably called: ‘chatbot fatigue’. Users will prefer to perform all their chatbot related functions in a single chat window or just a few for the benevolent ones.

Chatbot overload???

The dream of a meta-chatbot plugs into this contrived user need. Once we’ve all ‘finished’ developing our specialised chatbots, we can focus on building an ultimate meta-chatbot (bot router) that acts as an intermediary. It is like a ‘typical’ chatbot to a regular user but internally, it has a deep knowledge of other existing bots, their capabilities (strengths, weaknesses and the like) and can exchange messages with them in a structured/unstructured way. In-fact it can maintain some internal data of things like bot latency, precision, accuracy and a lot of metrics that helps in its decision making (this is a story for another day). In addition, it also has baseline information about its ‘owner’ and can expose the owner’s information to other chatbots as required by them to make a decision. This can be simple user preferences like current timezone or similar minor but useful details. Armed with these information, the meta-chatbot can receive ‘any’ form of input, use classification techniques & its ranking logic (since multiple bots may be able to handle a single task) to identify the ideal bot to route the task to. Once completed the response can be piped to the user. I’m well aware that this works best if all bot developers follow a standard that allows exposing the capabilities of chatbots to external systems. This will lead to discussions around creating specifications, (RFCs ??), protocols and a couple of other things most current chatbot enthusiasts are not yet interested in discussing.