Dynamic Workflows: When to Use Them and Avoid Token Burn
Prompt Engineeringgo watch the original →
the gist
Dynamic workflows move agent planning from context windows into versionable code scripts, enabling parallel execution and adversarial verification, but they require an objective test suite to avoid massive token waste.
The Breakthrough
Dynamic workflows shift the agent planning mechanism from a model's volatile context window into a versionable, executable script that manages agent orchestration, parallel task execution, and adversarial verification loops.
What Actually Worked
- Script-Based Planning: Unlike standard agent teams that rely on shared task lists within a context window, dynamic workflows generate JavaScript-like scripts that define the execution tree, including metadata, phase labels, and mapping logic.
- Adversarial Verification: The workflow implements an "implement-verify-fix" loop where independent agents attempt to poke holes in the generated code, requiring an objective oracle or test suite to validate success.
- Structured Primitives: The system utilizes specific primitives—
agent,parallel, andpipeline—to fan out tasks across up to 16 concurrent agents (with a hard limit of 1,000 agents per run). - Decision Framework: Use dynamic workflows only when an objective oracle exists to measure success, such as code migrations or security sweeps. Avoid them for creative or subjective tasks where no ground truth is available.
Before / After
- Migration Efficiency: In the Bun runtime migration from Zig to Rust, dynamic workflows enabled automated code conversion, though the resulting code contained 13,000 unsafe blocks compared to 73 in the original handwritten Rust, highlighting that automated output is not always production-ready.
- Token Consumption: A single workflow run can easily consume hundreds of thousands of tokens; the author demonstrated a migration task using approximately 750,000 tokens.
Context
Dynamic workflows represent a shift in how complex tasks are automated by moving away from monolithic orchestrators. While powerful, they are frequently misused for tasks lacking clear success criteria, leading to significant financial costs. The author emphasizes that these workflows are best suited for tasks with high test coverage where the agent can objectively verify its own progress against a defined baseline.
Notable Quotes
- "The plan is now a versionable artifact that you can access."
- "If you don't have ground truth which means you don't have unit tests or verifiable rewards, it's basically based on vibes."
- "It's code not context."