# Aep Workflow > Authors a re-runnable multi-agent harness for one task too large or uncertain for a single context. Use for "dynamic workflow" or "orchestrate subagents". - Skill: `memorysaver/aep-workflow` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add memorysaver/aep-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/memorysaver/aep-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: memorysaver (https://skillmd.com/u/memorysaver) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/memorysaver/aep-workflow --- # 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"](https://claude.com/blog/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`](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`](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 1. **Just ask.** "Set up a workflow to…" / "Use a workflow to verify every claim…". 2. **`ultracode` keyword.** Including `ultracode` forces Claude Code to author a workflow for the request. 3. **Within AEP.** "…with workflow" routes a dispatched build wave through `/aep-executor`'s `workflow` backend mode (one agent per locked story, hub-and-spoke gating) — see `/aep-executor` references (`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 1. **Decide if it's worth it.** Apply the sizing rule above. If one context window suffices, stop here and just do the task. 2. **Pick a sub-pattern** from the catalog (or compose several). 3. **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). 4. **Add verification** — a separate agent per finding when correctness matters; default verifiers toward refuting, not rubber-stamping. 5. **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. 6. **Author the script and launch it**, then return the synthesized result to the caller: a dispatched build wave to `/aep-executor` `workflow` mode; a verification / eval folded back into `/aep-validate` or `/aep-gen-eval`; standalone research / triage presented directly (pair with `/loop` if recurring). Read [`references/pattern-catalog.md`](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`](https://github.com/memorysaver/agentic-engineering-patterns/blob/main/docs/decisions/workflow-rationale.md).