Orchestrations

An orchestration is a goal-driven layer above individual workflows. It watches for a matching event or slash command, opens an instance for that work item (an issue or pull request, for example), and routes the item through approved workflows until the goal is met. Use an orchestration when one workflow run is not enough to finish the work. A production bug may need triage, root-cause analysis, a fix behind a PR, and a review. An orchestration keeps that one item moving through the right workflows while preserving a single timeline, a shared case file, and human approval points.

​

Why orchestrations exist

A workflow is one automation path: a trigger, steps, and an outcome. Real work often changes shape as it moves from intake to completion, and no single path covers it. Orchestrations coordinate that longer-lived path with a controlled loop:

1. An entry trigger matches an item and opens an instance.
2. The instance starts a configured first workflow, with no AI decision at entry.
3. The workflow runs and reports its result back to the instance.
4. The orchestration decides what happens next: route to another allowed workflow, wait for a human, or complete.
5. The loop repeats until the goal is reached, the instance is cancelled, or a limit is hit.

The goal you write is the contract. Overcut works the item toward it, pauses when a person must decide, and stops when the goal is met.

​

Orchestrations vs workflows

A workflow is still the unit that does work. The orchestration decides which approved workflow runs next. Workflows run exactly as you authored them; the orchestration never changes their steps.

​

What an orchestration contains

You configure everything in the Builder:

• Goal: what “done” means for one tracked item.
• Orchestration instructions: optional routing guidance between workflows.
• Allowed Workflows: the closed set of workflows instances may route between.
• Triggers: the events or slash commands that open an instance, each with a deterministic first workflow.
• Gates: human consent checkpoints before specific workflows or before completion.
• Limits: deterministic guardrails on steps, repeats, active instances, and idle time.

​

How decisions are made

Every step boundary opens a decision point with a proposal: route to a workflow, or complete the instance. Each proposal carries a confidence score and a rationale, both visible on the instance page.

• Proposals with high confidence auto-approve when no gate covers the target.
• Proposals behind a gate always wait for explicit human consent. The AI can never pass a gate on its own.
• Low-confidence proposals, dead ends, and limit violations also escalate to a person.

Humans respond by replying on the tracked item, or through a discussion session. See Approvals and Discussions. Limits are enforced by the platform, not the model. When an instance hits Max steps or Max repeats per workflow, the violation is recorded on the trail and the instance waits for a human instead of continuing.

​

Published versions and running instances

Orchestrations use published versions. Draft changes in the Builder do not affect anything until you select Publish. Each instance is pinned to the version that opened it and follows that definition for its whole life. Publishing a new version changes behavior only for new instances, so in-progress work stays stable while you iterate. The instance page shows the pinned Version, and the History tab lists every published version.

​

Billing

An orchestration instance bills as one workflow execution, regardless of how many routing decisions it takes. The workflow runs it starts bill as usual.

​

Related

• Workflows: the automation unit orchestrations route through.
• Triggers: workflow trigger types and event context.
• Workflow Execution Control: run queuing, priorities, and resource locking.