How I Beat Anthropic to Dynamic Workflow by Four Months

Last week, Opus 4.8 shipped alongside Claude Code with dynamic workflows. But four months earlier, I had already built an equivalent plugin called charge on top of Opus 4.5: you just give it a prompt, and it creates and orchestrates reusable workflows powered by subagents.

“Charge” here means a charge — many subagents charging in to get your tasks done.

Not long after, I abandoned the project because it turned out that dynamically generating and reusing subagent workflows was actually a fake need. Still, subagent-based orchestration remains central to my daily work in Claude Code. These days I’ve switched to amplify (amplify@wezzard-skills), which distills the lessons I learned while building charge.

If you’re building agents, I hope this story helps you catch the next real capability leap in new models, and avoid the dead ends I hit when designing a dynamic workflow system like Claude Code’s. Anthropic doesn’t publish their implementation details or design rationale, but this article and the open-source repo will break it all down.

Why Did I Build Charge?

Since August 2025, I’ve been running a long‑running agentic loop inside Claude Code / Opus 4.1, driving my personal project development through a detailed plan file.

In practice, this is a subagent‑driven loop. Because LLMs work by next‑token prediction, subagents provide excellent context isolation; one of the most effective ways to raise the floor of system performance is to keep irrelevant content out of context.

The loop includes an evaluator and several executor subagents that follow the plan — developing, testing, debugging, and integrating checkpoints. This subagent‑based design achieves context isolation, and every step benefits from it.

In September 2025, I wrote an article explaining how this system works. Two months later, Anthropic published an article introducing the “harness” concept, using a similar design.

When Opus 4.5 arrived, the subagents’ responses in the loop sometimes included task details that allowed the main agent to bypass the loop’s evaluator‑executor pattern and complete the task on its own. Around the same time, Claude Code introduced background tasks and parallel subagents. These two new features made this “task leakage” to the main agent actually faster, because leaked tasks would sometimes be further decomposed and processed in parallel. By January 2026, I had used Claude Code to spawn over 70 parallel subagents for a file‑processing task.

Overall, from Opus 4.5 onward, running and coordinating subagents became much easier. So I wondered: could we create and manage reusable subagent‑powered workflows, borrowing concepts from structured concurrency like task trees and directed acyclic graphs (DAGs) to build their dependency relationships?

Implementation Details & Design Philosophy

The implementation details of charge are actually straightforward: it’s entirely prompt‑driven and constrained by dynamically generated schemas. charge is open source, so I’ll focus on a few key points that people often mistake for “magic.”

Task Decomposition & Dependencies

Task decomposition and dependency construction are implemented using chain‑of‑thought:

• Understand the user’s intent

• Identify recurring patterns within that intent

• Split tasks so each one has a single, clear objective with distinct inputs and outputs.

• Define the attributes used in the task schema.

• Map dependencies into a task dependency graph.

Following this chain of thought, the model converts a simple user prompt into a JSON object representing the decomposed task dependency graph:

Tasks live in the tasks array, each with a depends_on field for dependencies. The workflow executor then consumes this JSON object directly.

Execution Engine

By reading the task dependency graph from the JSON object, Claude Code can “magically” execute tasks in dependency order.

Anthropic uses a deterministic execution engine written in JS for this part. For systems that need to orchestrate many subagents, I believe this is the right choice. An LLM works purely by next‑token prediction, but a prompt‑based execution engine has to rely on the model to infer the execution order and issue the correct tool call to start the next agent when the previous one finishes — neither of which is guaranteed.

However, even if all subagents are orchestrated in JS, you can still implement the execution engine using a generator pattern and run it directly inside the main agent:

In this design, the main Claude Code agent remains responsible for orchestrating the whole workflow. Whenever an agent finishes a task, the model must invoke complete-task.sh and, based on the tool output, generate new subagents.

Cost & Correctness

Once the workflow is built and ready to run, charge uses Claude Code’s plan mode to let the user review the decomposed workflow.

This review step is essential because dynamically generating subagents based on tasks charges by output tokens. Specifically, the main agent has to output the prompts used to generate these subagents, and output tokens are far more expensive than input tokens. This design effectively implements a token‑cost perspective of “progressive disclosure.”

Control & Direction

Here, charge has a unique advantage over Claude Code’s dynamic workflows. Because charge’s workflow orchestration remains inside the main agent, you can interrupt and steer it at any point during execution.

Why I Call It a Fake Need

After using charge for a while, I found that the workflows with the highest reuse rates in practice are better implemented as deterministic algorithms. That work should be in code, not in prompts.

LLMs are only needed when creativity is required. In reusable workflows, LLMs typically appear in analysis, diagnosis, or tasks like “porting Bun from Zig to Rust” — Anthropic showed the latter as a prime example in their dynamic workflow demo. For creating something brand new from scratch, keeping a human in the loop and adjusting direction as you go is the right path.

Even in analysis and diagnosis tasks, you can still use code to produce cleaner, more readable tool outputs and merge tool calls by inlining multiple tools in a script. This improves execution speed and reduces noise in context. These optimizations are critical and directly affect workflow performance and result quality. After all, what we really care about is whether the analysis or diagnosis yields actionable suggestions.

Moreover, for action‑oriented tasks, you can use an agent SDK like OpenCode SDK to introduce type safety in data transfer and in‑process communication, instead of cross‑process tool calls. OpenCode SDK uses the same session format as OpenCode, so an OpenCode SDK session can be continued directly in the OpenCode client. This interoperability brings debuggability to LLM‑driven workflows — a long‑overlooked gem in the agent ecosystem.

Research tasks are an exception. Research is still far from action and requires multiple layers of judgment before it can be turned into action. That’s probably why Claude Code has a built‑in /deep-research workflow.

Use the decision tree below to choose the right tool:

My Final Choice

With that decision tree, the conclusion is crystal clear:

• To create something new, we still need a human in the loop to guide the agent as it runs.

• To run reusable workflows, we have cheaper options — use OpenCode with a cost‑effective model, or just write code (code only costs CPU time, not tokens).

And the first item is exactly the bottleneck I face daily in Claude Code.

So, drawing from charge’s design elements, I built amplify in February 2026:

• Task dependency graph with dedicated subagents per task.

• Plan‑based task graph review.

• Execution inside the main agent for on‑the‑fly steering.

To prevent Claude Code from declaring a task “done” too early, amplify also introduces audit subagents that verify whether the planned work actually got done.