Skip to main content
delegation-chain is an archived example, not installed by init. Copy examples/init-pack/delegation-chain.tsx and its dependency closure into your project, or ask create-workflow to build an equivalent. Once installed, it runs the whole arc from an ambiguous ask to gated, scored delivery: strong models refine and decompose the goal into tiered chunks, cheap models render previews and probes, and every node gates its own execution (reviews, checks, previews, optional approvals). Outputs stay editable throughout, and the run ends with scorers plus a short poll (see How It Runs, Live control, and Scoring below).
Watch and steer it in the custom workflow UI, home to the delegation tree, question forms, editable outputs, and cost bar:

​
Inputs

Only prompt is required; everything else defaults to automatic operation. Example with a policy and a budget:

​
Tiers

Work flows down a ladder of intelligence tiers: labels (fable, opus, sonnet, haiku by default), not model ids. The copied workflow maps each label to an agent (or failover chain) from .smithers/agents.ts, so you can swap any tier without touching the workflow body. By default the strongest tier plans the root and reviews, the second plans chunks, the third executes leaves, and the cheapest renders previews and research probes at near-zero cost.

​
How It Runs

  1. Goal refinement. The strongest tier forecasts every user-preference question upfront and answers implementation questions itself; the cheapest tier pre-renders the question forms (10 by default) so you never wait on rendering, answering one durable form at a time in the UI. The goal agent writes the refined prompt; your approval (edited first if you like) becomes the root planning brief.
  2. Tiered decomposition. The root plan streams in children; each child declared a chunk fans out into its own plan task at its own tier, level by level, until the frontier is all leaves or maxDepth forces it. Every plan carries per-child { tokens, costUsd, minutes } estimates, a subtree rollup, and a risk list with a probe verdict each (poc, research, or null for “judged routine”, scored later).
  3. Zero-backpressure previews. Once planning completes, the cheapest tier renders every leaf’s expected output: calibration only, tagged “never executed”, so you catch misunderstood briefs before spending execution cost. The UI’s skip button sends a durable dc-skip-preview signal that suppresses the phase.
  4. Backpressure planning. Every node declares its gates and dependencies before execution: review gates at a declared tier, check gates as shell commands, preview gates (developer previews, below), and approval gates, permitted only with a passed approvalPolicy (none means no approval gates). With a policy, delegating agents add gates only where it applies, optionally clarifying it for children. The root node must declare a slideshow developer preview, so every run ends with something showable.
  5. Derisk loop. Every flagged risk spawns a probe: research probes read docs and report with sources, poc probes prove the risky thing works. Findings go to the nearest parent only; no node sees the whole tree. A finding that changes the plan triggers a replan round: the flagged node’s owner plus every dependent (child and dependency edges both) decide invalidated (version bump, fresh plan, old version archived) or reaffirmed (“my plan survives the change”). Rounds stop at maxDeriskRounds per node.
  6. Execution. Leaves run in dependency order at maxConcurrency parallelism: a leaf’s pipeline mounts only once every leaf under its dependencies completes. Each leaf loops exec plus gates up to maxAttempts times, folding failed-gate feedback into the next attempt’s brief. Reviews judge evidence, not summaries: each gets the node’s structured output plus the measured range of jj (or git) commits produced, with instructions to inspect them (jj log, jj diff, jj show). Chunk-level reviews get the union of their subtree’s ranges.
  7. Scoring and poll. A run-level digest task carries the five delegation scorers, and (unless poll: false) a final 3-question satisfaction poll renders in the UI as the run’s last attention badge.

​
Live control while it runs

The whole run is steerable from the delegation-chain workflow UI:
  • Editable outputs. Every rendered output is editable in place. Saving an edit sends a durable dc-edit signal riding the same replan cascade as a probe finding: the affected owner replans or reaffirms, and dependents cascade. Edits are ordinary events, not restarts.
  • Version history. Invalidation bumps a node’s version and archives the old one. Clicking a node shows its version list: every prior version stays inspectable, with the replan decision that killed it.
  • Attention routing. Nodes carry a pending-human rollup (self plus descendants); clicking a pulsing badge jumps to the nearest descendant that needs you: a question, the refined-prompt approval, an approval gate, or the poll.
  • Cost bar. The header shows actual spend against the latest predicted total; replans re-forecast, so the prediction is always the newest rollup, not the first guess.
  • Developer previews. Nodes with a preview gate build a showable artifact after execution: app (the built thing itself), terminal (rendered terminal plus driving instructions), api (an explorer over a built API), throwaway-ui (a disposable UI over the work), or slideshow (an HTML slideshow, the fallback with no runnable code). The build is backpressure: a failed build fails the node like a failed review. Its Invalidate and Request-changes buttons submit the same dc-edit round as any other edit.

​
Budgets

Pass budgetUsd and/or budgetMinutes to enforce the forecast: rolled-up actuals are checked after each leaf’s execution, crossing 80% of a limit writes a warning row and crossing it raises an error into the run. budgetMinutes also acts as a wall-clock latency SLO on the whole chain.

​
Scoring

Five scorers grade the run (see the scorer reference): The run total combines them via delegationRunScore, weighted 0.25 / 0.25 / 0.15 / 0.15 / 0.2 by default; skipped components drop out and the rest renormalize. All weights, plus the per-classification values and penalties inside pocJudgment and planSolidity, are configurable via the scorer factory options.

​
Roadmap

One follow-up is deliberately deferred: higher-order orchestration (a planning node authoring its own smithers workflow as its execution strategy), reserved via the optional dcPlan.orchestration: "tasks" | "workflow" field, accepted but ignored today. The UI-side fold store behind useDelegationChain already runs on Effect.ts, behind the frozen hook signature.

​
Use it when

  • The ask is ambiguous or large enough to deserve refinement, decomposition, and risk probes before anyone writes code.
  • You want per-node backpressure with evidence (commit-range reviews, checks, showable previews) instead of one final review.
  • You want to steer mid-flight by editing outputs rather than restarting.

​
Use something else when

  • The change is a single focused unit: use implement.
  • You want milestone-by-milestone delivery with one approval gate: use mission.
  • You only need the gate matrix, not the delegation: use backpressure-plan.
The workflow is a thin wrapper around the <DelegationChain> composite; use that page to embed the same machinery in your own workflows.