Claude Code has accumulated so many features with similar names that it's easy to reach for the wrong one — and for the most expensive one at that. Skills, sub-agents, agent teams, /goal, and since the Opus 4.8 launch, dynamic workflows as well. They sound interchangeable, they work entirely differently, and the gap between them is the gap between a fix worth pennies and a bill that eats half your monthly allowance in a single command. I'll show you what each of these is in plain terms and — more importantly — when to reach for which.
Skill, sub-agent, agent team — what's actually alike here
Let me start with the three terms that get mixed up most often. All three are about how many Claudes work on a task and whether they talk to each other — and that's exactly what tells them apart.
A skill is a reusable recipe. It's a saved process that you can run yourself in a conversation with Claude, or hand to an agent to carry out. If you run the same sequence of steps over and over, you wrap it in a skill and from then on call it with a single command. A skill isn't a separate "worker" — it's an instruction that someone uses.
A sub-agent is a parallel helper with its own, clean context. Context is the model's field of vision — everything it has "in mind" at a given moment. You fire off a sub-agent when you want to do something alongside the main conversation without cluttering it. Sometimes Claude launches one itself, sometimes you call it, and sometimes you build your own agent file and summon it by hand. The key point: sub-agents don't talk to each other. Each works in its own lane and reports its result back to your main session — not to other sub-agents.
An agent team is a small crew that talks. Here the agents share a task list, have individual roles, their own tools and specializations — and they exchange with one another. This lets you build something like a "war room" or a council, where agents debate and reach the goal together. You pay for that conversation: every exchange between agents is more tokens, so a team is markedly more expensive than individual sub-agents. (A token is the smallest unit of text the model processes — and the bill is counted in them.)
A common mistake I see: someone builds an agent team for a task that breaks down into independent pieces and doesn't require the agents to talk at all. They end up paying for a conversation that adds nothing.
/goal versus workflow — depth versus breadth
Now the two features that are hardest to tell apart, because both can work for a long time on their own. The simplest way to think about them is as depth and breadth.
/goal is a loop. One agent (or a few) takes pass after pass at the same task, again and again, until it meets a completion criterion — the model keeps asking itself "is done really done yet?" That's depth: the same goal, many passes, all the way to the finish. A loop like this can run for hours, in theory even a full day, if the criterion is hard to meet.
A dynamic workflow is breadth. Instead of a single loop, Claude writes a JavaScript script that fires off many independent sub-agents — there might be a few dozen, there might be a few hundred. Each works alone, in its own lane, on its slice. Nobody keeps checking "is it done?" — they all carry out a plan set at the very start, and at the end the results combine into a single whole and return to the main session. Here's the important difference from ordinary sub-agents: the plan no longer sits with Claude but in that saved script. That means you can keep a workflow and run it again whenever you like.
The image worth remembering: it's a ladder of rising power, cost and risk. At the very bottom is an ordinary conversation with Claude. Higher up, a skill. Higher still, a sub-agent. Then an agent team. Then /goal. And at the top, a dynamic workflow. The higher you go, the more you can do with a single command — and the more you can burn through along the way.
The whole ladder on one slide:
- A quick thing → just ask Claude.
- A process you repeat → make a skill.
- A tedious side task → hand it to a sub-agent.
- A small crew that has to coordinate → an agent team.
- Has to run until it meets a criterion →
/goal. - A big task to parallelize → a dynamic workflow.
When a workflow really pays off — and when it's overkill
I have one question that settles the matter faster than the whole ladder above: does this task break into many pieces that can run independently, at the same time? If yes — consider a workflow. If not — you almost certainly don't need one.
Two tasks that a workflow fits really well: reviewing every file in a codebase or migrating four hundred files at once. The stakes are high, there are many pieces, and each can get its own lane and the full attention of a separate agent. These are exactly the situations where splitting the work across dozens of parallel agents genuinely buys you something.
In my view it's also worth saying honestly when it's not worth it. Single fixes, short questions, general knowledge work, pushing toward one specific result — here a workflow is overkill. The word "workflow" itself doesn't mean you have to use it every day to keep from falling behind. It's good to know what a feature does and when it comes in handy — but that's not the same as being obliged to use it for everything. The question is always: does this solve a problem you actually have right now?
Cost and safety — how it works under the hood
Here you have to be honest about the mechanism, because it explains where the big bills come from. Each agent is a full call to Claude — it has its own context to read, and many of them fire at once. That means the use of input tokens (what the agents read in) can spike sharply. Fortunately the output tokens, what the agents write out, are usually much smaller and cheaper — so a workflow can be token-intensive without always being proportionally expensive.
The scale is real: one overly broad prompt can swallow a sizable chunk of your monthly limit and run for tens of minutes. A classic example of such an uncontrolled task is turning agents loose to search your entire desktop and all your local repositories for some analysis — the scope is bounded by nothing, so tokens vanish wholesale. Hence three rules I apply before I fire off anything broad:
- Limit the scope. Say exactly where the agents should look, and where they shouldn't.
- Name a specific result. The more precisely you describe what you want, the less wasted work. (The same logic applies to
/goal— a vague instruction can loop for a long time, because the agent doesn't know when "done" is really done.) - Put the workers on Haiku. Haiku is the fastest and cheapest of the Claude models — just right for many small, parallel tasks.
There's also good news on the safety side: a workflow never fires by accident. Claude asks for confirmation first, and before anything starts you can look over the raw script that's about to run. While it's running, the /workflows command shows all the active runs — you see how many agents are working, on which model, how many tokens they've used and how long they've been going — and that's also where you can stop them.
Details that are easy to miss
A few things worth knowing before you try it yourself.
Where workflows get saved. By default the script may land in a global location, somewhere outside your project. If you want it close at hand in the repository, tell Claude explicitly to save it in .claude/workflows inside the project — otherwise you'll be hunting for it later.
A skill fits inside a workflow. Skills and workflows aren't rivals — they complement each other. A skill says how to do something; a workflow decides on how many fronts and how broadly to do it. Since a workflow fires off sub-agents, and sub-agents can read and use your skills, a skill nests neatly inside.
/deep research is a ready-made workflow. This feature runs a workflow under the hood: it fires off many agents for parallel research, has them vote on each claim, and at the end you get a report with footnotes. If you do a lot of source-hunting, it's a good way to see a workflow in action without building anything from scratch.
ultracode is the maxed-out mode. In the model's effort-level settings you have low, medium, high, very high and maximum. Separately there's ultracode — the smartest and most expensive: it combines a very high level of reasoning with workflows on by default. In this mode Claude skips some of the usual permission questions and starts orchestrating right away, so treat it as a tool for a deliberate, costly exception, not for everyday work.
This whole family of features comes down to one decision: don't ask which is the most powerful, ask which fits the problem in front of you today. Power without a bounded scope isn't an advantage — it's a bill. Next time you feel the urge to fire off something big, ask yourself that one question about independent pieces and name the result before you hit "run."