There are two types of intents: user intents and bot intents. User intents are a formal representation of what the user means with an utterance. Analogously, bot intents are a formal representation of what the bot expresses with its response.

The rationale for having an intent layer for both the user and the bot is to be able to separate dialog logic from actual verbalizations in a particular language and channel. This means that the configuration of dialog flow in games is independent of how intents are expressed. Porting a bot across languages and channels thus only requires an adaption of the user utterances and bot messages; it does not require any changes on the level of dialog logic.


Intents are specified in the general format Game/Intent(slots).

Slots allow for adding parameters to intents. They consist of a slot label, an operator, and values that fill the slot.

Slot values are expected to correspond to the supported datatypes. Valid operators are the following ones:

List membership:

  • + means contains (e.g ingredient + 1 means that the list of values of the attribute corresponding to ingredient contains the value 1)
  • - means does not contain (e.g ingredient + 1 means that the list of values of the attribute corresponding to ingredient does not contain the value 1)


  • = means equals (e.g. vegetarian = true means that the single value of the attribute corresponding to vegetarian is true)
  • != means does not equal


  • ~ means is similar to (this is used mainly for keywords, e.g. title ~ burger means that the title attribute contains the keyword burger, and locations, e.g. location ~ (12.6, 50.4) means that the location is close to the specified coordinates)
  • !~ means is not similar to

Comparison and ranges:

  • <, <=, >, >= have the obvious meaning: less than, less or equal then, greater than, greater or equal
  • <> indicates inclusion in an interval, e.g. price <> 10...40 means that the value of the price attribute is one within the range from 10 to 40 (inclusive)

Hooks and callbacks

Games are isolated. As a result, there is no direct way to route interpretation results from one game to another. This sometimes makes dialog life tricky. For example, a lot of games need to interpret utterances like "yes", "no", and "doesn't matter". And depending on the current state of the dialog, they may mean different things, even at different points within one game.

In order to avoid having to add those general intents and all natural language variations of them to each game, they are collected in a general game called Conversation Hooks. Now, when one game asks a question and the user replies with "yes", the Hooks game will be the one to interpret that answer. But in order to react properly, this interpretation would need to be routed back to the game that asked the question.

Callbacks are a way to re-route interpretations to games that would otherwise not be asked to handle it. This works such that any game can register a callback, basically telling the dialog behavior "If this or that case happens, I want to handle it", and the dialog behavior then takes care of routing those cases accordingly.

Callbacks are registered per turn, i.e. they are registered during execution of bot actions and then can take effect when the next user message is interpreted. After interpretation of the user message, all callbacks are cleared.