Steps

Write step prompts, order tasks, and transition through a workflow.

Every step directory requires a nonempty prompt.md and a functions.yaml containing a YAML array. Use [] if a step has no functions. Put each function in the step where the assistant should be able to call it.

The files below complete the booking request workflow.

Collect the request

reception/workflows/booking/01-details/prompt.md
Ask for the caller's name and preferred appointment date and time, one question
at a time. Clarify ambiguous dates using the local time in context.
Do not promise availability. Once all details are clear, call proceed.
reception/workflows/booking/01-details/functions.yaml
- name: proceed
  description: Continue once the caller's name and preferred appointment date and time are clear.
  args: []
  execution:
    type: builtin
    operation: transition
    target: finish_step

Confirm the request

reception/workflows/booking/02-confirm/prompt.md
Summarize the caller's name and requested date and time, then ask if they are correct.
If details need changing, call change_details.
If the caller confirms, explain that no appointment has been booked by this
example assistant, then call finish_request. Do not claim the request was sent.
reception/workflows/booking/02-confirm/functions.yaml
- name: change_details
  description: Return to collecting details when the caller wants to correct the request.
  args: []
  execution:
    type: builtin
    operation: transition
    target: regress_workflow
    step: 01-details
- name: finish_request
  description: Finish after the caller confirms the request and understands that no appointment has been booked.
  args: []
  execution:
    type: builtin
    operation: transition
    target: exit_workflow

Add a booking function and update the confirmation prompt when you connect an appointment service. Completing a step does not itself perform an external action.

Step order and names

Step directories sort by name using numeric comparison: 2-details precedes 10-confirm. Alphabetical comparison breaks ties. Numeric prefixes are optional; using 01-, 02-, and so on makes the intended sequence easy to see.

For display, a leading numeric prefix followed by - is removed and hyphens become spaces: 01-collect-details becomes collect details. References always use the full directory name, including the prefix.

Transition targets

Transition fields in executionBehavior
target: finish_stepReturn to the calling step during regression; otherwise move to the next step in directory order, or end the workflow after the last step.
target: exit_workflowEnd the workflow and return to default.md. This does not end the phone call or undo completed actions.
target: 01-detailsJump to the named step in the current workflow and clear any pending regression return.
target: 02-confirm, workflow: bookingJump to a specific step in another workflow of the same assistant and clear any pending return.
target: regress_workflow, step: 01-detailsRevisit an earlier step in the same workflow, remembering the calling step for finish_step.

Transitions are allowed only in a step's functions.yaml. Their owning step is inferred from the file location. You do not specify an owner ID. Destinations must exist in the same assistant. For explicit jumps, omit workflow to use the current workflow; update references when you rename a step or workflow.

target is always a string: finish_step, exit_workflow, regress_workflow, or a step reference. These three behavior names are reserved. Regression requires a sibling step field; other transitions must omit it. workflow is allowed only for explicit step jumps.

GitHub configuration and the dashboard use the same transition operation. In the dashboard, add a built-in Transition, choose its behavior and destination, and describe when the assistant should call it. Destinations are configured by the author, not passed as model-generated function arguments.

Regression and required follow-up steps

Regression remembers one return step. If D regresses to A and A calls finish_step, the assistant returns to D and clears the return. If A explicitly transitions to B, that cancels the return: B's finish_step advances normally to C.

Use explicit destinations for required follow-up work, such as checking availability after changing an appointment date. Regression supports earlier steps in the current workflow; nested regressions are rejected. Exiting or starting another workflow also clears the pending return.

All transitions preserve saved variables and conversation context. Step prompts remain exactly as authored. A destination step should use saved information and validate any prerequisites that may be missing or outdated. Transitions do not undo completed actions or execute external functions automatically.

A step supports up to 17 functions, including transitions. Function names must be unique within the file and must not collide with assistant-level functions. Different steps can reuse a name such as proceed.

Put lasting instructions in base.md and the current task in prompt.md. See Prompts for how instructions and context are combined.

On this page