Orchestration
Coordinate multiple agent terminals in Orca with threaded messages, task dispatch, DAGs, and coordinator loops instead of ad-hoc chat handoffs.
Overview
Orca orchestration is an agent skill most often used in Build (also Ship, Operate) that runs structured multi-agent coordination—messages, task DAGs, dispatch, and coordinator loops—inside a running Orca runtime.
Install
npx skills add https://github.com/stablyai/orca --skill orchestrationWhat is this skill?
- Persistent ask/reply messaging between agent terminals with blocking flows
- Structured task dispatch with worker_done and escalation waits
- Task DAGs with dependencies plus coordinator loops and decision gates
- RPC via `orca orchestration` against a running Orca runtime (experimental feature required)
- Pair with `orca-cli` for shells/worktrees; use Computer Use only for UI outside Orca's embedded browser
Adoption & trust: 1.8k installs on skills.sh; 4.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need several agents to own tasks, reply on threads, and finish in order, but ad-hoc terminal chat loses state and dependencies.
Who is it for?
Teams already on Orca with experimental orchestration enabled who run multi-agent builds and need DAGs, gates, and message threads.
Skip if: Ordinary shell control, worktree tweaks, or embedded-browser automation—use `orca-cli`; external desktop/browser UI—use Computer Use.
When should I use this skill?
Use Orca orchestration for structured multi-agent coordination: threaded messages, blocking ask/reply, task dispatch, worker_done/escalation waits, task DAGs, decision gates, coordinator loops, or decomposing work across
What do I get? / Deliverables
Workers receive dispatched tasks, dependencies are tracked in a DAG, and coordinators wait on worker_done or escalation with durable orchestration state.
- Coordinated multi-agent task graph with tracked dispatch and completion
- Persistent inter-agent message threads with ask/reply outcomes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Orchestration is the structured multi-agent layer for building and running agent workflows inside Orca, so the canonical shelf is Build → agent-tooling. It governs inter-agent messages, worker_done waits, and task ownership—core agent-runtime tooling rather than generic backend or frontend work.
Where it fits
Decompose a feature across planner and implementer terminals with a task DAG and blocking ask/reply.
Run a decision gate that escalates to a reviewer agent before merge-related work continues.
Keep a coordinator loop waiting on worker_done while background agents clear a backlog.
How it compares
Use for persisted multi-agent coordination state, not as a replacement for `orca-cli` terminal control or generic MCP tool routing.
Common Questions / FAQ
Who is orchestration for?
Solo and indie builders using Orca who split work across agent terminals and need structured dispatch, dependencies, and completion tracking.
When should I use orchestration?
During Build when coordinating agent workers; in Ship when gated review or escalation paths matter; in Operate when long-running coordinator loops monitor task completion—always with Orca running and experimental orchestration on.
Is orchestration safe to install?
Treat it as runtime RPC to your local Orca instance; review the Security Audits panel on this Prism page before enabling experimental features in production workflows.
SKILL.md
READMESKILL.md - 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: ```bash 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 ```bash 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 direc