My another use case: I have an exercise from ~50 gambits with external CRM requests in some points. So I need to 1) save learning progress after every gambit and 2) restore it on next user’s load the exercise if user still not finished the learning.
Yes, I can do it by save gambit number to the external CRM after every step and request it on the very first gambit to redirect user to the it’s last learned step, but it is VERY DIFFICULT and not scalable.
Are there another ideas? Do plan the Tars team to make the statefull bots or simply save the current gambit number to the user’s cookie?
These Bots are stateless and does not hold information about the user upon page refresh.
This is a very deliberate design decision. As it has a lot of advantages, the primary one being that it makes it very easy and simple for the Bot Makers to manage the user-bot interaction as a small chunk of conversation that you have in one go.
As soon as you add statefulness in the bot conversation, the complexity to manage the bots increases But so does the capability of the bot. So we need to be very careful about adding this extra complexity in the system and make sure that the tradeoff of the extra capability is truly worth it.
We do have few ideas to bring in some statefulness in the bot conversations in an easy way, which i have discussed on another thread about how to retrieve the partial conversations for a bot from the TARS DB itself, when passed a unique ID. This will be config controlled statefulness, and not going to be the default behaviour. But that’s for later.
For now, the easiest way to do what you are trying to acheive is by saving the last gambit number in your CRM and continue from there when the same user comes back. To do that, instead of making an API after every gambit, you can do the Zapier email based integration with your app, which can be triggered by the partial emails that you get.