Running workflows & review gates
Running a workflow is a loop: run a stage, look at what came back, decide, move on. Ringmaster keeps every step on disk so you can always back up, try again, or compare.
Starting a run
Open a workspace, pick a workflow from the Workflows list, and start a new run. The run opens to its stages laid out in order. A fresh run has nothing executed yet: the first stage is ready, and stages that depend on others wait until their inputs exist.
The run is filed under the window's active project — the Default project, unless you've switched to another — which is also what scopes the Recent Runs list and Search.
Running a stage
Select a stage, confirm its runtime and model, and run it. Output streams in live in the Runtime Output drawer as the agent works. When it finishes you have an attempt: one numbered, recorded execution of that stage.
When a workflow doesn't pin a runtime, the picker defaults to whatever you last ran with — so once you've settled on a runtime, new stages and new runs follow it. A workflow that names a runtime or defaultRuntime is always honored, and the picker only offers runtimes that are actually available.
You can also swap the prompt for a single run: the Prompt File row's Browse… button picks any file, and the Library… menu offers every prompt in your workspace, grouped by workflow (see Prompt Library). The override applies to attempts you start from this form, and Revert takes you back to the workflow's own prompt.
If you don't like the result, run it again. Each run is a new attempt (002, 003, …) and the earlier ones stay put. Because nothing is overwritten, trying a stage a few times and keeping the best result is a normal part of working, not a copy-paste chore.
Stage states
A stage shows where it stands:
- Ready: its inputs exist and it can run.
- Running: an attempt is in progress.
- Waiting for review: an attempt finished and is waiting on your decision.
- Succeeded: an attempt was approved (or auto-approved); its output is canonical.
- Blocked: it depends on a stage that isn't approved yet.
- Failed: the last attempt failed or hit a blocking validation failure.
- Cancelled: the attempt was cancelled; whatever output existed is kept.
The review gate
When a stage finishes, it usually pauses for review instead of advancing on its own. The core decisions are:
- Approve and promote: accept the attempt. Its artifacts become canonical and any downstream stages unblock.
- Request a revision: send it back with feedback for another attempt. If the stage uses iteration, your feedback and the prior attempt carry into the next try.
- Reject: mark the attempt as not acceptable.
You can also re-run a stage, flag an attempt for follow-up, or promote an edited copy. Promotion is the moment work moves downstream: until you approve, later stages can't see a stage's output, which is what keeps unreviewed work from flowing through a pipeline.
Changing your mind
If you un-approve a stage after the fact, Ringmaster cascades the consequence: anything downstream that consumed it goes back to blocked, because its input just changed. You're never left with a later stage built on an input you've since pulled. Re-approve, or run a new attempt, and the chain comes back.
Cancelling
A run that's taking too long, or heading the wrong way, can be cancelled. In a single-agent stage that stops the one execution. In a multi-agent stage you can cancel one slot or the whole attempt; whatever output already exists is kept, marked cancelled, so you never lose the record of what happened. Cancellation reaches real subprocesses and in-flight HTTP requests, not just the UI.
Finishing a run
A run is complete when every stage has been approved (or auto-approved). There's no separate "submit"; the run is the record. Come back to it any time from the recent-runs list; everything it produced, including the full history of superseded attempts, is still there.
You can delete a run you no longer want from the recent-runs list; it moves to the Trash, so a mistaken delete is recoverable.