A workflow runs the same stages in the same way every time. Where an agent decides its own steps, you decide a workflow's steps ahead of time by picking a pattern and filling in its slots. You don't draw a flow; there are five ready-made shapes.
A single assistant or agent is often enough. Reach for a workflow when the stages really are fixed and you want a predictable, repeatable result, often cheaper because each stage can use a smaller model.
When you create a workflow you choose a pattern. Each one has a worked example you can start from with Use example; the examples use model stages only, so they run on every plan. Pick the models yourself, since which ones you can use depends on your workspace's providers.
| Pattern | Use it when | Trade-off |
|---|---|---|
| Chain | A job is a fixed series of steps: draft, review, format. | Each step is a separate model call, so it is slower but more accurate. |
| Routing | Different inputs need different handling, like triaging requests. | A small model sorts the input and only the matching branch runs, so cheap inputs stay cheap. |
| Parallel | You want one input reviewed from several angles, or a yes or no decided by a vote. | Voting asks the same question several times, trading cost for confidence. |
| Orchestrator-worker | The subtasks aren't known until the input is read, like research. | A planner decides the subtasks while the run is going, so cost varies with the input. |
| Evaluator-optimizer | Output has a quality bar, like translation or copy. | It spends more calls for quality: generate, evaluate, try again with feedback. |
Stage 1, then stage 2, and so on; each stage's output is the next stage's {{previous}}. After any stage you can add a check that either stops the run or retries that stage once with the failure as {{feedback}}. A check can be a length rule, required or forbidden text, a match against the stage's output schema, or a model that judges the output. A stage can also save its output under a name and a later stage can read it as {{state.name}}.
Example: Draft, then Edit, with a length check after the edit.
A classifier reads the input and picks one category you defined; each category has its own branch (a prompt on a model, or an existing agent). It can only pick your categories, or "none", which runs the fallback branch.
Example: sort a support request into billing or bug, and answer each its own way.
Two modes:
At most four stages run at the same time.
A planner reads the input and returns a list of subtasks, a worker runs each one, and a final stage assembles the answers. Unlike Parallel, the subtasks are decided while the run is going. You set the most subtasks allowed, and can ask for your approval of the plan before the workers start.
Example: split a research question into up to three sub-questions, answer each, then write it up.
A generator writes, an evaluator checks, and if it falls short the generator tries again with the feedback, up to the number of attempts you set. It stops early if an attempt doesn't improve, and returns the best attempt, not necessarily the last. Prefer a check (length, text, schema) to a model judge when one fits: it is free and gives the same answer every time. A judge scores 0 to 10 against a passing score you choose.
Example: rewrite a product description until a judge scores it 8, up to three attempts.
Prompts can use {{input}} and, where the pattern allows it, {{previous}}, {{feedback}}, {{subtask}} or {{outputs}}. Nothing else is filled in: there are no expressions and no code. To get structured output, give a stage an output schema; if the answer doesn't match, the model gets one repair attempt before the stage fails.
A stage can use tools, and in several patterns a stage can be an existing agent instead of a prompt on a model. An agent stage counts as one more run of your daily limit.
A run is a run like any other: it counts toward your plan's runs-per-day limit and is billed like one. The form shows a cost estimate before you run: the most model calls the run can make and how many runs of your daily limit it can use. It is an upper bound.
Save up to ten inputs on a workflow, then use Run all after an edit to run each one and read the new result next to the previous one. Nothing is scored, so you judge whether the change helped. Run all uses the saved workflow, not unsaved edits, and shows its cost before it starts.
A workflow can start on a schedule or from a webhook, the same way an agent can; see the schedules and webhooks in the Agents guide. Turn on Notify me when a run ends on a trigger to get an email with the result, or the failure, when a run it started ends.
An admin can attach workflows to an agent. The agent then gets a run_workflow_<name> tool for each one, runs it as part of its own task and uses the result. Attaching is done through the API for now; the agent form doesn't have it yet.
An admin can attach agents and workflows to an assistant, on the assistant's Tools tab. The assistant gets a tool for each one and can hand a customer's request to it: a Routing workflow that sorts a message into complaint, refund or other, for example, and the assistant relays the outcome. For each one you choose whether the assistant waits for the result (up to a time you set, 45 seconds by default) or runs it in the background and just says it has started. A run that is not done in time carries on by itself; the assistant tells the customer it is still being worked on. You can also make the assistant ask for approval before each call, except on an assistant with a web widget or a Telegram bot, where nobody is there to approve.
What a customer writes is text from outside. Keep approval on any tool inside the workflow that acts outside the platform.