Claude from Anthropic: Revolutionizing AI Workflows

A New Era for Managing Complex Tasks

Anthropic has recently introduced an innovative approach to managing complex tasks with Claude, their artificial intelligence model. For most of 2024 and 2025, the default response was simple: delegate the task to an agent, use the largest available context window, and wait. Sometimes, this worked. Often, the model would quietly lose track along the way.

Anthropic directly addressed this issue: long-term tasks require agents to maintain coherence across many steps, often beyond what a context window can reliably support. While enlarging context windows provided some assistance, it did not resolve the fundamental problem.

To mitigate these issues, Anthropic developed several tools such as sub-agents, skills, and agent teams. These tools allowed for the delegation of secondary tasks to isolated workers, each with their own fresh context, and for the summaries to be gathered in the main conversation. Skills, on the other hand, packaged repeatable workflows into Markdown files, a recipe that Claude could follow on demand. Agent teams went even further: multiple independent sessions of Claude, each with its own context window, coordinating through a shared task list and communicating directly.

Limitations of Existing Tools

Despite these advancements, each tool still had the same structural ceiling. With sub-agents, the orchestrating session of Claude still holds the plan. Each result returned by a worker lands in the context window of the main conversation. With sub-agents, skills, and agent teams, Claude is the orchestrator: it decides in turn what to generate or assign next, and all results accumulate in the context. This means that the orchestrating context expands as the number of agents increases, eventually reaching its limits. As a result, orchestration degrades, and the same failure modes appear.

Anthropic identified three failure modes that systematically arise when a context window—whether belonging to a single agent or to an orchestrator directing a small team—is responsible for a task too vast to be tracked properly. This is where the three common failure modes manifest.

• Agentic Laziness — It starts the task but does not complete it fully. It may stop early, skip certain files, or assume that the remaining work is sufficiently similar. Then it confidently declares that the entire task is finished. It's like a person who only checks part of a long Excel spreadsheet but marks the whole thing as reviewed.

• Self-Preferential Bias. The AI is not very strict when it comes to judging its own output. If you ask it, “Did you follow the instructions?”, it often responds yes, as it tends to give itself the benefit of the doubt. It may overlook its own mistakes or overestimate the quality of its response.

• Goal Drift. Over the course of a long task, the AI slowly loses sight of the initial goal. It may remember the main task but forget important details like “do not include X,” “do not skip any files,” or “use only this format.” The longer the conversation or task goes on, the more likely this drift becomes.

These are not bugs. They are the consequences when the plan is a thought, and thoughts degrade.

A Revealing Case Study

The cost became hard to ignore in early 2026 when Jarred Sumner, creator of Bun, had to port around 750,000 lines of Zig to Rust, file by file. In the past, a task like this would have taken months for a team. Sumner's scheme was simple: complete a unit of work, conduct an adversarial review, and then apply the changes. He later described dynamic workflows as “the state of the art today for reliably using agents to complete medium to large-sized projects.” The result: 750,000 lines of Rust, 99.8% of the existing test suite passed, and only 11 days between the first commit and the merge.

The key idea is that Claude does not need to keep the entire plan in mind. The workflow moves the plan into the code. The script contains the loop, branches, and intermediate results. Claude only needs to manage the current step and the final synthesis. The plan becomes a JavaScript file. It does not forget, does not drift, and does not stop halfway by declaring the work finished.

This is the problem that dynamic workflows were designed to solve. And this is what this article is about.

What is a Dynamic Workflow?

A dynamic workflow is like replacing an exhausted person with a small, targeted team.

Instead of asking an AI to manage the entire project from start to finish, you break the work into clear pieces. One agent handles a task. Another checks the result. Another moves the work forward. As a result, no one gets fatigued along the way and starts cutting corners. No one gives themselves a perfect score just because they wrote the answer. And no one forgets the original brief, as each agent only has to manage a clear piece of the work.

Claude's dynamic workflow helps you do this. It divides the work among a team of Claudes with fresh context. Each manages a small part, another layer checks the work, and the results are merged into a single response for you.

The key word here is harness. A harness is the scaffolding around the model: the part that decides how a task is planned, divided, checked, and executed. Claude Code's default harness is primarily designed for coding tasks. The Anthropic team found that these dynamic harnesses are “sometimes even more useful for non-technical work.” They then created it on the fly, shaped around the task you give it.

Before going further, it is helpful to separate a workflow from a few other words that are often mixed up. Tools, agents, harnesses, and workflows are often used as if they mean the same thing. This is not the case. The clearest way to separate them—I draw from this formulation from AlphaSignal—is to ask a question: who holds the plan?

A sub-agent is an aide that the main Claude sends for a specific job. The plan always remains with the main Claude. The sub-agent does its part, returns the result, and that result appears in your discussion. It is primarily fire-and-forget. As shown in the table below, a sub-agent cannot create its own aides or talk to other sub-agents.

An agent team is different. It is a group of Claudes working side by side, coordinating as peers. The plan does not reside inside a Claude. It lives between them. They can message each other, adjust as the work unfolds, and continue on a broader shared task. It’s more like entrusting a project to a small team.

A dynamic workflow is yet another different concept. Claude writes a small JavaScript program for the task itself. In this case, the plan lives in the code. The agents perform their work alongside, their outputs are stored in variables, and only the final merged response comes back to you.

An agent team and a dynamic workflow may seem similar. However, they are totally distinct. Check the table below to see this.

| Sub-agent | Agent Team | Dynamic Workflow | |------------|------------|------------------| | Who holds the plan | the main Claude (orchestrator), in its head | the peers, among themselves | a JavaScript program | | Lifecycle | fire-and-forget, one job | long, ongoing | runs once, returns a response | | Can they communicate with each other? | no — the orchestrator directs everything, and a sub-agent cannot even generate its own sub-agents | yes — they coordinate as peers over time | no — the agents work alongside in script variables; only the final response comes back | | Feel | an intern to whom you assign a task | colleagues on a shared project | an assembly line you designed |

And you might ask another question. What does dynamic mean? What are the differences between dynamic and static?

You could still build a harness yourself. You could connect the Agent SDK, or run claude -p in a loop, and create a fixed system that you use over and over again. This is a static harness: useful, repeatable, but designed in advance.

A dynamic harness is the opposite. Claude writes the harness on the fly, shaped around the task you just gave it. It plans the structure, divides the work, executes the agents, checks the outputs, and then discards the harness once the work is done—unless you press s to save it.

Static harnesses are versatile; dynamic ones are custom and disposable.

Claude is now capable of building dynamic workflows because Opus 4.8 is powerful enough to create the right harness on the fly—as the Anthropic team said, “smart enough to write a custom harness tailored to your use case.”

The Real Test

Models that Make Dynamic Workflows Useful

There are 6 workflows that Anthropic introduces, and I conducted some tests with them to intuitively show you how they work. They are:

• Fan-out-and-synthesize — divide the work, then merge it. Each piece gets its own agent and a clear context; a final synthesizer waits for all before combining the results.

• Adversarial checking — for each finding, generate a separate agent whose sole job is to contradict it. A skeptic checking the optimist.

• Classify-and-act — use a classifier agent to sort each item first, then direct it to the right manager. A reception desk.

• Generate-and-filter — brainstorm widely, then filter according to a criterion: deduplicate, verify, keep only what stands up to scrutiny.

• Tournament — generate N agents who each attempt the same task differently, then have a judging agent compare them in pairs until one wins. Good for taste and naming.

• Loop-until-done — for tasks of unknown size, continue generating agents until a stopping condition is met (no new findings, no more errors) rather than a fixed number of passes.

However, it is crucial to note that dynamic workflows consume significantly more tokens than a standard session, and using them for the wrong task constitutes a form of failure in itself.