When the Model Builds Its Own Harness: Anthropic's Dynamic Workflows and Why You Might Still Want Your Own

For a long time, getting good work out of an AI coding agent meant building scaffolding around it — a harness: the prompts, steps, tools, and checks that turn a raw model into a reliable worker. Anthropic's dynamic workflows move that job into the model itself. At runtime, Claude decides how to break a task apart and orchestrate itself to finish it. It works impressively well. It also quietly changes who owns the most important part of your setup.

What a harness is, and what dynamic workflows do

Anthropic's own framework splits agentic systems into two kinds: workflows, where models and tools are orchestrated through predefined code paths that you write, and agents, where the model dynamically directs its own process. Dynamic workflows push firmly toward the second. Claude plans the decomposition from your prompt, spins up tens to hundreds of parallel subagents in a single session, coordinates and verifies them, and adapts as it goes. With the right setting enabled, it will even decide on its own when a task is big enough to warrant a workflow at all. It shipped as a research preview alongside Claude Opus 4.8 in May 2026; one demonstration ported a large codebase from one language to another, producing roughly 750,000 lines with almost the entire test suite passing. In other words, the model now builds its own harness on the fly — and it is good at it.

Where it genuinely shines

Dynamic workflows are strong exactly where a hand-built harness struggles: genuinely unpredictable tasks where you cannot pre-specify the steps. Debugging an unfamiliar codebase, research that has to follow the evidence wherever it leads, sprawling migrations across thousands of files — these have a shape you do not know until you are inside them. Anthropic's guidance here is refreshingly honest: if you can specify the steps in advance, use a fixed pipeline; reserve dynamic decision-making for work that genuinely needs it. Letting the model assemble its own harness in the moment is the right call when the structure of the task is unknowable up front.

The cost is tokens, and it is not small. Reasoning at every step accumulates context, and dynamic workflows consume substantially more than a typical session. Error recovery is expensive, the behaviour is less predictable, and it is harder to audit than a pipeline you wrote. For anything you run hundreds of times, a fixed workflow is cheaper, fails faster when it fails, and is far easier to put into production. The model-built harness is a power tool, not a default.

The dependency that's easy to miss

Here is the part worth naming, and I will be explicit that it is opinion. Every capability the model absorbs is a capability you no longer build — and one that now lives inside a single vendor's product. When Claude selects and builds its own harness, the orchestration logic that used to be yours — portable, inspectable, model-agnostic — becomes Anthropic's: proprietary, opaque, and billed by the token. That is convenient. It also deepens your dependency on one provider at the exact moment that provider has filed to go public and has every reason to grow revenue per user. A harness you own travels with you; a harness the model builds for you does not.

To be fair, this is not a conspiracy, and Anthropic is unusually candid about when not to reach for dynamic workflows. But the direction of travel — more orchestration inside the model, less in your code — raises switching costs whether or not anyone intends it to. The more of your system is the model deciding for itself, the harder it is to move that system to a different model, a cheaper tier, or an open-weight option running on your own hardware.

The case for still owning your harness

The hedge is simple, and it is not anti-AI. Keep the orchestration you reasonably can in your own code. A harness you design — explicit steps, your choice of tools, your own evaluations — is portable across models, and even down to local or open-weight ones. It is cheaper to run at scale, auditable when something breaks, and it does not get more expensive because a vendor repriced. Use dynamic workflows where they earn their keep: one-off, unpredictable, large-surface work. Keep a model-agnostic harness for the repeatable core of what you do. That combination gets you the upside without betting your whole operation on a single company's price list.

The honest framing is not that dynamic workflows are good or bad. It is that the model building its own harness is a real advance for a specific class of work, and a real increase in dependency for everything else. Knowing which is which — and keeping the parts you would hate to lose in code you control — is the whole skill.

Sources: Anthropic — Building Effective Agents; Claude Opus 4.8; Introducing Dynamic Workflows in Claude Code; MindStudio — Anthropic Dynamic Workflows: When to Use Them (2025–2026).