I've had an idea for a bot-related service I call "plan b", which would act as a secondary action for any sort of bot request / response to an API. When developers are providing common bot responses like looking up a business address, sports statistic or stock quote, it could be exposed to suggestions for a "plan b". When a request is made, it can travel via its regular path, but it would also be included in a queue where other 3rd party developers could provide plan b suggestions, either free or paid. When a user is engaging with the bot and didn't like the primary response, they could click on the "plan b" option, opening up alternative responses. In theory, the user could cycle through each "plan b" suggestion until they find a suitable response.
Since I don't have any startup aspirations I enjoy working through these ideas on my blog as part of my wider research, I found myself thinking my Plan B bot idea as I was learning about Meya's Bot Flow Markup Language, and in the context of how we can build in resiliency into API client code. The concept of a plan B seems extremely relevant to this discussion, and worth consideration beyond just bots, into voice, iPaaS, and other clients being put to work on top of APIs.
In the context of fault and change resistance, it seems like we'd have a "plan b" layer in our SDKs to deal with when an API goes away temporarily, or even permanently. I know I do not have ANY plan b in place for any of my API integrations, either directly in the SDK, or in my business strategy--I am guessing this is the case for most API integrations. It seems like responding to status codes etc could be considered fault-tolerance (micro), where a plan b option would be in the change resistance category (macro).
I had pictured "plan b" being some sort of hypermedia layer that could be applied to the world of bots, providing alternative options alongside each API call. I am going to expand on this definition to include resiliency. Maybe we can incentivize resiliency through the discovery of better responses, or even possibly monetization opportunities when commerce behavior(s) are involved. I'll keep brainstorming on my plan b idea, something that is a little more interesting now that it isn't just about bot response discovery and monetization, and might actually provide a plan b switch for resiliency and API brokering at the client and SDK level.
