Registering Workflows & Status Gating
A workflow is a runnable pipeline entry: it ties together the configuration your agents use, the engine that executes it, the guardrails it runs under, and the workspace statuses it moves between. Workflows are where all the configuration you've built becomes something an operator can actually launch.
What a workflow references
Registering a workflow means giving it a name and connecting it to:
- one workflow configuration set (which agents, models, and prompts it uses);
- one service configuration set (the outside vendors it may call);
- a workflow engine — required; a workflow can't be saved, enabled, or run without one;
- guardrails: a maximum execution time and a maximum cost per run;
- eligible input statuses — the workspace statuses a run may be launched from (you can list several);
- exactly one resulting status — the status a workspace moves to on success;
- optional system-wide config overrides for this workflow.
Status gating: why a workflow appears or doesn't
The eligible and resulting statuses are what make a pipeline flow. A workflow only shows up as runnable when the active workspace is in one of its eligible input statuses — so an operator is offered exactly the workflows that make sense for where the work currently stands. On success, the workspace advances to the workflow's single resulting status, which typically becomes the eligible input for the next stage. Progression is always operator-driven: even after a workflow completes, you choose and launch the next one — nothing advances automatically.
Enablement and dependency health
A workflow has an enabled/disabled status, and it can be disabled automatically if the configurations it depends on become invalid. Trying to re-enable it will fail while any dependency problem remains — you have to heal the chain first (see The Dependency Chain & Disable Cascades). Together with the guardrails, this is what keeps a run from starting unless everything it needs is valid and within its limits.