Workflows.
A tool answers one question. A workflow answers a job: take this value, check it, reshape the result, hand it back. Up to 12 steps in a fixed order, where every step can use what an earlier one produced.
Why you would want one
Because the work you actually have is rarely a single tool.
Doing a job by hand means opening one tool, copying the answer, opening the next tool, pasting it in, and repeating that every time the job comes round. A workflow is that sequence, saved once. You give it the value it needs, it runs the steps in order, and it hands you the end result. The same saved workflow can then be run from your own code, so the thing you worked out by clicking becomes something a script can do at three in the morning.
A worked example
Say you get bank details from customers and you want two things at once: is this IBAN real, and what is a clean, URL-safe name for the country it belongs to. That is two capabilities, and the second one needs what the first one found.
What it looks like
| The workflow | |
|---|---|
| Workflow input | One field, iban, which you type when you run it. For example NL91 ABNA 0417 1643 00. |
| Step 1 (1) | IBAN Validator. Check an IBAN with the exact mod-97 algorithm and the country's own length rule, and name the bank country. Its iban field is wired to the workflow input. |
| Step 2 (1) | Slug Generator. Turn any text into a URL-safe slug, folding diacritics and stripping punctuation. Its text field is wired to step 1, at the path countryName. |
What comes back
Step 1 returns an object. Step 2 reads one field out of it and turns that into a slug, which is the result of the run.
{
"valid": true,
"iban": "NL91ABNA0417164300",
"country": "NL",
"countryName": "Netherlands"
}Step 2 takes the value at countryName and returns an object of its own, with "slug", "originalLength", "slugLength" in it. The last step's output is the result of the run, and the run panel shows you every step's output in full rather than only the last one.
That run costs 2 credits: 1 for the first step and 1 for the second.
The three pieces
Everything in the builder is one of these.
One capability call each, in the order you put them. You can give a step your own label, so the builder and the run panel read like your job rather than like our catalogue.
The values you supply when you run it. Each one has a name, a label, a type, and whether it is required. Give it an example value and the builder prefills it, so the workflow can be tried without thinking.
For every field a step needs, you choose where the value comes from. There are exactly three choices, below.
Where a step gets its values
Each field of each step is wired to one of three sources. This is the whole wiring model; there is nothing else to learn.
| Source | When to use it |
|---|---|
| A fixed value | You type it in the builder and it is the same on every run. Good for settings: the separator for a slug, a VAT rate, a date format. |
| A workflow input | The value is supplied at run time. Good for the thing that changes: the IBAN in the example above, the text to check, the amount to convert. |
| An earlier step | The value is read out of an earlier step's output. You pick the step and give a path into its result, so step 2 can work on what step 1 found. |
Paths, in one minute
A step output is usually an object, and a path names the piece you want. Dots go one level deeper and numbers pick an item out of a list. In the example, step 1 returns an object with valid, iban, country and countryName, so the path countryName gives you "Netherlands". A path like results.0.value would take the first item of a list and read one field out of it. Leave the path empty and the next step gets the whole output.
A path that leads nowhere is treated as a mistake, not as an empty value. The run stops and tells you what that step actually returned, because passing nothing along quietly would turn one wiring error into a confusing failure two steps later.
Test it before you save it
The builder has a test run. Fill in the inputs, press it, and you see every step, its output, and how long it took, before the workflow exists anywhere.
You are shown the real output of every step, not a prediction of it. When a step could not run, the panel names that step and says what went wrong in words you can act on. And when a tool ran with something other than the value your step handed it, the run says so against that step: a "Heads up" line naming the field, what was supplied, and what was used instead. That line is worth reading even on a run that succeeded, because the output below it is correct for what the tool actually used.
Fix what the run tells you, run it again, and save it when it does what you meant.
Steps run in order, and nothing branches
This is the one thing worth reading twice, because it is where expectations usually break.
A workflow is a straight line. There is no "if this, then that", no loop, and no step that runs only sometimes. Every step runs, in the order you put them, and each one may read the steps before it.
The verdict is in the output of the step that made it, under valid, and the run panel shows you that output in full. Nothing hides it. But nothing acts on it either, so put the check where its answer reaches you: make the validation the last step, so the result of the run is the verdict itself, or keep the later steps and read valid yourself before you act on the rest.
What does stop a run
A run stops at the first step that genuinely fails: a capability that refuses the value it was handed, a path that points at nothing, a missing required workflow input, an empty credit balance, or the whole run passing its 25 second budget. You are charged for the steps that ran, not for the ones that never started, and the result names the step that stopped it.
What a run costs
The sum of its steps, and nothing on top.
Each step is paid for immediately before it runs, so a run that stops halfway charges for the half that happened. Most capabilities cost 1 credit, so a short workflow of ordinary checks and conversions costs a handful of credits; a step that renders a PDF or asks a language model costs more, and the builder shows the price of each step as you add it. Credits and plans has the full price list.
Where your runs are recorded
Open a workflow and its history is on that page.
Your workflows lists everything you have saved, with how often each one has run and when it last did. Open one and you get its editor plus its recent runs. The history is one row per run: when it happened, where it was run from, whether it succeeded, which step stopped it if it did not, how long it took and how many credits it cost.
The step-by-step detail - each output, and any "Heads up" about a value that was substituted - is shown by the run panel at the moment you run it, so it is worth reading then rather than looking for it in the list afterwards. A very large output is stored shortened, and where it is shown it says so rather than pretending to be the whole value.
For the money side of the same picture, your usage page shows what has been spent across everything, as far back as your plan keeps history.
The limits
A workflow is a convenience, not a compute platform. Every limit exists so that a mistake in a definition cannot become a surprise bill or a stuck run.
| Steps | Up to 12 per workflow |
| Workflow inputs | Up to 10 |
| Time for a whole run | 25 seconds, after which it is stopped and recorded as a timeout |
| Name and description | 80 and 400 characters |
| Output kept per step | 20,000 bytes in history, shortened above that |
Running a workflow from your own code
A saved workflow is not only a page on this site.
It has an id, and with an API key you can run it over the REST API and get the same result back as JSON. That is how a workflow you built by clicking ends up inside a nightly job or a form on your own site. API and MCP shows the call.