memorysaver Dynamic Workflow Pattern
A reusable pattern for building a custom harness for a single task. Instead of
running the task in the one default coding harness, Claude writes a small
deterministic JavaScript program — a Claude Code Workflow — that spawns and
coordinates subagents, each with its own clean context window, tuned to the task.
Invoke it directly to decide whether a task warrants a workflow and to author one;
it also serves as the sub-pattern library that /aep-gen-eval and /aep-executor
read.
"Claude can now write its own harness on the fly, custom-built for the task at hand." — Thariq Shihipar & Sid Bidasaria, Anthropic, "A harness for every task: dynamic workflows in Claude Code"
Not
/aep-workflow-feedback. That skill captures lessons about the AEP process; this one authors an orchestration script for a task.
When to reach for a workflow
The core judgment: a workflow trades significantly more tokens for isolated
context windows + focused goals + a deterministic orchestrator instead of one long,
drifting transcript. That trade is worth it — and only worth it — when a single
context would go lazy, biased, or off-goal (the three failure modes it counters are
tabulated in references/pattern-catalog.md). On the
current generation a single context sustains a long story; duration alone is not a reason
to split — adversarial verification and fan-out are.
Reach for a workflow when the task:
- spans many independent items — sort 1000+ rows, audit every claim, refactor every callsite — where quality degrades if crammed into one prompt;
- needs adversarial verification by something other than its author (security review, fact-check, eval);
- is taste-based and benefits from competing attempts (naming, design direction);
- needs routing of different inputs to different handling or model tiers.
Otherwise stay single-context: an ordinary coding task that fits one window, or
a verification need a single /aep-gen-eval loop already covers, does not need a
panel of agents. A workflow is a deliberate choice for one task, not a default
wrapper around routine work.
Sub-patterns and their AEP touchpoints
Pick the shape that matches the task (they compose — a thorough review is
fan-out → adversarial verify → loop-until-dry). Full intent, the primitive to use
(parallel barrier vs pipeline no-barrier vs loop), skeletons, and architectural
levers are in references/pattern-catalog.md.
| Sub-pattern | What it does | AEP touchpoint |
|---|---|---|
| Classify-and-route | A classifier agent decides task type / model tier, then routes. | /aep-dispatch routes by readiness_score and offers the "…with workflow" opt-in; a full classifier / model-tier router is the workflow generalization. |
| Fan-out-and-synthesize | Split into many small steps → one agent each → a barrier merges. | /aep-executor workflow mode runs one dispatched build wave this way (the narrow use); this skill is the general catalog + judgment. |
| Adversarial verification | For each output, a separate agent refutes it against a rubric. | /aep-gen-eval (generator/evaluator) is the canonical N=1 instance; a workflow generalizes it to N verifiers per finding. /aep-validate runs a fixed trio today — a workflow gives one per claim. |
| Generate-and-filter | Generate many candidates → dedupe → keep only rubric-passing ones. | Naming / design option generation before a calibration gate. |
| Tournament | N approaches compete; pairwise judging until a winner. | Taste-based decisions (naming, design direction) feeding a /aep-calibrate gate. |
| Loop-until-done | Keep spawning until a stop condition, not a fixed count. | /aep-autopilot's tick loop is the long-lived, OS-driven cousin. |
How to invoke
- Just ask. "Set up a workflow to…" / "Use a workflow to verify every claim…".
ultracodekeyword. Includingultracodeforces Claude Code to author a workflow for the request.- Within AEP. "…with workflow" routes a dispatched build wave through
/aep-executor'sworkflowbackend mode (one agent per locked story, hub-and-spoke gating) — see/aep-executorreferences (backends.md) → Mode: workflow.
Pair with other tools: /loop runs a repeatable workflow on an interval;
/goal sets a hard completion requirement so it can't quit early (counters
laziness); prompt with a token budget ("use 10k tokens") to cap spend; press s in
the workflow menu to save to ~/.claude/workflows — treat a saved workflow as a
template, not a script to run verbatim.
Standalone authoring
- Decide if it's worth it. Apply the sizing rule above. If one context window suffices, stop here and just do the task.
- Pick a sub-pattern from the catalog (or compose several).
- Choose the primitive:
parallel(barrier — you need all results together),pipeline(no barrier — items flow through stages independently, the default), or a loop (unknown amount of work). - Add verification — a separate agent per finding when correctness matters; default verifiers toward refuting, not rubber-stamping.
- Set guardrails — per-agent model tier, worktree isolation for parallel file edits, a token budget, and (for triage of untrusted content) quarantine: agents that read untrusted public content must not take high-privilege actions.
- Author the script and launch it, then return the synthesized result to the
caller: a dispatched build wave to
/aep-executorworkflowmode; a verification / eval folded back into/aep-validateor/aep-gen-eval; standalone research / triage presented directly (pair with/loopif recurring).
Read references/pattern-catalog.md for skeletons.
Why this is a first-class pattern (not just /aep-executor's workflow mode, and
why it sits beside /aep-gen-eval rather than inside it): rationale in
docs/decisions/workflow-rationale.md.