Claude Code: Automate with Goals and Dynamic Workflows

TL;DR: Claude Code offers two primitives to move beyond iterative prompting: /goal, which keeps Claude working until a verifiable condition is met, and Dynamic Workflows, which orchestrate up to 1,000 agents via a JavaScript script. Understanding these two approaches, and when to choose one over the other, fundamentally changes how you design automation with Claude.

Every time you send a message to Claude, wait for the response, and send the next one, you are the orchestrator. For short tasks, this works fine. For a 300-file migration or a full security audit, it becomes the bottleneck: you spend more time re-prompting Claude than doing the actual work. Claude Code introduced specific primitives to address this. Understanding them is the shift from a reactive agent to an autonomous one.

Why iterative prompting hits its limits

The basic prompting model is synchronous: you send an instruction, Claude works, you get a result, you send the next. For simple tasks, this cycle takes seconds. For tasks that need 20, 30 or 100 iterations, it becomes expensive in attention and time.

Consider a concrete example: you want Claude to migrate all API routes to a new format, test each change, and iterate until all tests pass. In question-answer mode, you ask, Claude migrates a subset, returns, you send the next batch, and so on. Each return is a context interruption: a moment where you re-assess progress and decide what to ask next. The same problem applies to clearing a ticket backlog, fixing CI failures on a branch, or pushing a Lighthouse score above a threshold. These are tasks with a clear objective and a verifiable end state. They call for automation, not supervision.

Claude Code’s answer organizes around the concept of a loop: an agent that repeats work cycles until a stop condition is met, without waiting for the human between turns. Delba de Oliveira and Michael Segner, in an Anthropic blog post published June 30, 2026, describe four distinct patterns based on the trigger and the stop condition.

What are the four loop patterns in Claude Code?

Type	Trigger	Stop condition	Primitive
Turn-based	User prompt	Claude judges itself	Standard prompt
Goal-based	End of each turn	External evaluator (Haiku) confirms the condition	/goal
Time-based	Time interval	You, or Claude when task is done	/loop, /schedule
Proactive	Event or schedule	Script or orchestration	Dynamic Workflows, cloud routines

 

The two key dimensions are the trigger (who decides to start the next turn) and the stop condition (who decides it is done). These two variables define the actual autonomy level of the agent. For a tech lead, this table is a practical decision grid: if you are interrupting your work to re-prompt Claude, you are in turn-based territory. If you want to step away from that supervision, the next two patterns are Claude Code’s answers.

How does /goal work, and why does the independent evaluator matter?

The principle of /goal is straightforward: you define a condition, Claude works, and after each turn a separate model checks whether the condition holds. If it does not, Claude starts another turn without prompting you.

/goal all tests in test/auth pass and the lint step is clean

As soon as you run this command, Claude starts working. The ◎ /goal active indicator appears with the elapsed time. After each turn, the evaluator Haiku by default in current Claude Code version), returns a verdict with a short reason. That reason appears in the transcript and guides the next turn. If the condition is not met, Claude starts another turn immediately.

The detail that changes everything is the evaluator’s independence. In standard mode, Claude judges itself as done. It naturally tends to declare itself satisfied too early: a well-documented self-serving evaluation bias in large language models. With /goal, evaluation is handled by a model that did not do the work. It cannot be influenced by the effort invested, only by the observable result in the transcript. This separation of roles, between the agent that works and the model that evaluates, is the core functional difference from a standard prompt in Auto mode.

For an effective condition, the documentation recommends three elements: a measurable end state (test result, exit code, file count, empty queue), an explicit check (how Claude proves it is done, such as “npm test exits 0″ or “git status is clean”), and constraints that must not change along the way (such as “no other test file is modified”). The condition can be up to 4,000 characters, leaving room for precise and composite criteria. To prevent long loops, include a stop clause: “or stop after 20 turns”.

/goal is distinct from Auto mode: Auto mode approves tool calls within a turn but does not start a new one. /goal adds an external evaluator that decides whether the work is genuinely done and starts a new turn if it is not. The two are complementary: Auto mode removes intra-turn interruptions, /goal removes inter-turn ones. Available from Claude Code v2.1.139.

What do Dynamic Workflows offer that /goal cannot?

/goal solves turn-by-turn supervision. But even with an active goal, Claude works alone: one agent, one conversation, one context. For a 500-file migration or a full API audit, a single agent becomes the bottleneck. Dynamic Workflows address a different problem: coordination at scale.

The fundamental difference from standard subagents is where the plan lives. With standard subagents, Claude is the orchestrator: it decides turn by turn what to spawn, and every result occupies space in its context window. With a Dynamic Workflow, a JavaScript script holds the loop, the branching, and the intermediate results. Claude receives only the final answer. According to Claude Code documentation, this architecture supports up to 1,000 agents per run with up to 16 agents running concurrently. The script executes in an isolated environment, separate from the conversation, while your session remains fully responsive.

Three composition patterns illustrate what Dynamic Workflows make possible beyond what a single agent can handle: parallelization across a large corpus (each file or endpoint processed by an independent agent), adversarial review (one agent drafts, another critiques before synthesis), and cross-verified multi-source research (each source examined independently, then compared). That last pattern is exactly what the built-in /deep-research workflow does: it takes a question, fans out parallel searches across several angles, cross-checks the sources, and returns a cited report with unverified claims filtered out.

For your own tasks, include the keyword ultracode in your prompt (or ask explicitly “use a workflow”). Claude writes the script for that task. You can also activate /effort ultracode for the entire session: Claude automatically plans a workflow for every substantive task. Once a run produces the expected result, save the script from /workflows with key s. The workflow becomes a reusable command, stored in .claude/workflows/ in the project (shared with the team via git) or in ~/.claude/workflows/ (personal, available across all projects). Available from Claude Code v2.1.154, on all paid plans, as well as on Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.

How do you choose your automation level?

Situation	Solution	Why
Task with a clear verifiable condition (tests, lint, build)	/goal	Independent evaluator, minimal setup, v2.1.139+
Large-scale task requiring dozens to hundreds of agents	Dynamic Workflow	Plan in code, up to 1,000 agents, results outside context
Reducing tool-approval interruptions within a turn	Auto mode	Approves tools in the turn, does not start additional turns
Scheduled recurring task (daily triage, nightly checks)	/loop or /schedule	Time-triggered, independent of an open session

 

A practical approach for introducing these patterns in a team: start with /goal on CI/CD tasks that already have verifiable criteria. This is where conditions write themselves naturally and the benefit is immediate. Move to Dynamic Workflows when the task exceeds what a single agent can handle in reasonable time: large migrations, codebase audits, cross-sourced research.

The two primitives are complementary. A workflow can delegate sub-tasks to agents that themselves run with a goal. And both rely on the same tooling: if you have already connected your servers via the MCP protocol, they are available to all agents in the workflow without additional configuration.

One important caveat: the greater the autonomy, the broader the potential impact of errors. A goal running 20 turns can modify a lot of files before you intervene. A workflow of several hundred agents even more so. AI agent security deserves attention proportional to the level of autonomy granted: environment isolation, permission controls, action monitoring.

FAQ

What is the concrete difference between /goal and Auto mode?

Auto mode automatically approves tool calls within a turn, eliminating interruptions for each action. But it does not start a new turn when Claude finishes: the agent stops. /goal adds an external evaluator that decides whether the work is genuinely done and starts a new turn if not. In practice, the two combine well: Auto mode for intra-turn interruptions, /goal for inter-turn ones.

How many tokens does a Dynamic Workflow consume?

Significantly more than a standard conversation, since each agent is billed independently. Claude Code documentation recommends testing on a subset first (one directory rather than the whole repo, a narrow question rather than a broad one) before a full run. The /workflows view shows each agent’s token usage in real time, and you can stop the run at any point without losing the results of agents that already completed.

Can you reuse a workflow you wrote once?

Yes. From the /workflows view, press s to save the run’s script. Two storage options: .claude/workflows/ in the project (shared with the team via git) or ~/.claude/workflows/ in your home directory (personal, available across all projects). The workflow then becomes a command available via / autocomplete, alongside built-in ones like /deep-research.

Does /goal work in a CI/CD pipeline?

Yes, via non-interactive mode: claude -p "/goal CHANGELOG.md has an entry for every PR merged this week". The loop runs until the condition is met and stops. This is compatible with automated scripts that require no human interaction, which opens useful cases for continuous verification pipelines.

Read the original article: Getting started with loops →

Conclusion

The real question is not “should we automate?” but “at what autonomy level should we delegate this specific task?” /goal and Dynamic Workflows provide two answers to that question, with different tradeoffs in control, cost, and implementation complexity. Since the introduction of Dynamic Workflows with Opus 4.8, the automation spectrum available in Claude Code extends from a single conditional goal to a pipeline of hundreds of orchestrated agents. The shift that matters is the ability to pick the right level for each task, and to combine both when both are relevant.