Build agent workflows with reviews and approval gates
Define who implements, who reviews and what happens after a failed check. Inspect the execution graph instead of relying on one unstructured conversation to manage the whole task.
- Define roles and edges
- Review the graph
- Run, inspect and decide
Before you start
- Use the desktop app for the visual run graph, or /orchestrate and /runs in the terminal for CLI workflows.
- A repository task with explicit acceptance criteria.
- Available models for the roles you choose.
- A cost/time budget and a finite limit for retries.
Work through it
Describe the roles and stopping conditions
Ask for a planner, executor, reviewers and an arbiter only where the task needs them. Define what each receives and whether it may edit. Choose an approval gate before consequential actions.
Check: Name the tests and review criteria. Put a maximum on every retry loop.
Inspect before starting
Review the generated workflow, model assignments and edges. Agent, judge, parallel, council, shell and gate nodes do different jobs; a failure branch should lead somewhere intentional.
Check: Do not mistake a displayed graph for an approved run. Check shell steps and deployment boundaries.
Follow the run and its evidence
Use the live run graph and workbench to inspect activity, findings and model usage. On failure, use the bounded correction path or stop. Review code and test output before accepting the result.
Check: A judge’s verdict supports a decision; it does not replace independent checks of the changed application.
Design the control points
Parallel reviewers
Separate contexts inspect different risks, such as correctness and security.
Human gate
Pause for your answer before work crosses a consequential boundary.
Bounded retry
Return failed work to the executor without creating an endless spending loop.
A prompt to adapt
Replace the task details with your own. This is a suggested instruction, not a recorded result or a security policy.
/orchestrate Design a workflow with an implementation agent, read-only correctness and security reviewers, and an arbiter. Run reviews in parallel. Allow at most two correction rounds. Require my approval before a commit, push or deployment. Show the graph before starting it.Keep these boundaries clear
Open the detailed guides
Checked against the documentation on .