> ## Documentation Index > Fetch the complete documentation index at: https://docs.overcut.ai/llms.txt > Use this file to discover all available pages before exploring further. # Orchestrations > Coordinate a work item across a closed set of approved workflows until it reaches a defined goal. 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. Create, publish, and run an orchestration end to end. Configure the goal, allowed workflows, triggers, gates, and limits. Approve, reject, or discuss pending decisions as a human in the loop. Follow live activity, inspect the decision trail, and review history. ## 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 | Model | What it defines | What it produces | Best for | | ----------------- | ------------------------------------------------------------ | ----------------------------- | ----------------------------------------------------------------------------- | | **Workflow** | A trigger, steps, and the order they run in | One workflow run | A repeatable automation path, such as reviewing a PR or triaging a ticket | | **Orchestration** | A goal, allowed workflows, entry triggers, gates, and limits | One instance per tracked item | Coordinating a work item across multiple workflows until the goal is complete | 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. An orchestration cannot reach every workflow in the project. Instances route only to workflows listed in **Allowed Workflows**, a closed set you select in the Builder. ## What an orchestration contains You configure everything in the [Builder](/docs/orchestrations/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](/docs/orchestrations/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. Orchestrations availability depends on your plan. If **Orchestrations** does not appear under **Build** in the project sidebar, contact your account team. ## Related * [Workflows](/docs/workflows/workflows): the automation unit orchestrations route through. * [Triggers](/docs/workflows/triggers): workflow trigger types and event context. * [Workflow Execution Control](/docs/workflows/workflow-execution-control): run queuing, priorities, and resource locking.