From a user standpoint, a bot is a service that is exposed through a chat interface. It’s a personal concierge that can help you get things done, in a simpler and more productive way. But sometimes you need to complete a complex task that requires the help of multiple bots. Take travel, for example. It requires booking flight, hotels, and cabs. In the same way you need to interact with a few people to coordinate this trip, you might also need to communicate with a few bots.
This is the simplest use case, and also the most common these days. A user has a direct interaction with a service. This can happen via direct messaging or in a public channel, but the context of the service is one-on-one. From a development standpoint, this is the easiest mode to implement. Direct communication is also sufficient in many use cases. Users are used to having direct interaction with services, so this is an easy-to-understand paradigm from a consumer perspective.
In this use case, a bot is providing a service to a team or group. The context is no longer one-to-one, and anyone from the team can interact with the bot to accomplish a joint task. This is a slightly more complex use-case, as a bot needs to keep context with all of the users in the group and also expect users to leave and join the group. In this case, a bot needs to onboard new users and orient them about how to make use of it.
Bots in groups can facilitate complex business processes such as team check-ins, performance reviews, meeting coordinations and more. A bot might need to keep a more complex one-to-many context and handle changes in teams as their members change, but it can also provide very valuable service to the team.
User-to-bots service composition
This is a use case that I have not seen implemented well yet. A user states an intent or a task, and a set of bots collaborate to complete that task or fulfill the intent. This is quite complicated and uncharted territory, with a lot of ethical and security questions. Can bots share information? Who decides which bot does what? What happens if something breaks with one bot?
As you can see, the user sees a lot of bots/services working together to fulfill the intent. One can envision an orchestration engine, or a control flow, that makes these complex bot interactions. We will be covering one use-case like this next.
Super-bot — one bot to rule them all
This is a slightly different way to implement a complex task that requires multi-service collaboration. In this case, the user talks to a single super-bot that “knows all” and can mask the complexity of service composition.
While interacting with a super-bot might be simpler from a user standpoint, from an openness perspective this is slightly risky. A single super-bot might lead to a winner takes all market. It is important, in this use case, to keep the variety of innovation and openness of the bot market.
User-bot → bot — the discovery use case
Another interesting opportunity for collaboration is bots discovery. In this case, one bot introduces you to another bot/service. This use case requires some sort of intent directory or prior knowledge about other bots in the system.
There is a big opportunity here for services to cross promote each other, extend the service they provide the user, and give the user a more comprehensive service. The big risk, in my opinion, is of overwhelming users with too many interactions. Think of talking to many service providers at the same time. However, this can be handled with thoughtful conversational design.
We are really in the early days of bots, where most of the interactions are simple and one-on-one. But as we mature in this industry, exposing more complex and valuable services, we should figure out how humans and bots can work together. We need to get bots right and do it in a collaborative manner – bot builders need to collaborate in order for their bots to work together . I hope this is a good start.
This article is based on an interesting set of conversations I’ve had with a lot of smart people in Foocamp and Botness about bot collaboration.
This article was written by Amir Shevat and Slack from VentureBeat and was legally licensed through the NewsCred publisher network.