Workflows
Workflows mode chains independent agents into a reusable, named pipeline that runs in the background — research → draft → review — where the workflow owns the sequencing, not the agents. Each step is just an existing agent (or one you create as you build), so agents stay reusable on their own while the workflow coordinates the hand-off, lifecycle, and schedule. Workflows ride on the Agents opt-in — there's no separate switch, so enabling agents is what turns them on.
Start here
| Guide | What it covers |
|---|---|
| Building a pipeline | Creating a workflow, editing steps on the board, and the four step kinds. |
| Configuring a step | Instructions, placeholders, pipeline state, and narrowing what a step is fed and may use. |
| Running a pipeline | Triggers, the run brief, the run trace, failures, cost, and notifications. |
| Reference | The /api/workflows surface and sharing a workflow as YAML. |
| Authoring spec | A precise, machine-oriented specification — hand it to a coding assistant that must generate a workflow. |
What the workflow owns
An agent knows nothing about its neighbours and can't trigger another one. All the chaining lives on the workflow:
- Reusable, not baked in. A workflow references agents by id. The same agent can appear in several workflows; the chaining lives on the workflow, so you reorder or reuse steps without touching the agents themselves.
- One coordinator. The workflow drives the run — it starts the first step, waits for it to rest, feeds its output to the next, and advances down the line.
- Implicit hand-off. Each step receives the immediately preceding step's full answer plus its artifacts as a kickoff preamble, mirroring a pipeline stage. You don't have to prompt a step to "use the previous result" — the coordinator forwards it. No dependency graph to reason about.
- Shared blackboard. Beyond that immediate hand-off, a step also inherits the artifacts published by every earlier step in the run, labelled by step and oldest-first. A reviewer three stages down still sees the research inventory the first step produced — without the middle steps having to re-forward it. Steps that published nothing are skipped, and gates (which leave no deliverable) never appear on the board.
The four kinds of step
Every step is one of four kinds. The first two produce work; the last two judge it and are transparent to the data flow — they forward the last real producer's output rather than anything of their own.
| Kind | Runs | What it's for |
|---|---|---|
| Agent | a reusable agent from the Agents section | the normal case — a stage you want to reuse across pipelines |
| Inline | a private, hidden vessel that dies with the step | one-off work that doesn't deserve a permanent agent |
| Gate | an agent that votes PASS / FAIL | an automated quality check that can send the run back to an earlier step |
| Approval | nobody — the run parks | a human checkpoint in front of anything irreversible |
Steps run autonomously — they never stop to ask
A workflow runs unattended: once you start it, there is no human sitting in the loop to answer a mid-run question. So every task step is launched with a strict autonomy directive — it must carry out its objective directly on the input it was handed, and it is explicitly forbidden from asking for clarification, presenting a menu of options, or emitting NEED_INPUT. If a detail is under-specified, the step picks the most reasonable interpretation and produces the deliverable anyway.
This keeps bare chains flowing without careful prompting. A step like note this joke from 0 to 10 just scores the joke it received, rather than stopping to ask "what did you mean by note?" — which would otherwise park the step Blocked and pause the entire run.
Gates are exempt: they follow their own PASS/FAIL contract. And an approval checkpoint is the deliberate exception — the one place a pipeline is designed to wait for a person.