Dynamic Workflows vs. Skills vs. Sub-Agents in Claude Code: When to Use What 

Claude Code's architecture now spans four distinct layers: reusable skills, specialist sub-agents, coordinating agent teams, and massively parallel dynamic workflows. Each exists for a different reason, and understanding when to deploy which isn't a technical curiosity. It's a margin question.

Skills are your lightest-weight layer. They're essentially prompt recipes: structured instructions Claude reads at runtime to execute a repeatable task the same way every time. Skills don't spin up separate agents or fork sessions. They live inside a single conversation and guide behavior, think of them as callable procedures. A "LinkedIn post" skill might specify tone, structure, and CTA format. Skills are token-cheap because they're instructions, not independent execution contexts. If a task is repeatable and narrow, a skill is usually the right call.

Sub-agents are specialist agents Claude spins up *within* a session to handle focused, discrete work. A sub-agent might research a topic, draft a document, or analyze a dataset, tasks that benefit from a contained scope and their own execution loop. Sub-agents can use skills, access tools, and reason independently, but they report back to the parent session. You're still in one conversation; the sub-agent is a subroutine with agency. Token cost rises because you're running a second reasoning loop, but it's bounded.

Agent teams coordinate multiple agents that *can talk to each other*. One agent might handle research, another writes copy, a third edits. They share context, hand off work, and synthesize results. This is where you start to see serious token burn, multiple agents reasoning in parallel or sequence, each with their own context window. Agent teams shine when tasks require genuine division of labor and the value of specialization outweighs the overhead.

Dynamic workflows are the newest and most powerful layer, and the most expensive. A dynamic workflow can spin up dozens of agents in parallel, each working independently on a slice of the problem, then funnel results into a synthesis agent. In one documented test: analyzing 41 skills by spinning up 41 Haiku scoring agents in parallel, then feeding outputs to an Opus synthesis agent consumed 5 million input tokens and half a $200 monthly subscription in 30 minutes. Dynamic workflows deliver results that would take a human team days, but they're token-intensive by design. The strategic question isn't "is this powerful?", it obviously is. The question is "does the value justify the burn rate?"

When to Use What

Use a skill when the task is repeatable, narrow, and doesn't require independent reasoning. Examples: formatting output, pulling structured data, applying a consistent editorial voice. Skills are your highest-leverage, lowest-cost tool.

Use a sub-agent when the task is discrete but complex, research, analysis, document generation. The work is self-contained, but it benefits from a reasoning loop. Token cost is moderate; value is high when the task would otherwise clutter your main session.

Use an agent team when the problem genuinely benefits from specialization and handoffs, when one agent's output becomes another's input, and coordination beats monolithic execution. Token cost is significant; justify it with output quality or speed gains.

Use a dynamic workflow when you need massive parallelization and the value of speed or comprehensiveness justifies the token spend. Examples: analyzing hundreds of documents, scoring dozens of artifacts, synthesizing research at scale. This is your high-burn, high-reward option. It's not appropriate for routine work.

Why This Matters for Margin Structure

Architecture choice directly impacts unit economics. A workflow that could run as a skill costs 50x more as a dynamic workflow. That's not a rounding error. It's the difference between a profitable automation and one that hemorrhages margin. The pattern we're seeing: teams prototype with workflows because they're powerful and impressive, then wonder why client economics don't pencil. The fix isn't better pricing; it's architectural discipline.

The flip side: underbuilding is also expensive. Running 40 tasks sequentially when a dynamic workflow could parallelize them costs time, and time is often worth more than tokens. The trick is knowing which cost you're optimizing for.

The architectural trap most teams hit: they start with a dynamic workflow for a demo, the client loves it, then production usage reveals the token burn. Re-architecting to skills or sub-agents after launch means rewriting integrations, retraining the system on new patterns, and explaining to a client why their "working" automation suddenly needs changes. The correct sequence is the opposite: start with the lightest layer that solves the problem, then upgrade only when value justifies cost.

The really interesting part: you can compose these layers. A dynamic workflow can invoke sub-agents, which execute skills. The system is modular. But modularity without discipline just means more ways to overspend.

---

Markedeen builds agentic systems for teams that need architecture decisions grounded in margin reality, not demo appeal. If your automations are burning tokens faster than they're creating value, let's talk.