From Understanding to Action: Teaching Your Assistant to Respond

NLU answers:

“What did the user mean?”

Dialogue management answers:

“What should I do about it?”

In Rasa, this logic is built using four core components:

• Domain files
• Stories
• Rules
• Slots

Let’s break them down.

The Domain File: Defining the Assistant’s World

The domain file lives here:

domain.yml

This file defines everything your assistant knows how to do.

version: "3.1"

intents:
  - greet
  - book_flight

entities:
  - location

slots:
  location:
    type: text
    mappings:
      - type: from_entity
        entity: location

responses:
  utter_greet:
    - text: "Hello! How can I help you?"

  utter_ask_location:
    - text: "Where would you like to travel?"

actions:
  - action_book_flight

The domain defines:

• What intents exist
• What entities exist
• What slots store
• What responses are available
• What custom actions can run Think of it as the assistant’s capability registry; if it’s not in the domain, it doesn’t exist.

Slots: Memory Between Turns

NLU understands a single message. Slots allow your assistant to remember information across messages. Slots are your assistant’s working memory; without them, every message is isolated.

Stories: Teaching Multi-Turn Behaviour

Stories describe example conversations and live in stories.yml.

Example:

stories:
  - story: book flight happy path
    steps:
      - intent: book_flight
      - action: utter_ask_location
      - intent: inform
        entities:
          - location: Madrid
      - action: action_book_flight

Stories show the dialogue model:

1. Which intent starts a flow
2. What action follows
3. How slot filling changes behaviour
4. When to execute business logic
5. Under the hood, Rasa uses a transformer-based dialogue policy (TED policy) to learn patterns across these conversation examples.

Unlike rule systems, it generalises beyond exact story matches.

Rules: Deterministic Behaviour

Sometimes you don’t want learning, and want certainty and rules live in rules.yml.

Examples:
rules:
  - rule: respond to greeting
    steps:
      - intent: greet
      - action: utter_greet

Rules are:

• Deterministic
• One-intent → one-action
• Ideal for FAQs, greetings, confirmations

Use rules for predictable behaviour and use stories for flows.

Common Dialogue Design Mistakes

Just like NLU, dialogue design has pitfalls.
Avoid:

• Overusing rules for complex flows
• Writing too few stories
• Ignoring unhappy paths
• Forgetting slot resets
• Embedding business logic in responses

And most importantly:
Do not confuse intent prediction with behaviour control.

Intent prediction tells you what the user wants, whereas dialogue management determines what happens next.

What You’ve Built So Far;

Hopefully by now, you understand:

• Pipelines
• Rules
• Training
• Dialogue
• Model Behaviour and the basics of rasa...

Following this blog, the next one will probably be the last one to actually showcase a complete script to you.
So you can practically understand all the concepts through examples.
So, Until next time....