Dynamic Workflows: When the Agent Writes Its Own Harness

The week my orchestration code became dead weight

For a while I maintained my own way of running Claude across a big task: a small, fixed pipeline of specialized agents I had wired together by hand, each with its own role, each handing off to the next. It worked. I was proud of it. And over the past several weeks I have deleted most of it.

The reason is dynamic workflows. Anthropic announced them in Claude Code on May 28, 2026, and they are now generally available across the CLI, Desktop, and VS Code extension, as well as the Claude API, Amazon Bedrock, Vertex AI, and Microsoft Foundry. The idea is simple to state and surprisingly large in consequence: instead of me designing the multi-agent machine ahead of time, the model writes one on the fly, custom-built for the task in front of it.

My hand-built pipeline had exactly one shape, and every task had to fit it. A dynamic workflow has whatever shape the task needs, chosen and composed in the moment. That single difference is why the code I was proud of stopped earning its keep.

What a dynamic workflow actually is

Under the hood, a dynamic workflow is a JavaScript script that Claude writes for the task you describe, which a runtime then executes in the background, separate from your conversation. That separation is the whole trick. In an ordinary session, Claude has to hold the plan and do the work in the same context window. In a workflow, the plan moves into code: the loop, the branching, and the intermediate results all live in script variables, so your context holds only the final answer. The script itself has no direct filesystem or shell access – it only coordinates the subagents, and they are the ones that read, write, and run commands.

You do not write that script yourself. You ask for a workflow in plain language ("use a workflow to…") or drop the keyword ultracode into your prompt, and Claude writes and runs one. The same keyword doubles as a Claude Code effort setting: switch it on and Claude pairs xhigh reasoning with automatic orchestration for the whole session, deciding for itself which tasks become workflows – whereas the one-off keyword only affects the single prompt you drop it in.

Why hand the plan to a script

The honest answer is that a single long context window has failure modes, and the longer Claude works in one, the more susceptible it becomes to them. Anthropic names three:

• Agentic laziness – stopping after partial progress and declaring the job done, for example addressing 35 of 50 items in a review.
• Self-preferential bias – favoring its own results when asked to verify or judge them.
• Goal drift – losing fidelity to the original objective across many turns, especially after the context compacts and detail is lost.

A workflow attacks all three structurally rather than hoping the model behaves. The deterministic script, not the model, decides when the work is actually done. Verification is handed to agents that did not produce the work, so nothing grades its own homework. And each subagent runs in its own fresh, isolated context with the goal restated, so drift has nowhere to accumulate.

This is also the difference between a dynamic workflow and the static ones you might have built before with the Claude Agent SDK or claude -p. A static workflow has to work for every edge case, so it tends to be generic. A dynamic workflow, written by a model capable enough to author a custom harness (this landed with Claude Opus 4.8), is tailor-made for the task at hand. Generic versus tailor-made is the same gap I felt when my one-shape pipeline met a task that wanted a different shape.

Six shapes worth recognizing

You do not need to know how the script is written to use workflows well, but it helps to recognize the shapes Claude reaches for and composes. Anthropic's write-up "A harness for every task" (June 2, 2026, by Thariq Shihipar and Sid Bidasaria) lays out six common, composable patterns. Here they are, each as a picture.

Classify and act. A classifier decides what each item is, then code routes it to the right specialist. This is how mixed inputs – support tickets, error logs, feedback – each get the handling their type deserves.

graph LR
    Task[Task] --> Classify{Classifier}
    Classify --> |bug| A[Agent A]
    Classify --> |feature| B[Agent B]
    Classify --> |question| C[Agent C]

Fan-out and synthesize. Split the work across many agents, one per piece, then merge their structured outputs at a barrier that waits for all of them. Reviewing every file in a directory is the canonical case, and the one I reach for most: each file gets its own clean context so the reviews do not cross-contaminate.

graph LR
    Items[Items] --> W1[Worker]
    Items --> W2[Worker]
    Items --> W3[Worker]
    W1 --> Collect[Collect]
    W2 --> Collect
    W3 --> Collect
    Collect --> Synth[Synthesize]

Adversarial verification. For every finding, an independent agent tries to refute it against a rubric, and only findings that survive are kept. This is the antidote to self-preferential bias, and it is why a workflow's report tends to contain fewer confident-but-wrong claims – I lean on it hardest when a false positive is expensive, like a security pass.

graph LR
    Items[Items] --> Workers[Workers]
    Workers --> Findings[Findings]
    Findings --> V1[Verifier]
    Findings --> V2[Verifier]
    Findings --> V3[Verifier]
    V1 --> Vote[Majority vote]
    V2 --> Vote
    V3 --> Vote
    Vote --> Confirmed[Confirmed]

Generate and filter. Several generators produce candidates in volume from deliberately different angles, then a rubric-plus-dedupe step keeps only the best and visibly discards the rest. Naming, design, and other taste-driven work benefit from quantity before selection.

graph LR
    Prompt[Prompt] --> G1[Generator]
    Prompt --> G2[Generator]
    Prompt --> G3[Generator]
    G1 --> Filter[Filter + rank]
    G2 --> Filter
    G3 --> Filter
    Filter --> Best[Best result]

Tournament. Instead of dividing the work, agents compete on it: several attempt the same task different ways, and fresh judges compare them pairwise until a winner remains. Comparative judgment is more reliable than absolute scoring, which is the whole reason the pattern exists – and it is how you rank a list too big to score in one pass.

graph LR
    A1[Attempt] --> J1{Judge}
    A2[Attempt] --> J1
    A3[Attempt] --> J2{Judge}
    A4[Attempt] --> J2
    J1 --> JF{Final}
    J2 --> JF
    JF --> Winner[Winner]

Loop until done. When you do not know how much work there is, keep spawning agents until a round turns up nothing new, deduping against what you have already found. Exhaustive searches – dead code, flaky tests, dependency audits – want completeness, not a fixed number of passes.

graph LR
    Agent[Agent] --> Check{New findings?}
    Check --> |yes| Agent
    Check --> |no| Done[Done]

Real workflows chain these together: classify, fan out, adversarially verify, then synthesize. Recognizing them is enough to nudge Claude toward the right one in a prompt.

The payoff, and the bill

Here is the part that actually changed my mind. Because independent agents attack a problem from several angles and adversarially check each other before anything reaches you, a workflow can reach, in Anthropic's words, "results a single pass can't." In my own use that has meant tangibly better code, sounder architectural decisions, and fewer bugs surviving to the end – not on every task, but reliably on the hard ones where a single pass would quietly cut a corner.

That quality is not free, and it would be dishonest not to say so.

The rule of thumb I have settled on: most routine coding tasks do not need a panel of five reviewers. Reach for a workflow when a task is genuinely too big for one pass, or when the cost of getting it wrong justifies letting several agents argue about it first.

The same idea, arriving from two directions

Claude Code is not the only place this pattern is showing up. LangChain shipped dynamic subagents in Deep Agents, where an agent dispatches subagents from interpreter code with a task() call and combines the results in JavaScript loops and branches – the same move, a model writing code that dispatches more agents. By my own reading of the public dates, Claude Code got there first in late May 2026, and LangChain followed roughly a month later in late June. LangChain frames its version, in its Deep Agents blog posts, as "the same idea behind workflows in Claude Code and Recursive Language Models."

That last phrase is the interesting one, because it points at where this all comes from.

The research underneath: Recursive Language Models

The research idea is Recursive Language Models, and it is worth reading directly:

As I understand it, an RLM is an inference strategy: a language model works inside an interpreter, or REPL, where a very large context sits as a variable, and it programmatically explores that context, decomposes it, and recursively calls itself over slices of the prompt. The catch – and here I am relying on LangChain's write-ups of the paper as much as the paper itself, so treat it as a framing to verify – is that in the original idea the recursive children are mostly plain language-model calls, not agents with their own tools and state.

Dynamic workflows and Deep Agents move the interesting part. They keep the "a model writes code that decomposes the work and calls itself" structure, but they change the unit of recursion from a bare model call into a full agent – one with its own context window, its own tools, and the ability to actually read files, run tests, and use whatever it is connected to. That is my own way of putting it: RLM is recursion over context; these systems are recursion over agents doing work. Which is exactly why they end up closer to each other than to the paper LangChain traces them to, and why they feel like a more practical, applied version of the same idea. The recursion is not just reasoning about text anymore – it is work getting done, verified, in isolation, and that is what makes it useful for audits, migrations, research, and verification.

If you want the pattern named and studied rather than just used, there is a research framing for that too:

I am relaying its framing rather than vouching for it, but Recursive Agent Harnesses reportedly names and benchmarks exactly this – where the recursive unit is a full agent harness rather than a bare model call – and notes that Anthropic's dynamic workflows already use the same code-driven spawning in production. Its contribution, then, is naming and evaluating a pattern that shipped, not inventing the primitives.

Where it lives in my setup

Research framing aside, here is how this looks in daily practice. I do not run these workflows on a bare install; I run them inside AEGIS, my hardened, in-development Claude Code environment and daily driver. The important thing about AEGIS in this context is what it deliberately does not do: it ships no orchestrator of its own and no fixed roster of specialized agents. It rides on Claude Code's native dynamic workflows and supplies the layer around them – shared skills, always-on rules, quality-enforcing hooks, durable cross-session memory, and sensible defaults – so that every ephemeral subagent a workflow spawns starts from the same standards.

That closes the loop on the pipeline I opened with: it was AEGIS's old shape, and native workflows do that orchestration better and more variously than my hand-wired version ever could. So AEGIS stopped trying to be the orchestrator and now hardens the harness instead of replacing it.

A skill for the part the tool leaves out

There is one gap worth closing. The tooling that runs workflows teaches you the API and the mechanics, but not the judgment: which of the six patterns to reach for, which agent roles to combine for a given task, which model tier to give each role, and how to keep a long run alive through server errors, interruptions, and token budgets. That judgment is exactly what you accumulate the slow way, one run at a time.

I distilled mine into a small skill, dynamic-workflow-patterns, and published it in claude-code-artifacts-public. It is a single file, so one command installs it into Claude Code:

npx --y skills@latest add alex-feel/claude-code-artifacts-public --skill dynamic-workflow-patterns -g -a claude-code --copy -y

Still early

Workflows are new, and the best practices are still forming – Anthropic says as much, and so do I. But the shift underneath is real and, I think, permanent: the model no longer just works the task, it designs the machine that works the task, and it checks that machine's output before you ever see it.

One last note, in the spirit of the thing: I did not take my own factual claims here on faith. Before publishing, I had a workflow check every claim in this post against its sources and flag anything that was only my own reading rather than a documented fact – which is why the paragraphs about RLM and the timeline are hedged the way they are. That is a small example of the pattern, pointed back at the writing about it. Try a small one on something you care about being right, and see what it catches.