# Loop Builder

Loop Builder turns an agent task into a workflow you can inspect: a goal, explicit inputs, ordered steps and a result to check. Use the canvas to prepare work, the run record to see what executed and the next draft to improve what failed. Saving a plan is not permission to execute it.

**Loop Builder workflow from schedule and webhook triggers through an agent step to its outputs**

[Open the interactive Studio scene](/docs/studio-artifacts/docs-scenes/loop-builder.html)

## Start with the work you have

- [Create and inspect a canvas loop](/docs/loop-builder/quickstart) without a model request or execution.
- [Review agent performance](/docs/loop-builder/review-agent-performance) from a particular run and its actual output.
- [Schedule a governed loop](/docs/loop-builder/schedule-a-loop) only when future execution is intended.
- [Review a hosted version](/docs/loop-builder/review-a-version) when you have an immutable generated package rather than a canvas function workflow.

## Build, execute and evaluate separately

### Prepare the draft

Name the goal, inputs and observable output. Manual steps preserve instructions; executable steps require an available function with explicit arguments. Inspect earlier-step output bindings before running. **Ask assistant** can propose a loop under the workspace's function rules; a suggestion is not completed work.

### Inspect authority and actions

Open **Permissions & spending** to read the current workspace rules. **Runs & approvals** exposes exact governed actions, which can require approval before dispatch. Approval can execute the pending action. A text instruction, a checkpoint label or a saved draft does not grant access.

Keep long-lived rules in [Policy Hub](/docs/shared/policy-hub), and inspect its runtime records separately from the documents. Do not raise limits or remove approval requirements merely to clear a failed run.

### Check the result before improving it

Read the output against your acceptance check. A completed step does not establish that other steps ran or that the final result is useful. Change the draft based on that evidence, then make another deliberate execution decision. Missing usage or timing observations stay unavailable; no automatic performance gain is implied.

## Keep the hosted artifact lifecycle distinct

A hosted candidate is an immutable generated package. **Activate in Bar** makes that exact reviewed version available but starts no run. Invocation supplies its own inputs and cloud-processing consent. None of these states, by itself, establishes a recurring schedule or a successful result.

Hosted generation needs `cloud.loops.build`; hosted invocation needs `cloud.loops.run`. Your account can have one without the other. These capabilities are separate from the canvas function policy.

Open [Loop Builder](https://dashboard.ouros.md/loops/builder) for the canvas or [Saved Loops](https://dashboard.ouros.md/loops/saved) to inspect a hosted version. Keep unreadable packages unapproved. Use [versions and runs](/docs/loop-builder/version-and-run), [hosted run reference](/docs/loop-builder/run-reference) and [uncertain-operation recovery](/docs/loop-builder/troubleshooting) for that contract, not the governed workflow schema.
