InterBot: one giant step for botkind

Almost all the discussion around bots to date has focused on bot-to-human interactions: how bots interact with humans; conversational interfaces; human search and discovery; engagement metrics; spam controls, etc. However, there is a potentially bigger aspect of the bot phenomenon that hasn’t been much discussed or explored: bot-to-bot interactions.

Sounds like sci-fi, right? But bots communicating with each other can enable amazing possibilities. Here are a few of them:

Bots can negotiate and transact deals with one another, giving rise to bot marketplaces. Shopping bots can procure prices, deals, and discounts from merchant bots, thereby doing comparison-shopping. The shopping bot can even negotiate by making counter-offers to the merchant bots. Differing developers can build merchant and shopping bots without knowing about the other upfront.

Intermediary bots can enable greater privacy during e-commerce transactions. Instead of sharing credit cards with every merchant bot, you’ll just ask your “preferred payment bot” to pay the new merchant without revealing your credentials. Similarly, intermediary bots may facilitate transactions while keeping the counter-parties private or even anonymous, as requested.

Bots will compete with each other as they strive to keep getting better. Imagine a multi-player gaming scenario where a number of blackjack or poker bots play with a dealer bot. In this case, each bot may have its own strategy to compete with other bots. Bot players can play games at a much faster pace than human players, which means the learning curve will be fast too. A bot may potentially win and lose money, depending on how good its strategy is.

Bots can collaborate with one another to form groups, hierarchies and other organisations in order to achieve tasks that are more complex than any one bot can. Isn’t that what humans do too? Imagine your “smart home bot”, communicating with the “neighbourhood bot”, which communicates with the “city bot”, thus enabling hierarchical coordination with each other.

It also makes bot building easier. A developer can string multiple bots together to create a new bot. Placing a “pizza bot” together with a translate bot gives you a multilingual pizza bot. Placing a keyword-based travel bot together with an NLP bot can give an NLP-enabled “travel bot”. In such cases, bot composition substitutes bot development. Developers can, in fact, start building utility bots that provide component capabilities to other bots. Developers of the individual bots (the bot composer, the pizza bot developer or the translate bot developer) really don’t need to coordinate development, which makes composition easier.

In business, inter-bot communication will enable distributed development of enterprise bots. While each division in an enterprise can build a bot focused on its specific aspect of the business, the enterprise can add a single customer-facing bot that intelligently routes messages to the underlying…botlets. And different teams can build bots independently while simultaneously offering a unified interface to the customer.

If bots can communicate with other bots, then humans can delegate these interactions to their personal assistant bot. As bots proliferate, the sheer number of messages may overwhelm we humans’ ability to deal with them. At that point, we just may want to delegate the interaction with other bots to a personal assistant — also, you guessed it, a bot! Now the assistant bot can deal with all the other bots. The assistant susses out individual preferences and can either filter or autonomously take care of most messages.

Soon, bots will emerge as full-fledged financial entities. We may give our bots autonomy to earn and spend money. Our bots will make money for us. It’s a whole new economy!

Bots will also become smarter, self-healing and reproductive. Bots will become smarter by asking other bots for help when they need it. They can easily be self-improving or self-healing by replacing the bot’s component with a newer and better component when it emerges. Bots will be able to produce or reproduce other bots through bot composition. It’s a whole new civilisation!

These are just some of the possibilities we can imagine today. And, there are a lot more beyond the horizon. Still, one of the key questions that many developers will ask before pursuing them is why bother with bot-to-bot interactions when we have APIs?

Interbot communication offers new capabilities that are difficult (or in some cases impossible) to create with APIs. Bots can enable distributed computing in ways that APIs cannot. Here are some of the key differences between the bots and APIs:

1. Synchronous vs. Asynchronous — Bots are inherently designed for asynchronous messaging and can better handle long response delays. APIs are built for synchronous interactions and timeout with long delays. Asynchronous systems tend to be more scalable, reliable and robust.

2. Directionality: Bots are bidirectional, while APIs are unidirectional. Bots can both push and pull data, while APIs can only respond. Once communication is established between two bots, either can initiate a conversation or respond to it. APIs, on the other hand, generally only respond to calls.

3. Flexibility: Bots are robust with handling inputs, and are designed to flexibly handle a wide variety of input queries. APIs are very fragile by comparison. If the API call parameters are not submitted in precisely the right format, it breaks down. When provided incomplete information, bots can ask for more information. APIs simply do not do that.

4. Awareness: Bots can interact without mutual awareness, while APIs need to be mutually aware. Bots can interact with each other without any pre-defined agreement, thus freeing developers to build bots without worrying about what or who they might interact with. With API integrations, one side needs to be aware of the other for it to work.

5. Interoperability: Even independent third parties can get two bots to communicate with each other; not so with APIs. A consumer can compose new services — plug-and-play style — by chaining multiple bots, each of which may be independently built by other developers. That’s not possible with APIs.

Bots will inevitable become the new APIs, making integrations and mashups a lot easier.

Our team has been working on an InterBot Communication Channel (http://interbot.cc) to enable bot to bot communication — a messaging channel that allows bots to freely communicate with one another. To use InterBot, bots first have to publish themselves on this new channel. Then bots can consume the services of other bots or offer its services to others. Humans, and bots too, can compose other bots endlessly in plug-and-play style by simply connecting them like Lego blocks. Plus, there are APIs to enable more advanced combinations of bots, as described above.