Orchestration Planner

The agent that plans other agents.

The planning gap

  • Complex goals have non-obvious team composition
  • The conductor's attention is the scarce resource - don't spend it on decomposition
  • Antipattern: conductor self-assesses parallelization mid-task, gets sequencing wrong, reclassifies halfway through
  • Reclassification mid-execution is expensive: lost context, restarted agents, broken handoffs
The orchestration-planner exists so the conductor delegates composition reasoning, not just execution. Think before you spawn.

When to invoke

Invoke the orchestration-planner when any of these are true:

  • Complex goal - the task involves multiple distinct work units
  • Non-obvious team - it is not clear which agents are needed or in what order
  • Multiple phases - design, implement, review, verify each depend on prior output
  • Avoid mid-task reclassification - you want sequencing locked before spawning workers
Default step: after an architect or investigator returns a plan and the Skeptic signs off, run the orchestration-planner before spawning any workers. Skip only when the architect already returned a single atomic unit.

What it returns

Plan structure

  • Task summary - goal + why this team was chosen
  • Risk classification - Trivial / Low / Elevated / Elevated + Cleanup
  • Agent roster - agents and their specific role
  • Execution plan - phased: spawn, give, returns, proceed-when

Review + coordination

  • Skeptic checkpoints - what each reviews, what constitutes a pass
  • Parallelization opportunities - which phases run concurrently and why
  • Conductor actions - decisions, memory updates, context synthesis between phases
  • Open questions - ambiguities needing human input before execution

Orchestration-planner vs architect

Architect

  • Designs the code for one task
  • Reads the codebase, maps the change
  • Returns a technical plan: data model, API shape, file sequence
  • Scope: a single implementation unit

Orchestration-planner

  • Designs the execution flow for many agents
  • Reads the goal and the architect's plan
  • Returns an agent sequence: who, what order, what hand-offs
  • Scope: the full multi-agent campaign
Standard sequence: architect → skeptic-of-architect → orchestration-planner → worker phases

A worked example

Illustrative example - goal: "Add a /skill-audit slash command with tests and docs"

Plan output

  • Risk: Elevated (new files, multi-file)
  • Phase 1 (sequential): architect - design command structure
  • Phase 2 (sequential): skeptic - review architect plan
  • Phase 3 (parallel): engineer A - implementation; engineer B - docs
  • Phase 4 (sequential): integration skeptic - reviews combined diff

Key planner decisions

  • Docs and implementation are independent - safe to parallelize
  • One integration Skeptic covers both, not two stacked Skeptics
  • Skeptic checkpoint: no Critical/Major before marking complete
  • Open questions: none - architect plan fully specified inputs

Parallelization in practice

  • Independent workstreams with no shared state can run concurrently
  • Shared state or sequential dependencies (architect before engineer, debugger before fix) must stay sequential
  • Identify dependencies first - parallelization is the residual, not the default

Skeptic placement rules:

  • Independent elevated units - each gets its own Skeptic (can themselves run in parallel)
  • Interdependent elevated units - one integration Skeptic reviews the combined diff
  • Stacked per-unit Skeptics on interdependent changes produce false signal
One integration Skeptic, not stacked Skeptics. The planner identifies unit boundaries so the conductor applies the right rule.

Structured JSONL output - parallel fan-out fields

When a plan contains 2+ independent units, the planner emits a JSONL block. Each line is one unit:

{"unit_slug":"auth-middleware","merge_order":1,"skeptic_strategy":"per-unit","depends_on":[],"description":"Add JWT validation middleware","acceptance_criteria":["..."],"files_in_scope":["src/middleware/auth.ts"]}
{"unit_slug":"user-profile-api","merge_order":2,"skeptic_strategy":"per-unit","depends_on":[],"description":"Add /users/:id endpoint","acceptance_criteria":["..."],"files_in_scope":["src/routes/users.ts"]}

Key fields added for fan-out:

  • skeptic_strategy - the planner emits "per-unit" (independent units, parallel Skeptics) or "integration" (interdependent units, one combined Skeptic). The conductor may additionally apply a multi-dimensional review strategy on high-stakes units (correctness-Skeptic + security-auditor + perf-analyst in parallel on the same diff); that is conductor-side, not part of the planner's classification.
  • merge_order - integer; conductor merges unit branches in this order for conflict locality
  • unit_slug - the canonical unit identifier used in .agentic/tasks.jsonl task entries
N=1 still emits the one-line ## Task entries JSONL block (required by the spec). The conductor skips task-state initialization for single-unit plans - fan-out only activates for N≥2 independent units.

Delegate composition, not just execution.

The orchestration-planner does the structural reasoning so the conductor doesn't have to.

github.com/Space-Dinosaurs/DinoStack