What it is.
A subagent is a file describing one worker: what it does, which tools it may use, and which model it runs on. You choose the scope, so a subagent can be personal to you or shared with a project.
The value for marketing work is separation. A research subagent that only reads, a drafting subagent that only writes, and a checking subagent that verifies claims each stay small enough to behave predictably.
You also control capabilities per subagent, which is how you stop a drafting worker from touching anything it should not.
What you get.
- Named subagents, each with its own instructions and tool permissions.
- A model choice per subagent, so cheap work runs on a cheap model.
- Project or personal scope, so a team can share the same set.
- Capability limits per subagent, which keeps a writer from editing files.
- Parallel work on one task, split across focused workers.
How to set it up.
Write down the task as separate jobs before creating anything, since the split is the whole design.
Create one subagent per job and describe what it does and when to use it.
Choose the scope, with project scope when the team should share it.
Limit each subagent's tools to what its job needs.
Pick the model per subagent, keeping the expensive one for the hardest step.
Test each subagent alone before chaining them, because a bad handoff is hard to debug in a chain.
Use cases
Split research from writing
Give each subagent its own instructions and let them work in sequence.
Add a checker
Point one subagent at verification so the writer is not reviewing itself.
Spend the model budget wisely
Use a cheaper model on the mechanical steps and keep the expensive one for judgment.
Best for
Research then write then check
Three jobs with different tools and standards, which is exactly what one prompt handles badly.
Cost control
A cheap model can do extraction while the expensive one only handles judgment.
Shared team setups
Project scope means everyone delegates to the same workers.