Orkestra
GitHub

Every stage in a Trak’s pipeline — what agent runs, what gates check the output, what capabilities it has, and what happens on failure — is configured in .orkestra/workflow.yaml.

File structure

A workflow.yaml file contains one or more named flows. A Trak is assigned to a flow at creation time and runs the flow’s stages in order.

version: 2

flows:
  default:
    stages:
      - name: work
        artifact: summary
        prompt: worker.md
    integration:
      on_failure: work

Root fields

FieldTypeRequiredDescription
versionintegerNoSchema version. Current value: 2. Defaults to 2 if omitted.
flowsmapYesNamed flows. At least one flow is required.

Flow fields

Each entry under flows is a named flow:

FieldTypeRequiredDescription
stageslistYesOrdered list of stage configs. At least one stage is required.
integrationobjectYesMerge behavior configuration.

Integration fields

FieldTypeRequiredDefaultDescription
on_failurestringYesName of the stage to return to when a merge fails. Must match an existing stage name in this flow.
auto_mergebooleanNofalseIf true, merges the Trak’s branch automatically when the final stage completes.

Stage fields

Each item in stages configures one stage in the flow:

FieldTypeRequiredDefaultDescription
namestringYesUnique identifier within the flow. Shown in CLI output and logs.
artifactstringYesName under which the stage’s output is stored and injected into later stages as context. Must be unique within the flow. Reserved values: activity_log, task.
descriptionstringNoHuman-readable description. Shown in UI and logs.
promptstringNo{name}.mdPath to the prompt template, relative to .orkestra/agents/. Defaults to {name}.md.
modelstringNoDefaultAI model to use. See Model values.
is_automatedbooleanNofalseIf true, the stage auto-advances after producing valid output — no human approval step. Gates still run.
capabilitiesobjectNoOptional extensions to stage behavior. See Capabilities.
gateobjectNoShell script that runs after the agent produces output. See Gate fields.
disallowed_toolslistNo[]Tools the agent cannot use. See Tool restrictions.
schema_filestringNoAdvanced / unverified — confirm stability before use. Path to a custom JSON schema for the stage output, relative to .orkestra/schemas/. If omitted, Orkestra generates a schema from the stage’s capabilities.

name and artifact must be unique within a flow. The names activity_log and task are reserved and cannot be used as artifact values.

Model values

The model field selects both the AI provider and the model. The provider is inferred from the model name.

ValueProviderModel
(omitted)Claude CodeDefault model
sonnetClaude CodeClaude Sonnet 4
opusClaude CodeClaude Opus 4
haikuClaude CodeClaude Haiku 4.5
claudecode/sonnetClaude CodeClaude Sonnet 4
claudecode/opusClaude CodeClaude Opus 4
claudecode/haikuClaude CodeClaude Haiku 4.5
Full model ID (e.g., claude-sonnet-4-6)Claude CodeSpecific version
kimi-k2OpenCodeKimi K2
opencode/kimi-k2OpenCodeKimi K2

Capabilities

The capabilities object extends what a stage can do:

FieldTypeDefaultDescription
ask_questionsbooleanfalseAllows the agent to ask clarifying questions before producing its artifact. The Trak pauses until the questions are answered.
subtasksobjectAllows the agent to decompose the Trak into child Traks (Subtraks). See Subtasks.
approvalobjectMakes this an Agentic Gate: the agent produces an approve or reject verdict instead of a plain artifact. See Approval.

subtasks and approval cannot coexist on the same stage. ask_questions and approval can coexist. ask_questions and subtasks can coexist.

Subtasks capability

FieldTypeRequiredDefaultDescription
flowstringNodefaultThe flow assigned to child Traks. Must be a named flow in workflow.yaml.
completion_stagestringNoNext stageThe stage the parent Trak resumes at after all Subtraks complete. Defaults to the stage immediately following this stage in the flow’s stages list. Must be a valid stage name in the parent flow.

Approval capability

FieldTypeRequiredDefaultDescription
rejection_stagestringNoPrevious stageThe stage the Trak routes to on a reject verdict. Defaults to the stage immediately preceding this stage in the flow’s stages list. Must be a valid stage name in the flow.
reset_sessionbooleanNofalseIf true, the target stage starts a fresh agent session. If false, the existing session resumes with the rejection as feedback.

Gate fields

FieldTypeRequiredDefaultDescription
commandstringYesShell command to execute in the Trak’s worktree. Exit 0 passes; non-zero fails and sends the output to the agent as feedback.
timeout_secondsintegerNo300Seconds before the gate is treated as failed. Must be greater than 0.

See Gates for gate behavior and environment variables.

Tool restrictions

Each item in disallowed_tools restricts the agent from using a specific tool:

FieldTypeRequiredDescription
patternstringYesTool name or pattern in Claude Code format (e.g., Bash(cargo *), Edit). Cannot be empty.
messagestringNoExplanation injected into the agent’s prompt describing why this tool is restricted. Helps the agent work around the restriction.

Available tool patterns include: Bash, Bash(<pattern>), Edit, Write, Read, Glob, Grep. Any Claude Code tool name is a valid pattern.

Validation

Orkestra validates workflow.yaml at startup and reports errors immediately:

  • Stage name must be unique within a flow.
  • Stage artifact must be unique within a flow. activity_log and task are reserved.
  • integration.on_failure must name an existing stage in the flow.
  • approval.rejection_stage must name an existing stage in the flow (if specified).
  • subtasks.completion_stage must name an existing stage in the parent flow (if specified).
  • subtasks.flow must name an existing flow (if specified).
  • gate.timeout_seconds must be greater than 0.
  • disallowed_tools[].pattern cannot be empty.

Full example

The default workflow.yaml created by Orkestra on first run:

version: 2

flows:
  # Default pipeline — used for most Traks
  default:
    stages:
      # Planning: agent asks questions, then produces a plan
      - name: planning
        artifact: plan
        description: Clarifies requirements and produces an implementation plan
        prompt: planner.md
        capabilities:
          ask_questions: true   # Agent can ask clarifying questions before outputting

      # Breakdown: agent researches the codebase and proposes Subtraks
      - name: breakdown
        artifact: breakdown
        description: Breaks the plan into parallel implementation Subtraks
        prompt: breakdown.md
        capabilities:
          subtasks:
            flow: subtask       # Subtraks use the subtask flow below

      # Work: agent implements the changes; gate verifies quality
      - name: work
        artifact: summary
        description: Implements code changes and produces a summary
        prompt: worker.md
        gate:
          command: "$ORKESTRA_PROJECT_ROOT/.orkestra/scripts/checks.sh"
          timeout_seconds: 600  # 10 minutes; adjust for your project's test suite

      # Review: agentic gate — agent approves or rejects the work
      - name: review
        artifact: verdict
        description: Reviews completed work and produces an approve/reject verdict
        prompt: reviewer.md
        capabilities:
          approval:
            rejection_stage: work  # On reject, route back to the work stage

      # Compound: captures learnings; automated — no human review step
      - name: compound
        artifact: learnings
        description: Captures learnings to improve future Traks
        prompt: compound.md
        is_automated: true

    integration:
      on_failure: work  # If merge fails, route back to the work stage

  # Subtask pipeline — simpler flow for child Traks
  subtask:
    stages:
      - name: work
        artifact: summary
        prompt: worker.md
        gate:
          command: "$ORKESTRA_PROJECT_ROOT/.orkestra/scripts/checks.sh"
          timeout_seconds: 600

      - name: review
        artifact: verdict
        prompt: reviewer.md
        capabilities:
          approval:
            rejection_stage: work

    integration:
      on_failure: work