> ## 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. # Orchestration Builder > Configure an orchestration's goal, allowed workflows, entry triggers, gates, limits, and publishing from one canvas. The Builder is where you define everything about an orchestration. Open a project, go to **Build** > **Orchestrations**, and select an orchestration (or the pencil icon) to open its **Builder** tab. The Builder shows a canvas of nodes (goal, triggers, allowed workflows, gates) with a properties panel on the right. Selecting a node opens its settings in the panel; selecting nothing shows the orchestration-level settings. Edits save automatically to the draft as you type. Nothing affects live behavior until you publish. ## General settings With nothing selected, the panel shows: * **Orchestration name** (required). * **Color**: used for the orchestration's dot in lists and monitoring views. * **Default LLM Model**: the model used for routing decisions. ## Goal and instructions Select the **Goal & Instructions** node. * **Goal**: the outcome contract for one tracked item. Make "done" unambiguous, for example "Every production bug reported as an issue is investigated, root-caused, fixed behind a PR, and verified." The goal must be at least 20 characters. * **Orchestration instructions**: optional routing guidance, for example "Start with triage. If it is a bug, run RCA first; go straight to Implement & PR when the issue names the fix." Only the routing AI reads these. The workflows themselves run exactly as authored; the goal and instructions never change their steps. ## Allowed workflows Select the **Allowed Workflows** node and use the **Allowed Workflows** multi-select. This is the closed set of workflows instances may route between; the AI can only propose workflows from this list. If an allowed workflow is later deleted from the project, its badge is flagged on the canvas and publishing is blocked until you remove or replace it. ## Triggers Each entry trigger defines one way an instance opens. At least one trigger is required. * **Entry event**: the event that opens an instance, or **slash command**. The selector lists the event types currently supported as orchestration entries. * For event-based entries, a condition builder filters which events match, using the same conditions as workflow triggers. * For slash commands: * **Slash command**: the comment command that opens an instance (for example `investigate`), without the leading slash. Saved lowercase. * **Require @overcut mention before command**: when on, the comment must mention `@overcut` before the command. * **Starts with workflow**: the workflow that runs when this trigger matches. It must be one of the allowed workflows. Entry is deterministic; no AI decision happens at this point. If a slash command is also used by a workflow trigger in the same project, the orchestration entry takes precedence. Publishing warns about collisions but does not block them. ## Gates A gate is a human consent checkpoint. Add one with **Add Gate** on the canvas. * **Gate name** (required): a kebab-case slug, unique within the orchestration, for example `approve-pr`. * **Description**: what is being consented to. * **Gate point**: choose one. * **Before workflow**: the instance pauses for approval before starting any of the selected **Gated workflows**. * **Before completion**: the instance pauses for approval before it is marked complete. Only one completion gate is allowed. Gated proposals always wait for a person. High confidence never passes a gate, and the routing AI cannot approve through one. How approval works is covered in [Approvals and Discussions](/docs/orchestrations/approvals-and-discussions). ### Discussion agent Each gate can open a chat when a human reply reads as a question rather than a decision. * **Enable chat on this gate**: allows the pending decision to open a discussion session. * **Discussion workflow**: **Built-in workflow** answers from the decision context, the case file, and the tracked item. Choose **Custom workflow** when the discussion needs your own agent, tools, or repository setup. A custom discussion workflow can be any project workflow, but it must contain exactly one agent session step as its last step. * **Allow access to the previous agent session**: grants the discussion agent read-only access to the last workflow session. Enable it only when that context is appropriate for the people in the discussion. * **Max chat duration (minutes)**: how long a discussion session can stay open. Minimum 5, default 60. ## Limits Limits are deterministic guardrails, enforced by the platform rather than the AI. Blank fields use the defaults. | Limit | Default | Maximum | What it bounds | | ---------------------------- | ------- | ------- | ------------------------------------------------------------------------------------ | | **Max steps** | 20 | 100 | Workflow runs one instance may take | | **Max repeats per workflow** | 3 | 20 | How often one workflow may run within an instance | | **Max active instances** | 25 | 500 | Instances of this orchestration running at once; excess instances wait as **Queued** | | **Idle timeout (hours)** | 24 | 336 | How long an instance may sit idle before it is escalated to a person | When a route would exceed **Max steps** or **Max repeats per workflow**, the proposal is rejected, the violation is recorded on the instance trail, and the instance waits for a human. Nothing is dropped silently. ## Publish, discard, and activate The top bar shows actions when the draft differs from the published version: * **Publish** opens the **Publish Changes** dialog. Write a **Publish Message** (required; Overcut suggests one) and confirm. New instances start from the new version; running instances stay pinned to the version that opened them. If the draft has problems, Publish highlights the sections to fix instead of publishing. * **Compare** opens the draft against the last published version in **History**. * **Discard** resets the draft to the last published version. For a never-published orchestration, it deletes the draft entirely. The activation toggle turns the orchestration on or off and appears after the first publish. Inactive orchestrations ignore their entry triggers. **Delete** removes the orchestration. ## Version history The **History** tab lists every published version, newest first, with the draft tagged **unpublished** and the current version tagged **latest**. Select a version to view its definition, use **Compare with** to diff against the draft, the latest, or the previous version, and use **Restore** to copy an old version into the current draft. Restoring overwrites uncommitted draft changes. ## Related * [Your First Orchestration](/docs/orchestrations/first-orchestration): end-to-end setup walkthrough. * [Approvals and Discussions](/docs/orchestrations/approvals-and-discussions): how gated decisions get resolved. * [Monitoring Instances](/docs/orchestrations/monitoring): follow instances after they open.