Using prompt steps

Use prompt steps to call AI models and produce text or structured data in a Flow.

Add a prompt step

To add a prompt step, follow these steps:

1. In the Flow editor, click Add Step.
2. Select Run Task for a single prompt, or select Run Agent for a conversational prompt with message history.
3. Configure the step with these fields:
   • Name: Enter a descriptive label, such as Generate summary.
   • Model: Select an AI model.
   • User: Write the prompt text.
4. Click Save.

Write prompts

Write a specific instruction that names the task, required format, and important constraints.

A vague prompt leaves the output format open:

Summarize this.

A specific prompt defines the required length and focus:

Summarize the following customer email in 2 to 3 sentences.
Focus on the main request and any urgency indicators.
Email: {{EMAIL_TEXT}}

Replace EMAIL_TEXT with the Flow input that contains the customer email.

Use template variables

Use template variables in prompts to reference Flow inputs and outputs from previous steps:

You are a customer support agent for {{COMPANY}}.
Customer message: {{CUSTOMER_MESSAGE}}
Customer tier: {{CUSTOMER_TIER}}
Previous interactions: {{PREVIOUS_INTERACTION_COUNT}}
Provide a helpful, professional response.

Replace COMPANY, CUSTOMER_MESSAGE, CUSTOMER_TIER, and PREVIOUS_INTERACTION_COUNT with the corresponding Flow input or step output names. Flow input names come from the inputs field. Step output names come from outputVariable.

Choose a model

Use a routed model ID such as claude-sonnet-4-6, gpt-5.4-mini, or gemini-3-1-flash-lite. Runtype routes these IDs to supported providers without a provider-specific version in your Flow. Choose a model based on task complexity, response time, and cost.

Configure parameters

Use Advanced settings to adjust model behavior.

Temperature

Set Temperature from 0 to 2. Lower values reduce variation, and higher values increase variation.

Runtype omits Temperature for models that reject the parameter. Claude 5 models and some GPT-5 models reject it. Use Top P to control variation when a model does not support Temperature.

Max tokens

Set Max tokens to limit the response length. Leave it on Use model default when you do not need a custom limit.

System prompt

Use the System editor for role definitions and instructions that apply across the prompt.

Advanced sampling parameters

The editor shows provider-supported sampling parameters. The following table describes their ranges and effects:

Not every provider supports every parameter. The editor shows the parameters supported by the selected model’s provider. Leave a parameter on Use model default to use the provider’s default value.

Reasoning

To use reasoning, select a model that supports it. The editor then shows Reasoning and the controls that model accepts.

Select Enable reasoning to allocate part of the model call to reasoning. The editor reads the effort levels and the budget range from the selected model’s own catalog entry, so it offers only the values that model accepts. The following table lists the controls by provider:

Two models from the same provider can offer different levels. gpt-5.6-luna offers Low, Medium, High, and Extra high, and does not offer Minimal, while gpt-5-mini does offer Minimal.

A model served from an OpenAI-compatible custom endpoint shows Reasoning effort only after it is declared as a reasoning model on its model configuration, and offers low, medium, and high. Runtype sends the chosen value as reasoning_effort without checking it against the endpoint. For the declaration and how the value on the wire is chosen, see Reasoning models on OpenAI-compatible endpoints.

Claude 4.6 and later, and the Claude 5 family, use adaptive thinking. Adaptive thinking carries no token budget, so the editor shows Reasoning effort for those models and no budget input. If a step still carries a budgetTokens value from an earlier model choice, Runtype drops it before it sends the request and validation reports REASONING_KNOB_UNSUPPORTED. For more information, see Flow validation warnings.

Some models always reason. On those, turning reasoning off selects the model’s lowest effort level instead of disabling reasoning, and the editor says so under the Disable reasoning option.

If a step carries an effort level the selected model does not publish, the editor keeps the saved value in the list and marks it as one the model does not accept. Pick another level to replace it.

Higher effort and larger budgets use more tokens and can increase response time. For short extraction or classification tasks, leave reasoning off.

Test prompts in the Playground before you add them to a Flow. Use the Playground to compare prompts without running the full Flow.

Access output

Set an outputVariable for each prompt step. Reference that variable in later steps with this syntax:

{{SUMMARY_RESULT}}

Replace SUMMARY_RESULT with the step’s outputVariable value.

If you set responseFormat to json, access properties in the returned object with dot notation:

{{EXTRACT_DATA.customerName}}
{{EXTRACT_DATA.orderAmount}}

Replace EXTRACT_DATA with the step’s outputVariable. Use property names that the JSON response returns. Use the outputVariable value, not the step name, in every reference.

Handle errors

Prompt steps can fail when an API quota is exhausted, a model rate limit is reached, or an API key is invalid. A prompt can also exceed the model context.

Choose how a prompt step handles an error:

• Continue on error: Skip the failed step and continue the Flow.
• Stop on error: For prompt steps, report the failure and continue to the next step.
• Use fallbacks: Try configured alternatives before the step reports failure.

A fallback chain runs each fallback in order until one succeeds. Each fallback has one of these types:

• Retry: Run the same model again.
• Different model: Switch to a backup model with optional temperature and max tokens overrides.
• Fixed message: Return a pre-written reply without calling a model. Use this as the last fallback when you want an author-written response after model fallbacks fail.

Choose when to run the fallback chain:

• The step errors: Run fallbacks when a provider error, timeout, or thrown failure occurs.
• The reply is empty: Run fallbacks when the model finishes without visible text.

You can enable both triggers. A provider can return a refusal without a transport error. When The step errors is enabled, that refusal triggers the fallback chain. Retry is skipped for a refusal because it calls the same model and configuration. Use Different model or Fixed message when you need a different response after a refusal.

If a fallback returns a refusal, the chain advances to the next fallback. Add Fixed message last when you want a non-model response after other fallbacks fail.

Tool call strategy

When you attach tools to a prompt step, set Tool call strategy in the tools panel to control whether the model calls a tool:

Use Auto for most prompt steps. Use Required only for one forced tool call. Set maxToolCalls to 1. If you leave maxToolCalls unset or set it higher, the step can return empty output because the model remains in tool-call mode.

Best practices

Use these practices when you write prompt steps:

• Be specific: State the task, input, output, and constraints.
• Provide examples: Include representative input and output when the format matters.
• Request structured output: Set responseFormat to json when later steps need structured data.
• Keep context concise: Include only the information the model needs.
• Test variations: Use Evals to compare prompts and models.

Next steps

Use these pages to continue working with prompt steps:

• Creating and editing flows: create and test a Flow
• Flow variables and templates: pass data between steps
• Using transform-data steps: process prompt output
• Running an eval: compare prompt and model variations