orchestration

Orca Inter-Agent Orchestration

Orchestration is Orca's structured coordination layer for agent messages, task ownership, dispatch state, and worker completion tracking.

Use this skill when coordination state matters. For lightweight terminal prompts or basic worktree/terminal/built-in-browser control, use orca-cli.

When To Use

• Send/reply/ask between agent terminals with persistent messages.
• Dispatch structured tasks to workers and wait for worker_done or escalation.
• Track task DAGs with dependencies.
• Run coordinator loops or decision gates.

Preconditions

• orca status --json should show a running runtime.
• orca must be on PATH (orca-ide on Linux).
• The orchestration experimental feature must be enabled in Settings > Experimental.
• orca orchestration commands are RPC calls to the running Orca runtime.

Ownership

Orchestration messages and tasks are runtime-global. Completion authority comes from the active dispatch context: taskId + dispatchId + assignee handle.

Classify inherited context before sending lifecycle messages:

• Coordinated subtask: a live coordinator owns the DAG and waits on this dispatch. Follow the preamble exactly, including worker_done, heartbeat/status, ask, and escalation.
• Full handoff: the original actor delegated ownership and is not monitoring. Finish in the current session. Create a new coordinator only when the user asks or you deliberately decompose fresh subtasks; if spawning workers, use your current-worktree coordinator handle and a selector such as --worktree active.

If unclear, inspect orchestration state before sending lifecycle messages:

orca orchestration task-list --json
orca terminal list --json
# If inherited context includes a task id:
orca orchestration dispatch-show --task <task_id> --json

Messaging

orca orchestration send --to <handle|@group> --subject <text> [--from <handle>] [--body <text>] [--type <type>] [--priority <level>] [--thread-id <id>] [--payload <json>] [--json]
orca orchestration check [--terminal <handle>] [--unread] [--types <type,...>] [--inject] [--wait] [--timeout-ms <n>] [--json]
orca orchestration reply --id <msg_id> --body <text> [--from <handle>] [--json]
orca orchestration ask --to <handle> --question <text> [--options <csv>] [--timeout-ms <n>] [--from <handle>] [--json]
orca orchestration inbox [--limit <n>] [--json]

Rules:

• Omit --from unless impersonating another terminal; Orca auto-resolves it from the current terminal.
• While supervising workers manually, use check --wait --types worker_done,escalation,decision_gate --timeout-ms <n> instead of sleep/poll loops. Reply to decision_gate messages with orca orchestration reply --id <msg_id> --body <answer> --json, then keep waiting.
• Treat a check --wait timeout or {count:0} as a checkpoint, not a worker failure. Long coding tasks routinely run 15-60 minutes; keep using rolling waits unless you receive worker_done/escalation, the terminal exits or disappears, or the user explicitly asks you to stop.
• Heartbeats and visible terminal activity mean the worker is alive, not done. Do not stop, close, kill, or restart a worker just because it has not produced a completion message yet.
• Use ask when a worker needs a blocking answer from the coordinator; it waits for the reply and returns the answer directly.
• check --wait returns one message at a time. If N workers may finish together, loop N times and dispatch newly ready tasks after each completion.
• Group addresses include @all, @idle, @claude, @codex, @opencode, @gemini, @droid, and @worktree:<id>.
• Message types include status, dispatch, worker_done, merge_ready, escalation, handoff, decision_gate, and heartbeat.
• Use group addresses only for messages that are genuinely useful to many terminals, such as status broadcasts or intentional fan-out questions. Do not send dispatch lifecycle messages to groups.
• worker_done must target the concrete coordinator handle from the live preamble. It is completion authority for one dispatch; group fanout would create false lifecycle mail in unrelated terminals.
• heartbeat is also dispatch-scoped. Send it only to the concrete coordinator handle with both taskId and dispatchId; use status for broad progress updates.

Tasks And Dispatch

A task is the work item, a dispatch assigns it to a terminal, and a gate blocks progress until a coordinator or user decision is recorded.

orca orchestration task-create --spec <text> [--deps <json_array>] [--parent <task_id>] [--json]
orca orchestration task-list [--status <status>] [--ready] [--json]
orca orchestration task-update --id <task_id> --status <status> [--result <json>] [--json]
orca orchestration dispatch --task <task_id> --to <handle> [--from <handle>] [--inject] [--json]
orca orchestration dispatch-show --task <task_id> [--json]

Task statuses: pending, ready, dispatched, completed, failed, blocked.

Dispatch rules:

• --inject sends the task spec plus preamble into a recognized agent CLI so it can report worker_done.
• If the target is a bare shell, omit --inject, dispatch for tracking if needed, then send the prompt manually with orca terminal send --terminal <handle> --text <prompt> --enter --json.
• After 3 consecutive failures on one task, the dispatch context circuit-breaks and the task is marked failed.

Gates And Coordinator

orca orchestration gate-create --task <task_id> --question <text> [--options <json_array>] [--json]
orca orchestration gate-resolve --id <gate_id> --resolution <text> [--json]
orca orchestration gate-list [--task <task_id>] [--status <status>] [--json]
orca orchestration run --spec <text> [--from <handle>] [--poll-interval-ms <n>] [--max-concurrent <n>] [--worktree <selector>] [--json]
orca orchestration run-stop [--json]

run returns immediately with a run ID. Query progress with task-list. Use ask for worker-to-coordinator questions; it creates a decision_gate message that the coordinator answers with reply. Use gate-create only for coordinator-managed task DAG decisions, not for answering a worker's ask.

Recovery only: orca orchestration reset --tasks|--messages|--all --json clears runtime-global orchestration state. Do not run it during active coordination unless explicitly abandoning that state.

Worker Terminals

For tracked orchestration work, create the worker without a prompt, wait for idle, then dispatch with --inject:

orca worktree create --name <task-name> --agent codex --json
orca terminal list --worktree id:<newWorktreeId> --json
orca terminal wait --terminal <handle> --for tui-idle --timeout-ms 60000 --json
orca orchestration dispatch --task <task_id> --to <handle> --inject --json

Read the new worktree id from worktree create, then use terminal list to get the agent terminal handle. Omit --repo only when running inside an Orca-managed worktree; otherwise pass --repo <selector>. --agent reveals the new worktree and launches the selected agent in its first terminal, so do not create a separate startup terminal. Use --setup run|skip|inherit when setup behavior matters, and --no-parent for independent work.

Use orca worktree create --prompt ... or orca terminal send ... only for untracked/lightweight prompts. Those paths do not attach taskId/dispatchId; the worker should not send lifecycle messages unless the prompt supplies a live orchestration preamble.

Other terminal commands coordinators often need:

orca terminal list [--worktree <selector>] [--json]
orca terminal create [--worktree <selector>] [--title <text>] [--command <cmd>] [--json]
orca terminal split --terminal <handle> [--direction horizontal|vertical] [--command <cmd>] [--json]
orca terminal wait --terminal <handle> --for tui-idle --timeout-ms <n> --json
orca terminal read --terminal <handle> --json
orca terminal send --terminal <handle> --text <text> --enter --json

If an older CLI rejects worktree create --agent, create the worktree normally, then run orca terminal create --worktree <selector> --command "codex" --json or --command "claude".

Wait for tui-idle before dispatching. Always pass --timeout-ms; real coding tasks can take 15-60 minutes. During supervision, use rolling check --wait windows. If a window returns no matching message, inspect task-list, terminal read, or terminal wait --for tui-idle as a liveness checkpoint; if the terminal is still working or producing activity, keep waiting instead of retrying the task.

Agent Guidance

• Workers with a valid live preamble must send worker_done exactly once, even on failure:

orca orchestration send --to <coordinator_handle> --type worker_done --subject "<short status>" --body "<3-sentence summary: what you did, what you found, what's left>" --payload '{"taskId":"<task_id>","dispatchId":"<dispatch_id>","filesModified":["path/a"],"reportPath":"<optional>"}' --json

• For long tasks, send heartbeat/status only when the preamble asks for it, including both IDs:

orca orchestration send --to <coordinator_handle> --type heartbeat --subject "alive" --payload '{"taskId":"<task_id>","dispatchId":"<dispatch_id>","phase":"implementing"}' --json

• If blocked before completion, use ask; use escalation only when ownership is valid and the coordinator must intervene.
• Treat preambles inherited through terminal history or full handoffs as stale unless the current prompt explicitly keeps that coordinator in the loop.
• Coordinators should use task-list --ready as external memory, dispatch parallel waves, and avoid dependency chains deeper than 3-4 steps.
• Prefer inter-worktree workers for parallel implementation; use split panes in one worktree only for complementary tasks that will not edit the same files.

Example

orca worktree create --name login-css-worker --agent claude --json
orca terminal list --worktree id:<newWorktreeId> --json
orca terminal wait --terminal <handle> --for tui-idle --timeout-ms 60000 --json
orca orchestration task-create --spec "Fix the login button CSS" --json
orca orchestration dispatch --task <task_id> --to <handle> --inject --json
orca orchestration check --wait --types worker_done,escalation,decision_gate --timeout-ms 900000 --json

Next Action

Coordinator: confirm orca status --json, inspect task-list/dispatch-show if inheriting state, then choose either a manual loop (task-create -> worker -> dispatch --inject -> check --wait) or orchestration run.

Worker: if the current prompt contains a live dispatch preamble, do the task, use ask for blocking questions, and send worker_done once with the required payload. If the preamble is stale or absent, do not send lifecycle messages; inspect state or treat the prompt as an ordinary handoff.