Why build BotDunc, my personal bot?

I recently released my personal bot, BotDunc, into the wild. BotDunc is available through both Twitter and Facebook Messenger.

I’m not the first person to launch a person bot — MessinaBot and EstherBot are other examples. But these are all provided by people working the bot field — personal bots don’t seem to have yet become “a thing” for consumers.

So what exactly is BotDunc and why did I decide to embark on this seemingly pointless activity?

BotDunc — what is it?

But more than my personal bot, BotDunc is a public study into bot development. It’s a vehicle through which I can explore the highs and lows of creating a bot, discovering what works and what doesn’t. It allows me to engage in a conversation with you, my dear readers, helping to share my experiences. BotDunc is most definitely not designed to be a perfect bot solution. Instead, it’s very much an experiment and the spark for a conversation.

Why?

I am also conscious that, given the current bot hype, there might be a rush for bot names. So, being completely open, my timing was motivated by a desire to ensure I grabbed a great bot name in Twitter and Facebook before someone else got there before me. Who knows, bot names might just be the new domain-name gold-rush!

As I work wtih IBM Watson, I was also influenced by our launch of the Watson Conversation service — an ideal platform for aspiring bot-makers like myself. I needed a purpose to play with the new technology and BotDunc has become just that.

An MVB

My MVB was deliberately minimum in both its technical architecture and its training. I intend the approach to both to be a kind of agile evolution. Rather than scope-out and design the world’s perfect personal bot, I plan to evolve BotDunc incrementally. Taking this approach I hope to be able to show the value of each incremental improvement as it is made. No doubt I will also go down some blind alleys along the way. Some design decisions may end up being proven wrong and being replaced — indeed, some already have (read on for the details).

Overall my big rationale for this “launch a minimum product quickly and iterate in public” approach is very simple — nobody really knows how popular bots will be, or indeed what a personal bot needs to do. At this stage I’m just guessing — and I’m almost certainly wrong in nearly all my guesses. The only way to discover what BotDunc should do, is to get the bot out there and see what people do with it. Only by observing what real users ask of my bot and what their actual expectations are, can I ever hope to build anything useful.

Further, by collecting the questions people are asking BotDunc, I’m already building my training data for the underlying AI that supports it. There is no existing corpus of training data for a personal bot, so I’m effectively getting you to generate one by launching early and collecting what you ask BotDunc. In some senses you could view BotDunc at this stage as little more than a question collector.

Of course this approach has risks. In its version 0.1 guise BotDunc is pretty stupid. He’s already made some obvious gaffs and embarrassed me. But I’ve been careful to keep BotDunc conversations 1:1. On Twitter BotDunc doesn’t tweet publicly, preferring instead Direct Messages only. Public tweeting at this early stage would seem, to me, to be folly. BotDunc is learning and making mistakes without the full glare of publicity — in stark contrast to Microsoft’s Tay. This post, and the subsequent ones that follow, will hopefully explain what I am doing and why — perhaps you will forgive BotDunc’s stumblings a little more when you understand this. Above all, BotDunc is not a showcase — he’s an experiment.

BotDunc Design

  • BotMaster, a simple NodeJS framework for connecting a bot into messaging platforms like Twitter, Messenger and Telegram. BotMaster is engineered by my friend and colleague @jdwaurin.
  • Watson Conversation, a cognitive bot platform. Conversation provides a machine learning system so that I can teach my bot by example how to understand the intent of questions that users ask of it — for example, “hello” and “hi” are both ways of expressing a greeting that share a common underlying intent. Conversation also includes a structured dialog system that allows me to configure answers to questions and conversational flows where you can have a back-and-forwards conversation with BotDunc. These major capabilities of Conversation make it an ideal base for a bot platform.

Both BotMaster and Watson Conversation are deployed into IBM’s Bluemix Cloud system. As Bluemix is a platform-as-a-service solution, I don’t need to setup any servers or configure any infrastructure — I just provisioned a NodeJS and Watson Conversation instance with a few mouse clicks and Bluemix does all the rest. Perfect for my MVB.

This was the sum total of my initial implementation. I could see questions being asked of BotDunc in Twitter and Facebook — the volume of conversations were sufficiently low that reviewing these manually was easily viable. Doing so I quickly identified things that BotDunc was struggling with and adjusted its training and dialogs appropriately. I was up and running within a couple of days and working things out as I went. No big planning here.

Iterating the Architecture

Two big problems I needed to address included:

  1. Answers to questions could only come from within Watson Conversation itself — the ability to reference other sources was absent (for example, to search in a document for an answer, to call an external API, or to reference a database). I needed a cognitive integration framework that allowed me the flexibility to reference many and varied sources of information that BotDunc might need in order to be successful.
  2. Reviewing conversations through Twitter and Facebook was clumsy at best and wasn’t going to scale when BotDunc went viral (well, I have to plan for success, right?!). A more structured data store of historical conversations that would allow me to extract and analyse conversations was clearly going to be needed if I was to achieve world domination.

In order to implement the technical underpinnings to address these two problems, I’ve just re-engineered BotDunc to include an additional layer between BotMaster and Watson Conversation. This inserts NodeRed into the architecture acting as the, until now, missing cognitive integration framework. NodeRed has a wonderful graphical development tool that allows me to wire together pieces of function, access databases, call APIs and generally muck about doing lots of cool stuff! Because my bot presence in Messenger and Twitter is now plumbed into NodeRed, which calls Watson Conversation, I can add additional function like:

  • access a database of information
  • call an external API to retrieve live data to augment a reply
  • call other cognitive services — for example, Watson Retrieve & Rank looks for answers to questions within a natural-language document (maybe my CV?) and the Emotion service helps to identify if incoming questions include strong emotions.

With the just deployed architecture, a question from BotDunc passes through BotMaster, which forwards that to a simple ‘flow’ in NodeRed. That flow stores the conversational fragment in a database and then calls Watson Conversation. It’s simple, but it provides a base on which I can build. The flow also handles the conversational state. Watson Conversation is a stateless service and the calling system needs to pass a Context object between calls that handles that state. My NodeRed flow manages and stores the Context object, ensuring that once you’ve told BotDunc your name, he’ll remember it forever! It sounds complex, but is almost trivial to implement once you know how.

I could have achieved the same goals as NodeRed in the design by just writing JavaScript code — BotMaster gives me the framework to do that. But NodeRed allows me to make on-the-fly changes without going through a full code re-deploy. Instead, it allows me to deploy my flow changes with the click of a single button. The various pre-built NodeRed nodes also give me easy access to a library of potentially useful functions — so it’s ideal for my needs. Mostly I find that NodeRed reduces the cognitive (!) overload on me of learning the syntax and technicalities of how to interact with a wide variety of different technologies.

One extra function I built to exercise this capability, in just a few minutes, was the ability for the user to ask BotDunc what the date is. Watson Conversation is configured to reply to this question with the string ‘%DATE’. My NodeRed flow has a tiny fragment of JavaScript that looks for %DATE in the response from Watson and replaces it with the current system date (suitably prettified of course). This is a very simple example I implemented in order to prove the concept, but of course that same pattern could be used to do something much more sophisticated. The protocol of %COMMANDS that are interpreted by NodeRed, is one I plan to build on in the coming months. The sky really is the limit now. The combination of Watson Conversation and NodeRed give me an ideal set of tools for understanding what a user is asking, building a conversational response and configuring more or less any function I might need into that response.

Agile Architecture

If I decide later on to let BotDunc handle sensitive personal information, for example, then I’ll address the architectural requirements then. Trying to plan ahead now would just prevent me from making my first move and working out what people think BotDunc should do. Maybe BotDunc is a terrible idea and nobody will use it — in which case, it’s good to find that out now before I’ve invested time and effort in its development. Only an Agile Architecture can allow me to launch, discover and iterate.

If need be, I can throw my investment in the current design away when I discover a need for a super-secure version — for that investment is sufficiently small for that not to be an issue. Agility, iteration and experimentation are the order of the day.

I wouldn’t recommend an Agile Architecture for every situation but, given my purpose and the technologies I’m using, it’s perfect for the task.

Training

Nevertheless, the open-ended approach was revealing and useful — it helped me to begin to get a sense of my bot user’s expectations and improve its training. Had I implemented a more directive approach (eg “Please only ask me about these three things”) I might never have discovered some of the insights into possible requirements that I did.

But still, it seems that BotDunc can usefully set some expectations and start to guide users down a path where it’s more likely to be successful. I don’t want to remove the potential ‘random stuff’ that might come up, but I do want to gently encourage usage in areas that BotDunc is better qualified. As a result, I’m in the process of building guided options into the BotDunc conversation. Instead of “What can I do for you?” it will say “You can ask me about Duncan, about BotDunc or about Watson. What would you like to ask me?”.

Of course a user might still ask about BotDunc’s views on Brexit or Donald Trump, but hopefully the expectation is set that those are possibly topics that it isn’t so qualified on.

Having reviews the logs of conversations with my bot, I would like to make it clear that BotDunc has not yet experienced questions of “personal” nature, unlike IKEA’s experience.

Release and publicity

I had the obvious advantage of a soft-launch through obscurity — not being a celebrity, my user-base is fairly (OK, extremely) limited. Let’s just say I don’t have to worry about my servers being over-loaded. If your public presence is grander, a more controlled release is probably called for. Limited publicity, required registration, selected friends-and-family, cloaked branding and other such techniques can all be used to ensure your bot’s idiocy don’t make the front page of the Daily Mail. But I do think it’s critical to get any bot in the hands of real people as soon as possible — not project team members. Only then will it be exposed to the expectations and abuse that it will surely receive when you go big.

What Next?

Eclectic tastes, amateur at most things. Learning how to build a new startup. Former CTO for IBM Watson Europe.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store