Dynamic Workflows: stop assuming the LLM will remember the whole workflow

"But I wrote it at the beginning"

Yes.

But then there were:

• dozens of tool calls,
• several failing tests,
• many files read,
• a plan change,
• subagent results,
• perhaps context compaction.

After an hour, the model can:

• skip one instruction,
• consider the task finished too early,
• fail to return to an earlier TODO,
• interpret "done" differently than you.

That does not mean Claude works badly.

It means we are using a probabilistic model as memory for required step order.

That is the wrong responsibility.

A context window is not a workflow engine

We have two separate problems.

Reasoning problem

How should the feature be implemented?

Claude is a great tool for that.

Orchestration problem

After implementation there must always be review, after blockers a fix, and after the fix verification.

This can be written deterministically.

implementation
-> review
-> blockers?
   yes -> fix -> verification -> review
   no  -> final verification

The model should not "remember" that this graph exists.

The graph should exist outside the model's memory.

Dynamic Workflows

Claude Dynamic Workflows solve exactly this kind of problem.

Instead of driving orchestration turn by turn in one conversation, Claude can prepare an executable workflow script.

The runtime executes that script.

A workflow can:

• run subagents,
• fan out work in parallel,
• wait for results,
• pass results to later stages,
• execute conditions,
• execute loops,
• run separate verification passes.

Schema:

Claude
-> creates workflow script
-> Workflow runtime
   +-- research agents
   +-- implementation
   +-- reviewer
   +-- tester
   +-- conditions
   +-- verification

The key difference:

Step order no longer exists only as a sentence from 40 thousand tokens ago.

It becomes part of an executable structure.

Two different loops

This is a good moment to organize the concepts.

Agent loop

Inside a single task:

Claude
-> tool
-> result
-> Claude
-> tool
-> result
-> ...

This is the loop of one agent performing one task.

Workflow loop

At a higher level:

implementation
-> review
-> blockers?
   yes -> fix -> review

This is a loop between stages of work.

Dynamic Workflow lets you write that second layer explicitly.

What do you gain?

1. Verification actually happens

If it is in the workflow, it does not depend on the memory of the current session.

2. A large amount of work does not have to flood one context

Subagents get scoped tasks.

The workflow keeps results and passes them onward.

3. Parallelism is explicit

If review and test analysis can run independently:

implementation
-> review
-> tests
-> merge findings

you do not have to rely on the main agent rediscovering that strategy every time.

4. The workflow can be improved

If you discover:

After a fix, reviewer should run again, not only tests.

you change the workflow.

You do not have to remember to add that sentence to every later prompt.

Not every task needs a workflow

If the task is:

Fix this single failing test.

a normal Claude Code agent loop is probably enough.

Dynamic Workflow starts making sense when:

• the task has several mandatory stages,
• you use multiple subagents,
• you need independent verification,
• part of the work can run in parallel,
• required steps start disappearing in a long context window.

Example from everyday SDLC

You want a standard for a larger implementation:

1. analyze requirements
2. inspect existing architecture
3. implement
4. run relevant tests
5. independent review
6. independent test analysis
7. fix blockers
8. re-run verification
9. final summary

Before:

one big prompt
-> I hope Claude remembers 1-9

After:

workflow
-> stages 1-9 are explicit
-> Claude makes decisions inside stages

This is a very important split of responsibilities:

Claude
= how to perform an intelligent step

workflow
= which step must happen and what follows

Is this already a durable workflow engine?

Do not mix these things.

Dynamic Workflow solves orchestration of a Claude task and lets you move control flow outside one context.

If you need a workflow that:

• waits two days for approval,
• must survive the whole platform failing,
• reacts to webhooks from several systems,
• has durable state independent of the session,

you are entering the category of external durable orchestrators.

But for a large part of everyday agentic coding, you do not need to start there.

First move required stages from LLM memory into an executable workflow.

Implement this today

1. Find a task where you write long "then do..."

Good candidate:

implement
-> test
-> review
-> fix
-> test

2. Write down mandatory stages

Not as a prompt.

As a graph:

A
-> B
-> C
   fail -> D -> B
   pass -> E

3. Run the task as a Dynamic Workflow

Let Claude prepare the workflow instead of driving the whole thing only turn by turn.

4. Inspect the generated script

Check:

• whether mandatory steps are explicit,
• where subagents are run,
• which stages are parallel,
• when verification happens,
• what the completion condition is.

5. Save a good workflow

If this is something you repeat in the SDLC, do not generate the whole structure from scratch every time.

Treat the workflow like another engineering artifact.

Level complete

The level is complete if you can answer:

What happens if main Claude forgets the instruction "run verification at the end"?

and the answer is:

Nothing. Verification is part of the executable workflow, so it does not depend on model memory.

At the final level, we remove one more dependency: the need to run all the work in a Claude Code session on your laptop.

Materials

• Dynamic Workflows / Claude Agent SDK cookbook