dynamic-workflow-patterns

Dynamic Workflow Patterns

The Workflow tool description already teaches the script API, the opt-in rules, and the execution mechanics; every mention of those below is a one-line anchor, never a re-teach.

This skill adds what that description lacks: which pattern to pick, which agent roles to combine for each task family, which model to give each role, how large to cut each agent's unit of work, how to behave between launch and completion, and how to keep a workflow alive through server errors, stalls, and interruptions.

Why Single Contexts Fail

Pattern choice and prompt design follow from knowing which failure mode the workflow defends against, so diagnose the threat before picking the shape.

Agentic laziness. The model declares done after partial progress, for example addressing 35 of 50 items in a review. Counter: the deterministic script, not the model, decides when work is done -- explicit item lists, loop-until-done stop conditions, and a logged record of every dropped item.

Self-preferential bias. The model favors its own output when asked to verify or judge it. Counter: assign verification to agents that did not produce the work -- verifiers, refuters, skeptics, and judges who never grade their own attempt.

Goal drift. Fidelity to the objective decays across many turns and lossy compactions, dropping edge-case requirements and don't-do-X constraints. Counter: each subagent lives in a short fresh context with the objective restated verbatim in its prompt, the script pins the original goal in args so no compaction ever touches it, and the deterministic script body holds the authoritative item list, bracket, or rule set, which survives compaction because it lives in the persisted script text and is re-read in full on every relaunch, whether or not a single call replays from cache.

When Not to Use a Workflow

Workflows multiply token cost by the number of agents, and the user's standing decision settles where that cost is paid: substantive work that spans several units, needs independent verification, or exceeds one context runs as a workflow -- its parallel() and pipeline() fan-outs, its worktree-isolated agents, its refuters and settlers inside the run -- whether or not the session declares ultracode, and that standing decision is the opt-in a workflow launch needs. A standalone Agent call is for a small one-off unit where a workflow's setup would cost more than the unit, never the vehicle for the substantive work. The cost question therefore moves inside the run: size each phase as the next paragraph describes. A routine single-unit change that shows none of the three failure modes stays in the default harness, which is cheaper, faster, and just as correct for it, and a routine change never needs a panel of five reviewers.