Skip to main content
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.

​
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. 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.