Contexts are the skeleton of an application developed with Kogno, since in these, a large part of the logic of capturing, processing and replying to an incoming message is developed.

In a given project, all the contexts needed can be created in order to develop a well structured conversation.

Making a parallel with Ruby on Rails or the MVC architecture, the contexts would be the equivalent of controllers.

Creating a new Context

A context is represented by a class which is declared as follows:

class TheContextNameContext < Conversation

Basic rules to create a new context

  1. All contexts created must inherit from the Conversation class.

  2. The class name must end in Context. Ex: MainContext, ProductsContext, PurchaseContext and so on.

  3. All context files must be located in the bot/contexts/ directory under files with ".rb" extension. Ex: the_context_name_context.rb, profile_context.rb ,people_context.rb and so on.

Default context: MainContext

In a new project, the context MainContext is created by default into the file bot/contexts/main_context.rb.

This is the general context of the conversation and the context by default in a new conversation.

All the logic of capturing, processing and replying to a message from a user that is in a conversation without a context, will be developed here.

Change the default context

The default context can be changed by modifying the config.routes.message field in config/application.rb configuration file.

blocks() method

The blocks() method is declared in a Context class and within it, the action blocks necessary to capture messages with the characteristics that the context is expecting to handle.

class MainContext < Conversation

  def blocks
      # Here you will define the action blocks.

Usage Example

In the code below, see how MainContext can handle the following scenarios with the declaration of 3 action blocks:

  • intent "greeting" : A greeting messages, such as "Hello" or "Hi". If the intent exists and has been trained on the NLP engine.

  • postback "email_subscription": A click event, that occurs when the user clicks on the button "Subscribe Me" replied by the block above.

  • everything_else: A generic response, in case the message were not any the ones declared above.

class MainContext < Conversation

  def blocks

    intent "greeting" do 
      @reply.text "Hello!"
        "What can I do for you?",
            title: "Subscribe Me",
            payload: "email_subscription"
            title: "See Featured Products",
            payload "products/featured"
    postback "email_subscription" do
      @reply.text "Great!"
      @reply.typing 1
      ask "/profile/ask_email"
    everything_else do 
      @reply.text "My answers are still a bit limited."


The ask() method, that together with the block answer, focuses and reduces the conversation to achieve a goal. In this case "get the user's email".

Read more in the ask & answers chapter.

Multi-Context conversation

When the logic of the conversation becomes broader, a better distribution of the code will be very helpful.

For this reason, it's recommendable to create as many contexts needed, in a similar way to when the controllers are created in the MVC architecture.


For this example we will create a new context called ProductsContext in bot/contexts/products_context.rb.

class ProductsContext < Conversation

  def blocks
    postback "featured" do
      products = Product.where(featured: true).limit(10)
      @reply.text "Here you can see our featured products 👇"
      @reply.template "products/carousel", products: products


And remembering the first example above, in the hypothetical scenario in which a user clicks on the second button "See Featured Products" (payload: "products/featured") that has been sent as reply in the block intent "greeting".

The click event will delegated in order to be handled by the ProductsContext, since the payload contains a route to this context. Learn more about this in Context Routing chapter.

Moving between contexts

These methods are used to take the conversation from one context to another:

change_to(route=String, params=Hash)

Changes the context of the conversation, from the current context to another context or sub-context.

After this method is called, all incoming messages from a particular user will be captured by the context defined in the route argument, and this context will remain active until the context changes again or exit_context() method were called.


Change to other context:

change_to "some_context_name"

Change to a sub context from other context:

change_to "some_context_name/sub_context_name"

Change to a sub context in the same context

change_to "./sub_context_name"

Change From a sub context to his parent context:

change_to "../sub_context_name"



route String


Contains a context's name of a path to a context or sub-context.

params Hash

Optional. Only available for sub-contexts. It sends parameters to the sub-context defined. Read more in sub-contexts chapter.

delegate_to(route=String, args=Hash)

It delegates the handling of the incoming message to a context or sub-context, but without the conversation changing context.


delegate_to "some_context_name_or_path", ignore_everything_else: false

The format of the route argument is the same as with the change_to() method.



route String


Contains a context's name of a path to a context or sub-context.

args Hash


If ignore_everything_else is true, it will not execute the everything_else block, if it exists in the delegate context. By default false.


Exits the current context and takes the conversation to the default context.




Keeps the conversation in the delegated context. Whether it was delegated by context routing or by calling the delegate_to() method.



Last updated