Orchestrate Tasks
Fan large tasks across parallel agents with planner/worker/verifier roles. Adapted from Cursor's orchestrate plugin for CK governance.
Do NOT use when
- Single-agent task (just use
controlkeel-governance) - Task has no parallelizable slices
- Budget is tight (orchestration is expensive — multiple delegations)
Principles
- Planners own scope, not code — decompose, publish tasks, read handoffs, decide next. No file edits.
- Workers are isolated — one task, one agent, one scope. Talk up through handoffs only.
- Verifiers check independently — read worker output, verify against acceptance criteria.
- State on disk —
ck_memory_recordand git, no long-running agent state. - Continuous convergence — each cycle produces progress. No progress → escalate.
Workflow
- Check
ck_budget— orchestration costs multiple delegations. Stop if insufficient. - Decompose into tasks (or use existing
plan-sliceoutput). Each task: name, type (worker/verifier/subplanner), scoped goal, acceptance criteria, dependencies, paths. - Record plan via
ck_memory_record(type:decision, tags:orchestration-plan). - Submit plan via
ck_review_submit(review_type:plan). Wait for approval before spawning. - Execute loop:
- Select ready tasks (dependencies satisfied, not started)
- Check budget before each delegation
- Delegate:
ck_route→ck_delegate - Collect handoffs
- Verify completed tasks
ck_rollbackcheckpoint after each success- Decide: new tasks, retry failures, or completion
- Synthesize:
ck_git_difffor total change,parallel-reviewif large.
Failure recovery
- Worker failure → record
ck_finding, retry once, escalate if retry fails - Budget exhaustion → checkpoint state, stop, record for resumption
- Verifier failure → worker output not trusted, fix or escalate
Output
- Approved orchestration plan
- Delegated tasks with handoffs
ck_findingfor failuresck_rollbackcheckpoints- Synthesized result
Reference
- Handoff format