Define the loop. Orchestro runs it.
Updated Read as Markdown ↗
A loop is work plus checks plus limits, running on a schedule until you change it.
Every Orchestro loop answers the same five questions: what is the goal and how is it measured, what work moves it, what checks prove the result, what the loop may never do without you, and when it runs next. The Factory does the work, the Governor keeps it moving, and the answers above are what keep it safe to leave running.
The anatomy of a loop
| Part | What you declare | Example: repair loop |
|---|---|---|
| Goal + measure | One primary metric, population, window, target | Onboarding activation, 64% within 24 hours |
| Work | What the agents do each round | Reproduce, fix the cause, release |
| Checks | Independent proof, separate from the worker | Behavioral check on the release |
| Limits | Permissions, budget, approvals, guardrails | No merge without green checks; you approve publishing |
| Schedule | When the loop wakes up | Configured watcher on an awake host |
What runs today
The private preview runs one canonical loop: report to verified release. Connect a project, map one capability, and the loop investigates, repairs within your permissions, and verifies each release independently. Start with the quickstart, or watch the loop run.
Custom loops are the direction
Your own loop definitions — your triggers, your checks, your limits — are being designed with early partners, not shipped. The repair loop is the implemented reference: every future loop inherits its contracts, especially the rule that whoever does the work never certifies it alone.
Builders run the repair loop on an app they maintain. Grow design partners scope campaign loops on the same contracts. See the growth loop.