StartConceptsWorkflowsReferenceTroubleshoot

Parent / Worker Orchestrator Mode

Silver Bullet's default execution model: the parent session composes and schedules work; Task workers implement atomic flows. The parent never edits project source at enforcement tier 2+.

What Is Orchestrator Mode?

When orchestrator_mode is parent (the only supported value in .silver-bullet.json), Silver Bullet treats the main session as a scheduler, not an implementer. The parent reads orchestrator-directive.json, spawns Task workers from .silver-bullet/orchestrator-workers/ templates, and advances the flow queue until it is empty.

This model is proven structurally — hook tests, directive guards, and parent-only tool allowlists enforce it on tier 2+ hosts (Cursor Multitask, Claude Code with hooks). It is not the same as full enterprise autonomy: live tri-host E2E certification is still in progress (see Autonomous Enterprise Status).

Contract authority: docs/ORCHESTRATOR.md in the SB repo defines the orchestrator contract. This help page summarizes customer-facing behavior — not runtime internals.

Parent vs Worker Roles

RoleMay implement?Typical tools (tier 2+)
ParentNo — schedules onlyTask, Read, Grep, Glob; Skill: silver / silver-orchestrator
WorkerYes — after assigned skillFull tool surface per atomic-flow contract; must invoke the assigned skill so hooks record state

Workers run with SB_ORCHESTRATOR_WORKER=1 so directive-guard semantics apply until next_skill is recorded. The parent clears worker markers on SubagentStop and writes the next directive via flow-advance.sh.

Directive Loop

  1. User intent arrives via /silver or a composer workflow skill.
  2. Composer spec seeds orchestrator.json and the enforcement queue.
  3. orchestrator-directive.json names next_skill + next_worker_template.
  4. Parent spawns a Task worker using the matching template under .silver-bullet/orchestrator-workers/.
  5. Worker invokes the skill, implements the atomic flow, and produces V-loop evidence.
  6. Queue advances; repeat until current_flow is empty.
{ "next_skill": "silver-quality-gates", "next_worker_template": "QUALITY-GATE", "blocking": true, "reason": "Planning floor before EXECUTE" }

Blocking Decisions (Human Gates)

Autonomous mode suppresses clarifying questions for non-blocking preferences. SB still escalates outcomes tagged decision_class: blocking — material forks, irreversible external actions, missing credentials, or destructive ambiguity.

  • Blocking — parent must ask the user; queue pauses until resolved or audited SB OVERRIDE: <reason> is logged.
  • Non-blocking — SB may choose a best-judgment default and log an Autonomous decision.
  • Production deploy / release — remain human-gated unless an explicit enterprise policy profile documents a narrower exception (today: still human-gated for production).

/silver:clarify --auto frames scope without interactive back-and-forth; it does not remove blocking gates. See Enterprise Policy Profiles for how teams declare posture in config.

Not overclaiming: Catalog metadata describes parallel DAG semantics; the current runtime queue is still sequential. Parallel scheduling is in progress — see status page for proof levels.

State and Audit Surfaces

ArtifactPurpose
orchestrator.jsonSession flow queue, current_flow, workflow id
orchestrator-directive.jsonMandatory next skill + worker template when blocking: true
.planning/orchestrator-composition-log.jsonlAutonomous composition audit (committed)
.planning/orchestrator-override-log.jsonlUser SB OVERRIDE: audit trail (committed)

Tier 0–1 Fallback

Hosts without Task/subagent support or without merged hooks (tier 0–1) invoke the same skill sequence directly in a single session. Parent-only directive blocks apply only when tier ≥ 2 and orchestrator_mode is parent. See Capability Matrix and docs/RUNTIME-COMPATIBILITY.md.

See Also

← Previous Composable Workflow Next → Enterprise Policy Profiles