How to check identity before changing a booking in Rasa

Goal

Compose small skills into a booking-change journey with authentication and confirmation.

Teach

When a skill needs another skill’s logic mid-conversation, reference it with @skill.<name>. The parent skill waits while the other skill runs. That skill exports its public memory, then the parent resumes.

Find the booking: @skill.find_booking

Parent skills can also declare a precondition. The skill names it in its frontmatter:

precondition: authenticated

and agent.yml says when the precondition holds and which skill satisfies it:

orchestrator:
  preconditions:
    authenticated:
      satisfied_when: session.project.authenticated
      resolve_with: authenticate

If the customer is not authenticated, Mantle pauses the booking-change skill and runs the authentication skill first. It resumes the booking change once authentication succeeds. The memory field records the result. The precondition decides what runs first. Rasa Pro 3.21.0.dev3 rejects the older skill-level requires: key, which hid the skill from routing until the field was true.

Identity is the precondition’s job, not the prose’s. Leave out a line such as First verify identity: @skill.authenticate in change_booking: the engine already runs authenticate when it is needed, and a second copy in the instructions can start it again for a traveller who has already signed in.

Where shared fields live

A tool writes memory under the skill that is active at that moment. Booking selection runs inside the lookup skill. If that skill owned the selected reference, the booking-change skill could not use it to check readiness:

Put fields shared by several skills in the project’s root memory file. They are then available under the project namespace, regardless of which skill is active:

# memory.yml (project root)
selected_booking_ref:
  type: text
  description: Booking reference the traveler has settled on for this request.
selected_trip_name:
  type: text
  description: Trip name for the selected booking.

A good rule of thumb: a field used by exactly one skill belongs to that skill, and a field that is a handoff between skills belongs to the project.

Confirming an irreversible tool

tool_constraints:
  - cancel_booking:
      requires: session.project.selected_booking_ref
      requires_confirmation:
        enabled: true
        utter_for_confirmation: utter_confirm_cancel_booking
        utter_on_user_denial: utter_cancel_aborted
      on_success: utter_booking_cancelled

Note the division of labour between the two gates. The readiness check hides the tool until its required data exists. The confirmation check makes the engine ask the customer before running an available tool. You rarely need a separate “did they confirm?” memory field, because the confirmation gate already is that check.

Composition rules:

• Prefer small, focused skills that export shared state through project memory
• The parent must have meaningful business logic of its own
• @skill is coordinated; user interrupts are not guaranteed to resume the same way

Paste

Paste set: tutorial/snippets/step-06-composition/

Copy the three skills and the updated project memory file, which adds the two shared booking fields:

skills/authenticate
skills/find_booking
skills/change_booking
memory.yml

You can also copy the remaining handoff, goodbye and introduction skills:

Source: tutorial/snippets/step-07-remaining/
Skills: human_handoff, goodbye, intro

Demo PIN: four two four two (4242).

Train and try

make train
make inspect

Try: “I need to cancel a booking.”

Verify: Atlas authenticates, finds a booking, asks for confirmation, then cancels only after approval.

Talking point

Authentication is reusable across every sensitive skill. Transaction or booking lookup is reusable across changes, baggage, and status. Parents own the business outcome.

Next

Chapter 9 — Voice deep dive