- 1. Skill: the reusable recipe
- 2. Sub-agent: the isolated worker
- 3. Agent Team: the crew that talks
- 4. Dynamic Workflow: the giant parallel job
- Side-by-side comparison
- Decision cheat sheet
/goal,/loop, and/schedule- Six dynamic workflow patterns, with ready-to-use prompts
Claude Code has four distinct ways to delegate work beyond just talking to your main session: Skills, Sub-agents, Agent Teams, and Dynamic Workflows. They all feel similar on the surface ("get more agents involved"), but each answers a different question:
| Pattern | Answers the question |
|---|---|
| Skill | "How do I make this reusable?" |
| Sub-agent | "How do I keep a messy side task out of my main context?" |
| Agent Team | "How do I get several specialists talking to each other?" |
| Dynamic Workflow | "How do I run this at massive parallel width?" |
The core thing that changes as you move through them: how many agents are in the loop, and whether they can talk to each other.
Note
This is a ladder, not a menu. Complexity, capability, cost, and risk all climb together as you move right. Reach for the cheapest rung that solves your actual problem. One workflow prompt burned through half of a $200/month subscription in about 30 minutes by crawling an entire desktop's worth of files.
A skill is the "how." It's a saved procedure Claude can run whenever the task matches, without you re-explaining it every time.
- Where it can run: directly in your session, inside automation, invoked by a sub-agent, invoked by an agent within a team, or nested inside a dynamic workflow.
- Cost and risk: lowest. It's just instructions, no extra agent, no extra context window.
- Use it when: you keep doing the same thing and want it codified once and reused.
"A skill is a reusable recipe... you can run these skills, you can have these skills be in automation, and you can also have a sub agent execute a skill, or a sub agent within an agent team execute a skill, and of course, you can have workflows execute these skills as well."
A sub-agent is a parallel agent with its own context window, spun up to do a side task without cluttering your main session.
| Property | Behaviour |
|---|---|
| Context window | Its own. Separate from the main session, keeps the main session clean. |
| Talks to other sub-agents? | No. Reports only back to the main working session. |
| How it's invoked | Auto-spun-up sometimes, manually requested sometimes, or via your own hand-built agent files. |
| Count | Usually one, unless you explicitly spin up multiple in parallel. |
- Use it when: you have a messy side task (a search, an exploration, a "go dig through this") that would otherwise pollute your main conversation's context.
"These are basically just parallel agents that don't have the same context window as the main session... There's one of them unless you spin up multiple, but they cannot talk to each other. They only talk back to the main working session that you are talking to."
Example: investigate without polluting your main context
When to use: you need an answer to a research question mid-task, but reading every file it takes to get there isn't worth keeping in your main conversation.
Why it works: the sub-agent's exploration, every file it opens, every dead end, happens in its own context window. Only its final summary comes back to you.
Use a subagent to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse
before I build a new Google OAuth flow. Report back just the relevant files,
functions, and a one paragraph summary of the current flow.
Example: get a second opinion before calling it done
When to use: you just implemented something yourself and want a check that isn't biased toward the reasoning that produced it.
Why it works: a fresh subagent sees only the diff and the criteria you give it, not the back and forth that led to it, so it evaluates the result on its own terms instead of rubber-stamping your work.
Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.
An agent team is a small crew of agents that do talk to each other. They share a task list, and each has individual roles, tools, and specializations. Think "group chat," not "one-off errand."
| Property | Behaviour |
|---|---|
| Context window | Each agent has its own. |
| Talks to other agents? | Yes. This is the whole point. |
| Roles | Individual roles, tools, and specializations per agent. |
| Good for | "War rooms," councils, debate, collaborative work toward one end goal. |
| Cost | Higher than a lone sub-agent: multiple agents, plus the coordination overhead of them talking. |
- Use it when: you want specialists to deliberate: debate an approach, cross-check each other, or run a genuine "council" rather than a single agent working alone.
"Agent teams are kind of like a small crew, and these are also pretty expensive because they do talk to each other, and they can share like a task list... That's really cool to have things like war rooms and councils and opportunities for agents to debate and work on an end goal together."
Example: run a council instead of a monologue
When to use: a real decision needs to be argued out, not split into independent pieces. The disagreement between specialists is the value, not overhead to eliminate.
Why it works: because they share a task list and can see each other's contributions, the critic can actually challenge the researcher's findings before the writer commits to a conclusion. The debate closes within the team instead of bouncing back to you.
Set up an agent team to decide our approach for migrating the payments service.
Give one agent the researcher role: pull the current architecture and past
incident history. Give another the critic role: challenge every proposal the
researcher raises and flag the failure modes it doesn't cover. Give the third
the writer role: once the researcher and critic have gone back and forth,
write the final migration plan to MIGRATION_PLAN.md, citing which concerns
were addressed and which were explicitly deprioritized and why.
A dynamic workflow is Claude Code writing and executing a JavaScript file that spins up and delegates to many agents, potentially hundreds, each working alone. Results merge and synthesize back to the main session at the end.
The key structural difference from every other pattern: the plan doesn't live with Claude anymore. It lives in the generated script. With sub-agents and agent teams, "the whole plan is right there with Claude." With a workflow, Claude authors a script, and that script is what actually executes and orchestrates.
- Saveable and reusable. Workflows get written to a
workflowsfolder and can be re-run later. By default they may save somewhere global rather than in your project. Tell Claude explicitly to save into.claude/workflowsif you want it to live with the repo. - Always requires confirmation. It will not run silently. Claude asks "can I run this dynamic workflow?" and you have to say yes explicitly. You can also inspect the raw generated script before it runs.
/workflowsshows all open workflows: which agents are running, what model they're on, tokens used, tools, and runtime. It also lets you stop any of them.- The "how many," not the "how." "The skill is kind of like the how, the workflow is like the how many." A skill can be, and often is, nested inside a workflow's individual agents.
Tip
Real worked example from the source: auditing 41 skills spun up 41 Haiku scoring agents in parallel, each grading one skill (clarity, front-matter pass/fail, trigger quality, one highest-value fix), then fed everything into one Opus synthesis agent that ranked every skill worst to best. Total: about 5 million input tokens, cheap output, because the workers all ran in parallel on a fast, cheap model.
/goal isn't a fifth rung on this ladder. It's an orthogonal axis. A workflow is width (many agents working horizontally on a plan set from the start). /goal is depth (one loop, checking "does done equal true?", taking as many turns or passes as it needs, potentially 24+ hours).
You can combine them (a workflow nested inside a /goal, or vice versa), but that stacks autonomy on autonomy. It's powerful, and a great way to burn money fast.
| Skill | Sub-agent | Agent Team | Dynamic Workflow | |
|---|---|---|---|---|
| Unit of work | A recipe | One isolated worker | A talking crew | Many isolated workers |
| Own context window? | No (runs in caller's context) | Yes | Yes, each member | Yes, each worker |
| Agents talk to each other? | N/A | ❌ No | ✅ Yes | ❌ No (fan-out/merge only) |
| Who holds the plan? | The caller | The caller | The caller | The generated script |
| Typical count | 1 recipe | 1 (sometimes a few) | A handful | Tens to hundreds |
| Relative cost | 💲 | 💲💲 | 💲💲💲 | 💲💲💲💲 |
| Requires explicit confirmation to run? | No | No | No | ✅ Always |
| Reusable/saveable as a standalone artifact? | ✅ Yes (the skill itself) | Rarely | Rarely | ✅ Yes (.claude/workflows/*.js) |
"So, the question that I would ask is, does this break into many pieces that can run individually of each other at the same time? If that's true, then go ahead and try out a workflow."
MCPs, CLIs, and API endpoints plug into any of these four patterns the same way. The choice above is purely about topology and coordination, not about what data or tools each pattern can reach.
The four patterns above are about who does the work. These three commands are about how long and how autonomously it keeps running. They stack on top of any pattern, including a plain main session.
| Command | Trigger | Stops when | Runs on |
|---|---|---|---|
/goal |
You start it in the current session | The stated condition is met, or a turn cap is hit | Your machine, current session |
/loop |
A fixed time interval | You cancel it, or the machine goes offline | Your machine, local only |
/schedule |
A fixed time interval or an event | You turn it off | Anthropic's cloud, no machine needed |
A loop with one exit condition, checked after every turn by a separate evaluator. Good for tasks where "done" can be stated as a fact, not a feeling.
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
Tip
Deterministic conditions work best: a test count, a score, a "yes/no" that doesn't need judgment. A vague goal just makes the loop run longer without getting closer to done.
Re-runs the same prompt every N minutes, on your machine, for as long as your machine and session stay on.
/loop 5m check my PR, address review comments, and fix failing CI
Good for short, recurring chores tied to something changing on your machine, like a PR you're actively shepherding.
Moves the same idea off your laptop. A fresh cloud environment spins up on a schedule (or on an event, like a GitHub PR opening), runs the task, and tears down. Nothing needs to stay open on your end.
/schedule every hour: check #project-feedback for bug reports.
The real power shows up when you combine them: /schedule decides when to start, /goal decides when to stop, and a dynamic workflow decides how the work gets split up once it starts.
/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged, actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions in parallel worktrees
and have a judge adversarially review them.
Track spend as you go with /usage and /workflows, and don't schedule more often than the thing you're watching actually changes.
Dynamic workflows aren't one thing. They're a JavaScript file, and how you shape it defines what it's good for. These are the six recurring shapes, each solving one specific failure mode you'd hit trying to do the same job in a single conversation. Swap the file paths for your own before running any of these.
When to use: a flood of mixed items that each need a different specialist: support queues, inboxes, routing tasks.
Why it works: quarantining the reading agent stops untrusted ticket text from ever triggering an action directly. It can only classify and summarize, never act.
Build a workflow that triages my support inbox in ./support_tickets by spawning
a classifier agent that reads each ticket and routes it to a bug, refund, lead,
or spam handler, deduping against what is already tracked before any handler
acts. Quarantine the reading agents so the ones touching the untrusted ticket
text can only classify and summarize, never take actions, and hand everything
off to a separate trusted agent that does the actual routing and replies. Pair
it with /loop so it keeps clearing the queue as new tickets land.
When to use: one big job that splits into independent pieces: research, due diligence, reading many files at once.
Why it works: each subagent works in its own clean context, so pieces never cross-contaminate. A barrier step waits for everyone before merging, keeping the synthesis grounded in cited sources.
Build a workflow that does due diligence on the data room in ./data_room by
fanning out one subagent per folder, each in its own clean context so the files
never cross contaminate, and having every agent return a structured summary
with the exact source path for each finding. Then run a barrier synthesize step
that waits for all of them to finish and merges their outputs into one cited
diligence memo at ./diligence_memo.md, where every claim links back to the file
it came from.
When to use: something needs a real check, not a grade from the agent that made it: claims, reports, audits.
Why it works: the agent that extracts a claim is never the one that verifies it, so nothing rubber-stamps its own work. This kills self-preferential bias directly.
Use a workflow to go through my blog post draft in ./draft.md and verify every
factual and technical claim before I ship it. Have one agent extract each claim
into its own item, then for every claim spin off a separate agent that checks
it against the real source in ./codebase and flags any claim that does not hold
up. The agent that verifies a claim must be a different agent from the one that
pulled it so it is not just rubber-stamping its own work. When it is done, give
me back the list of claims that failed and the exact reason each one failed so
I know what to fix before publishing.
When to use: taste-based work where you want the best of many options: titles, headlines, copy.
Why it works: same anti-self-preference logic as verification, applied to creative output. The generator goes fast and loose, a separate judge scores against a rubric.
Use a workflow to brainstorm 40 video title and headline angle options for the
topic in ./topic.md with one generator agent, then hand them all to a separate
judge agent that scores every option against a rubric for hook strength,
clarity, and curiosity, dedupes the near identical phrasings, and returns only
the top 5 winners with a one line reason for each. The generator that
brainstorms and the judge that scores must be different agents so the judge is
not grading its own ideas.
When to use: ranking a big pile by judgment where a 1-10 score would be unreliable: resumes, leads, ticket severity.
Why it works: pairwise comparison beats absolute scoring, and the deterministic bracket keeps only the running order in context instead of every candidate.
Use a workflow to rank every resume in ./resumes for the backend engineer role
by running a tournament of pairwise comparisons against a rubric instead of
scoring each one cold, where each head to head match is its own comparison
agent and the deterministic loop holds the bracket so only the running order
stays in context. Once the bracket settles, spin off fresh agents to
double-check the top ten against that same rubric and flag anyone who ranked
higher than they should have. First interview me with the AskUserQuestion tool
to build the rubric before any comparing starts.
When to use: an unknown amount of work where you don't know how many passes it will take: flaky tests, cleanups.
Why it works: keeps spawning attempts against a real stop condition instead of quitting early after partial progress. This is the direct fix for agentic laziness.
Build a workflow that hunts down a flaky test in ./tests that fails maybe 1 in
50 runs. Keep forming theories about the cause and adversarially testing each
one in its own isolated worktree, looping and spawning new attempts with no
fixed pass count, until the stop condition is met where one theory reproduces
the failure on demand and its fix makes the test pass clean. /goal do not stop
until one theory works and the test is green.
When to use: real work that chains a few patterns into one machine.
Why it works: combines fan-out coverage, adversarial verification, and a real stop condition. Three failure modes closed at once.
Build a workflow that audits every file under ./codebase, fans out one agent
per file, has a separate agent try to refute each finding against the code, and
loops until a clean pass turns up no new issues. Return only the confirmed
issues, each with the file and the exact line. /goal do not stop until a full
clean pass finds no new issues.