1. Stateful bots
The very first bots you built in this course were completely stateless. That means that the response to a message x is the same no matter what messages came before. When we talk about a bot's *policy* we mean this mapping of a user input to an actions. It's amazing how far you can get with stateless policies, but to build more sophisticated experiences you will always want to add some statefulness.
In chapter 3, you started adding memory to your bot, in the form of key-value pairs. Now we'll go a step further, and make the selected actions depend on the context of the conversation.
2. What do we mean by stateful?
What do we mean by statefulness?
This super simple conversation already shows how important statefulness is in real conversations. What we really mean is that the bot has a 'memory'. In previous exercises, the memory was limited to key-value pairs describing the entities the user had already specified. Now we're going to add an additional piece of memory: a state machine.
3. State machines
If you've never heard of a state machine before, don't worry.
A simple example of a state machine in the real world is a traffic light. The traffic light has 3 states: (green, yellow, red).
When an event is received by the traffic light it changes its state (e.g. red -> green or green -> yellow).
Shopping is a typical use case where a state machine can help simplify the implementation of a bot. A user begins by browsing, maybe they looking for some shoes, and a matching shirt. Once they've chosen to make a purchase, you need to collect some information from them like their card details and shipping address. After completing the order, they might have some further questions (like when their slick new shoes are arriving!)
4. Implementing a state machine
To implement a state machine we need some symbols to define the states,
and it's common to use integers for this purpose. You're going to build a coffee ordering concierge. Let's define three states, init, choose coffee, and ordered.
Then we need to define some rules, or events, which switch between these states. For example, if we're in the "INIT" state and the user expresses an `order` intent, we should push the bot onto the `choose_coffee` state. Once they've confirmed which coffee they want (the `specify_coffee` intent) we can place the order for them and move them into the `ordered` state.
We can define these rules in a dictionary, where each key is a tuple of the current state and the expressed intent, and each value is a tuple of the next state and the message to be relayed to the user.
5. Using the state machine
To use the state machine in our bot, we need to think about the scope of our `state` variable. It should have the same scope as the `params` key-value memory store we saw in earlier exercises, i.e. outside of the respond and send message functions.
Here we've defined an interpret function which just returns the intent for any given message.
Note that again, our `send_message` function now returns the new state value, we modify the bot's state by overriding the state variable with the output of the send message function.
We can now expand the set of rules in our bot's policy to handle context. For example, if a user asks for help, it's important to know where in the flow they were, so you can help them best.
6. Let's practice!
In the next exercises you will create bots which can do just that.