Playbook instructions

Playbook instructions define the process that you follow to accomplish the playbook goal.

Each step contains a natural language instruction that can contain any of the following:

  • A basic instruction that you can write for the LLM to understand.
  • An instruction to route the user to another playbook, referencing them using the form ${PLAYBOOK: playbook_name}.
  • An instruction to use a specific playbook tool, referencing tools using the form ${TOOL: tool_name}.
  • An instruction to route the user to a flow, referencing flows using the form ${FLOW: flow_name}.
  • A reference to a playbook parameter, referencing parameters using the form $parameter_name.
  • An instruction to call a code block, referencing code blocks using the form `function_name`.

Each step description starts with - and an optional numbered step, and you can define sub-instructions using indentation.

Example:

- greet the customer and ask them how you can help.
    - If the customer wants to book flights, route them to ${PLAYBOOK: flight_booking}.
    - If the customer wants to book hotels, route them to  ${PLAYBOOK: hotel_booking}.
    - If the customer wants to know trending attractions, use the ${TOOL: attraction_tool} to show them the list.
- help the customer to pay for their booking by routing them to ${FLOW: make_payment}.

Instruction steps

To add structure to your instructions, you can optionally define steps with a hierarchical numbering system. If you don't provide step numbers and a code block references a particular step, the ordering of steps determines step position values.

Example:

- Step 1. Greet the user and ask how you can assist them today.
- Step 2. Collect the user's basic flight information in the following order
  from (a) to (f). Don't deviate from this order, and don't proceed until the
  user has specified each piece of information. Ask clarifying questions if
  necessary, and make sure that the answers the user gives make sense.
    - Step 2.1 The traveler's $origin city. Don't proceed until the user has
      made this clear.
    - Step 2.2 The traveler's $destination city. Don't proceed until the user
      has made this clear.
    - Step 2.3 When the traveler will leave their origin city. If the user
      specifies one departure date, collect their $earliest_departure_date. If
      the user specifies a range of departure dates, collect their
      $earliest_departure_date and $latest_departure_date. Unless otherwise
      specified, assume all dates are from 2024 to 2025. If the user provides
      a vague departure date, ask them follow-up questions to determine their
      precise departure date(s). All dates should be in YYYY-MM-DD format. If
      the user does not provide their departure date(s) in YYYY-MM-DD format,
      then convert the dates for them.
    - Step 2.4 When the traveler will leave from their destination city and
      return home. If the user specifies one return date, collect their
      $earliest_return_date. If the user specifies a range of return dates,
      collect their $earliest_return_date and $latest_return_date. Unless
      otherwise specified, assume all dates are from 2024 to 2025. If the user
      provides a vague return date or a vague return date range, ask them
      follow-up questions to determine their precise return date(s). All dates
      should be in YYYY-MM-DD format. If the user does not provide their return
      dates in YYYY-MM-DD format, then convert the dates for them.
    - Step 2.5 The $num_adult_passengers the user wants to buy tickets for. All
      people 12 years old or older are adult passengers. This value must be a
      precise whole number. Don't proceed until the user has provided a valid
      number of adult passengers.
    - Step 2.6 The $num_child_passengers the user wants to buy tickets for.
      This value must be a precise whole number. Don't proceed until the user
      has provided a valid number of child passengers.
    - Assume the user is an adult.