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
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.- 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_stepConfirm the request
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.- 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_workflowAdd 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 execution | Behavior |
|---|---|
target: finish_step | Return 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_workflow | End the workflow and return to default.md. This does not end the phone call or undo completed actions. |
target: 01-details | Jump to the named step in the current workflow and clear any pending regression return. |
target: 02-confirm, workflow: booking | Jump to a specific step in another workflow of the same assistant and clear any pending return. |
target: regress_workflow, step: 01-details | Revisit 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.