The annoying part about spec-driven agent work is that the boring advice keeps being right.

Write the plan before the code. Keep implementation in a cleaner context than planning. Make the acceptance criteria explicit. Review the result in a separate pass. Use tests, traces, source links, or some other external receipt instead of letting the same context that produced the answer be the only thing judging it.

None of that sounds futuristic. It sounds like process. It is process. It is also where most of the real progress has been hiding.

The first wave of agent hype was about models that could write code. The next useful wave was about learning how to wrap those models: specs, plans, AGENTS.md, skills, todos, review agents, verification gates. We learned, mostly by getting burned, that an agent with a loose prompt is not a coworker. It is autocomplete with a shell account and confidence issues.

Dynamic workflows in Claude Code are interesting because they take that manual discipline and turn it into an artifact the agent can write itself.

Not just "make a plan." Not just "spawn some subagents." The actual primitive is stranger: Claude writes a JavaScript workflow that owns the plan, the fan-out, the fan-in, the review passes, the loops, and the intermediate state. The plan stops being prose the model is supposed to remember. It becomes code the runtime executes.

Blueprint-style diagram: human intent becomes a spec, Claude writes an orchestrator, implementation agents and verifier agents produce a final artifact.

We were already doing this by hand

Spec-driven development is a polite name for a thing most people started doing because the naive version sucked.

The naive version was: open Claude Code or Codex, paste the goal, and hope the agent keeps the whole job straight. Sometimes it does. Sometimes it performs the first four steps beautifully, forgets the fifth, changes a file nobody mentioned, invents a passing test result, and writes a summary with the emotional texture of a project manager leaving early.

So we added structure.

First, we made the planning step explicit. The agent had to produce a plan before touching code. Then we separated planning from implementation, because the context that explores options is not always the context you want writing the patch. Then we started writing acceptance criteria because "looks good" is not a contract. Then we added review agents, lint gates, test commands, and little repo-specific rules because every agent eventually finds a way to misunderstand the obvious thing.

That whole stack is a human-authored orchestrator, even when it does not look like one.

The human says: do discovery first. Now stop. Summarize. Now implement. Do not use the old context too much. Now review. Now run the check. Now fix what failed. Now summarize only what actually happened.

That is orchestration. It is just orchestration performed through chat turns and vibes.

Dynamic workflows move that orchestration into a script.

Chat is too soft to be the runtime

A long agent run has three jobs fighting for the same context window.

Planning wants breadth. It wants options, prior art, weird edge cases, and permission to challenge the first framing.

Implementation wants depth. It wants the chosen plan, surrounding files, conventions, invariants, and enough local detail to avoid breaking the repo.

Review wants freshness. It should not inherit every rationalization from the implementation pass. A reviewer that already absorbed the author's intent is more likely to validate intent than inspect behavior.

When all three jobs happen in one conversation, the context becomes a junk drawer. Some useful things are in there. Also logs, stale assumptions, half-fixed errors, prior summaries, and the agent's own explanation of why its previous answer was probably fine. Then compaction arrives and turns the junk drawer into a smaller junk drawer with a confident label.

That is why the context boundary matters. Not because fresh contexts are aesthetically pleasing. Because different phases need different evidence.

A workflow makes that boundary architectural. The script can give one agent the narrow file-level task, another agent the rubric, another agent the job of trying to refute the result, and keep the parent conversation out of the exhaust. Claude's main context does not need to ingest every intermediate tool call. The workflow runtime can hold the intermediate state and return the synthesized result.

That is the real design move: not more agents, but less conversational mush between phases.

Comparison diagram showing a chat-loop runtime with all phases mixed in one context, versus a workflow runtime where the script owns state and phase boundaries.

The plan becomes an inspectable object

The Claude docs describe a dynamic workflow as a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task, then a workflow runtime executes it in the background while the session stays responsive.

That sounds like a feature bullet until you follow the consequence: the plan is no longer only in the model's working memory. The orchestration is encoded as a script you can inspect and rerun. You can save a successful workflow as a command. Saved workflows live in .claude/workflows/ for a project or ~/.claude/workflows/ for your own machine. Saved workflows can accept structured args.

That turns a successful process into something you can inspect, reuse, and share.

The runtime also gives the shape people keep rebuilding around agents anyway:

  • phased execution
  • fan-out across isolated contexts
  • fan-in synthesis
  • adversarial review
  • progress UI in /workflows
  • token accounting per phase and agent
  • pausing, stopping, restarting, and saving

There are hard limits. The docs say up to 16 concurrent agents and 1,000 agents total per run. The workflow script does not directly read files or run shell commands; agents do that work. There is no arbitrary mid-run user input except permission/tool prompts. Resume works within the same Claude Code session; if you exit while it is running, the next session starts fresh.

Those caveats matter. The marketing version wants you to picture a thousand tiny engineers. The useful version is much more specific: a generated task harness with clean phase boundaries and a progress surface.

Rubrics are the same lesson from the other side

LangChain just shipped RubricMiddleware for Deep Agents, and it is a useful comparison because it attacks the same problem from the opposite direction.

Deep Agents is LangChain's opinionated agent harness on top of LangGraph. It bundles the things serious agent systems keep rediscovering: planning, filesystem context, subagents, memory, skills, permissions, human approval, streaming, checkpointing, and production deployment through LangSmith or LangGraph. It is not "the model writes the harness." It is "the developer configures a harness that can survive production."

RubricMiddleware adds an explicit grader loop to that harness.

The base agent attempts the task. A separate grader sub-agent reviews the transcript against a rubric. If every criterion passes, the run ends. If not, the grader returns per-criterion feedback, that feedback gets injected, and the agent tries again until it satisfies the rubric or hits an iteration cap.

The statuses are wonderfully unromantic: satisfied, needs_revision, max_iterations_reached, failed, grader_error.

Good. We need more unromantic agent infrastructure.

This is basically acceptance criteria becoming executable at runtime. The agent is not merely told what done means. A separate process checks whether done happened and drives another pass when it did not.

Rubric loop diagram: attempt, grader, per-criterion feedback, revise, terminal verdict.

The contrast is useful.

Claude dynamic workflows bet that the agent can generate the task-specific orchestrator. LangChain Deep Agents bet that engineers want a configurable harness with explicit runtime guarantees. Dynamic workflows are more like a compiler for bespoke process. Deep Agents are more like an application framework for agents you intend to operate.

Both are responses to the same discovery: prompts are too soft for long-running work. Plans, context boundaries, and verification need somewhere harder to live.

The Bun example is a migration harness, not a miracle

The Bun rewrite is the case everyone is going to cite until the numbers dissolve into folklore.

The clean version from Anthropic's post: Jarred Sumner used dynamic workflows to port Bun from Zig to Rust with 99.8% of the existing test suite passing, roughly 750,000 lines of Rust, and eleven days from first commit to merge. The work was not yet in production. One workflow mapped Rust lifetimes for struct fields. Another wrote .rs files as behavior-identical ports of .zig files, with hundreds of agents working in parallel and two reviewers per file. A fix loop drove the build and test suite until they ran clean. After the port landed, another workflow addressed unnecessary copies and opened PRs for review.

Jarred's own X thread uses the sharper line: dynamic workflows and adversarial code review were part of what made it possible to rewrite Bun in Rust in six days. He also describes the useful pattern:

  1. do the work
  2. adversarial review
  3. apply changes

And, importantly: during each unit of work, ban slow/global commands like git and cargo so parallel agents do not stomp on each other. Run the expensive consolidation steps after the isolated work is done.

That is not magic. That is a migration harness.

The task had file-shaped units. It had porting guidance. It had a large test suite. It had a brutal external judge. It had review agents trying to break each file before the result was folded in. The workflow did not make correctness appear out of nowhere. It created a structure where many local attempts could be made, attacked, merged, and checked against a real oracle.

That distinction matters because most software work does not look like that. If you point a workflow at a vague product idea with no tests, no rubric, no acceptance criteria, and no obvious decomposition, you did not invent an autonomous engineering team. You bought a faster hallucination pump.

The better everyday cases are boring

The more useful examples are less cinematic.

Cat Wu from Anthropic described using dynamic workflows to catalogue hundreds of A/B test flags and find ones rolled out to 0% or 100%, so stale flags could be deprecated. That is a perfect workflow-shaped task: many independent items, same classification logic, parallel investigation, one final list.

Klarna's quote in the launch post is similar: discovery and review across large codebases, identifying dead code and cleanup opportunities static analysis missed. Again: lots of candidate units, contextual judgment per unit, aggregation at the end.

The same shape applies to auth audits, API deprecation migrations, flaky test investigations, technical claim checking, incident root-cause clustering, and support triage. The task does not need to be glamorous. It needs to be decomposable, checkable, and worth the token bill.

I would rather run a workflow that verifies every factual claim in an article against the linked docs than a workflow that claims to design an entire product from scratch. One has receipts. The other has vibes wearing a hard hat.

The convergence: process is becoming part of the artifact

This is the part I keep coming back to.

For a while, the artifact was the code. Then, as agents got better, the artifact became the spec plus the code. The plan mattered because it controlled the model. The acceptance criteria mattered because they constrained the output. The review notes mattered because they explained what survived.

Dynamic workflows add another artifact: the process that produced the result.

That process can be generated, inspected, saved, rerun, and revised. It can encode how work is split, what context each worker sees, which checks run before synthesis, what counts as convergence, and where the human needs to approve the next move.

Rubrics push the same direction from the verification side. The rubric is not just prose guidance. It is part of the runtime loop. It tells the grader what evidence to demand before the agent is allowed to stop.

So the stack starts to look like this:

  • spec: what we are trying to do
  • workflow: how the work gets decomposed and coordinated
  • rubric: what done means
  • trace: what actually happened
  • artifact: the code, report, PR, or decision that survived the process

Layered map: spec, generated workflow, rubric, trace, artifact.

That is a different mental model from "ask the agent to do the task." You are asking the agent to build or inhabit the machinery that does the task.

Generated harnesses versus configured harnesses

I do not think dynamic workflows replace LangGraph, Deep Agents, Temporal, custom queues, or boring production orchestration. That would be a stupid conclusion, and the internet will arrive there on schedule anyway.

They sit at a different layer.

A dynamic workflow is compelling when you have a high-value, task-specific process that would be annoying to hand-code every time: a migration, audit, research pass, claim check, or adversarial planning session. You want the agent to synthesize the harness because the harness itself is part of the thinking.

A configured harness is better when the process is stable enough to operate: customer-facing agents, recurring production jobs, multi-tenant systems, remote sandboxes, long-running async agents, auth boundaries, traces, evals, retries, human approval, and all the other parts nobody wants in the keynote because they make the diagram ugly.

That is why the LangChain comparison is useful. Deep Agents and RubricMiddleware are not less advanced because a developer configures them. They are aimed at a different failure mode: not "can the agent invent the right process for this one task," but "can this process run reliably for many users, many times, with observability and control."

Claude is pushing orchestration generation. LangChain is pushing orchestration infrastructure. The interesting systems will probably use both ideas: generated task plans inside runtime environments with explicit rubrics, traces, permissions, and recovery.

The failure mode is parallel nonsense

The obvious failure mode is cost. Dynamic workflows can burn tokens quickly. The docs say to start with a scoped slice, and for once the docs are not being dramatic.

The less obvious failure mode is fake verification.

An adversarial agent is not automatically adversarial in the useful sense. It can share the same blind spots as the worker. It can grade the wrong thing. It can accept a plausible explanation because the output looks complete. It can produce a report full of "concerns" that are not connected to any failing evidence. You can absolutely build a theater where agents review agents until everyone feels very process-mature and nothing got safer.

The antidote is boring again:

  • atomic claims
  • explicit rubrics
  • tool-backed checks
  • test commands
  • source citations
  • diff inspection
  • permission boundaries
  • human gates where taste or risk actually belongs

If the workflow cannot say what evidence would change its mind, it is not verification. It is vibes with extra steps.

The line I think matters

We are moving from promptcraft to processcraft.

That sounds a little cute, and I hate it, but it names the real change. The leverage is not just asking the model better questions. It is shaping the process around the model so the right context enters at the right phase, the wrong context stays out, and the answer has to survive something stricter than the agent's own confidence.

Spec-driven development taught us to write the contract before asking the model to build. Dynamic workflows let the model write the temporary machinery for executing that contract. Rubrics make the definition of done executable. Traces tell us what actually happened.

The agent is no longer just writing code.

It is starting to write the orchestrator around the code.

That is the part worth paying attention to.

Sources