A developer running dynamic workflows with Claude Code has documented an approach that cut token spending by 80% and reduced workflow execution time from five or six hours to twenty or forty minutes. The method works by standardizing agent roles, moving test orchestration to a Makefile, and having Claude generate workflow JavaScript directly instead of reasoning through each step.
What the analysis revealed
The developer had Claude analyze weeks of workflow execution logs stored on disk. The analysis showed that despite the apparent complexity, every workflow boiled down to three types of steps, implemented in countless ad-hoc variations. The first type is a code change worker that takes a task from the plan and implements it, with multiple workers running in parallel. The second type is a gate agent that evaluates what the parallel workers produced and runs serial verification. The third type is the final check that deploys and runs end-to-end tests.
The realization was that the variability between workflows was not in the types of steps but in how those steps were implemented each time. Every workflow had workers, gates, and final checks. The differences were in the specific prompts, the test commands, and the deployment targets. Standardizing the agent roles and moving the variability into configuration eliminated most of the token spending on workflow construction.
Two standardized agents replaced custom prompts
The developer reduced the workflow to two standardized agent definitions, each written as a hundred-line markdown file that Claude does not need to regenerate. The workflow-worker agent receives a piece of the plan and tight permissions: it can only write and run tests for its own part of the plan, cannot fix anything that other workers might be touching, and cannot run the entire test suite. The workflow-gate agent receives results from parallel workers and runs serial verification based on what changed in the git tree.
The gate agent's behavior is driven by a Makefile with two targets. The serial gate target checks which files changed and runs the appropriate tests: if web files changed, run web tests; if backend files changed, run API tests. The final gate target runs the full test suite, deploys to staging, and runs post-deployment tests. Moving this logic into the Makefile means no tokens are spent reasoning about which tests to run. The git tree determines that.
Generating workflow JavaScript instead of reasoning through it
With standardized agent roles, the developer had Claude write a tool that reads a plan file with steps and dependencies and generates workflow JavaScript directly. Previously, Claude would spend ten minutes reasoning through a complex plan and producing the workflow. With the generator, the same output takes about a second. The workflow scripts are JavaScript, which Claude Code understands natively, and the generator reads the plan structure to compose the correct sequence of worker and gate calls.
Since the agent definitions are static markdown files written once, no tokens are spent writing prompts for workflow agents each time. Since the test orchestration lives in the Makefile, no tokens are spent deciding which tests to run. Since worker agents receive the plan and a step number, no tokens are spent telling them what to do beyond reading the specific step. The only token spending happens on creating the plan, narrow implementation tasks, and contextual fixes when something goes wrong.
Permission constraints through pre-tool-use hooks
When a named agent runs as part of a workflow, the context passed to pre-tool-use hooks includes the agent name. This lets the system constrain agent behavior based on the role. The workflow-worker agent is not allowed to run make or execute the entire test suite, with a message directing it to delegate those tasks to the gate agent. This prevents workers from expanding their scope and keeps them focused on their assigned portion of the plan.
The constraint mechanism works because Claude Code passes the agent name in the hook context. The hooks can check the agent name and reject or modify tool calls that fall outside the agent's allowed operations. This is a lightweight enforcement mechanism that does not require modifying the model or the prompts.
What this means for teams running dynamic workflows
The approach demonstrates that the cost of AI-assisted workflows is not fixed. Most of the token spending in dynamic workflows comes from the LLM reasoning about workflow structure, test orchestration, and agent coordination. Moving that reasoning into deterministic code, Makefiles and JavaScript generators, eliminates the token cost while preserving the flexibility to handle different plans and dependencies.
For teams building on Claude Code or similar tools, the practical lesson is that the LLM does not need to do everything. Standardize the roles, move the orchestration into code, and let the LLM focus on the parts that actually require language understanding: creating plans, implementing changes, and fixing problems. The rest is plumbing that should not cost tokens.