DeskTheory is where founder-CEOs learn to run their companies on AI leverage.

When to use a goal vs. a dynamic workflow in Claude Code

Two new Claude Code features that both let it keep working without you. A dynamic workflow goes wide. A goal keeps going. One question tells you which to reach for.

Claude Code shipped two features in a few weeks that both let it run on its own, and it is easy to treat them as the same thing. They are not. One is built to go wide. The other is built to keep going. Reach for the wrong one and you either get a shallow answer or a job that quits before it is done. A dynamic workflow is about breadth. A goal is about persistence.

What they are (in plain English)

A dynamic workflow hands one big job to many agents at once. Claude plans the work, splits it into pieces, runs tens to hundreds of subagents (separate copies of itself) in parallel, checks their results, and gives you one finished answer. You start one by asking Claude to "create a workflow," or by turning on the ultracode setting.

A goal is the opposite move. You type /goal followed by a finish line, like "every test in the auth folder passes," and Claude works turn after turn toward it. After each turn a separate, smaller model reads what happened and decides one thing: is the condition actually met? If not, Claude takes another turn, using the reason it fell short as the next instruction. It keeps going, sometimes for hours, until the finish line is true or you stop it with /goal clear. The slash command /goal shipped in Claude Code in May 2026.

The difference that matters: a workflow does many things at once and then stops. A goal does one thing at a time and refuses to stop until a checker confirms it is done.

Why you should care as a CEO

The whole game is one question: do you need to go wide, or keep going?

Go wide, and you want a dynamic workflow. The job breaks into pieces that can happen at the same time: read forty contracts and pull the renewal dates, audit a large codebase, research a market from a dozen angles at once.

Keep going, and you want a goal. The job has a clear finish line but you do not know how many tries it will take to get there: "until the tests pass," "until the backlog is empty," "until every deal in the pipeline has a next step."

The expensive mistake is reaching for the wrong one. Run a vague workflow at a job that needed a finish line and it does a few reasonable things and quits with nothing actually done. Set a goal on a job that needed breadth and it grinds through one at a time what a workflow would have finished in parallel.

The best jobs use both. Set a goal as the stop condition and let workflows do each turn's heavy lifting. The goal is the part that refuses to quit until the end state is real; the workflow is the part that does each round wide and fast. One caution on goals: the checker can only judge what Claude has shown in the conversation, so write the finish line as something its own output can prove ("the test command exits clean"), and cap it ("or stop after 20 turns") so it cannot run forever.

Where you'll see it

• What a dynamic workflow actually is: dynamic workflows in Claude Code.
• The CEO deep dive on workflows, with real use cases and the cost math: making AI argue with itself before it answers you.
• Both are gears in your harness, the setup that lets an agent run real work for you.
• To run a goal unattended on a schedule with your laptop closed: Claude Code routines.
• The repeatable jobs worth encoding first: make a skill in Claude Code.

What you should do next

Take the next real job on your desk and ask the one question before you type: do I need to go wide, or keep going? Then reach for the matching tool.