# Subagents: when to split a marketing task across several agents

**Author:** John Morabito (Founder, /winston)
**Published:** September 20, 2026
**Reading time:** 10 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/claude-subagents-for-marketing-teams/

Running five agents at once is the most impressive-looking thing you can do with an agent framework, and it is also the easiest thing to do for no reason. Five agents reads as five times the work. Often it is one agent's worth of work, paid for five times, with a merge problem waiting at the end of it.

Whether parallel agents are possible stopped being interesting a while ago. The question we have to answer every time is which tasks survive being split. Some do, cleanly. Most of the ones people reach for first do not, and the failure is quiet: five plausible answers that do not fit together, and the person who has to reconcile them is you.

This is how we decide, on the work we run here.

## What a subagent is

A subagent is a separate context that gets one job, does it, and reports back.

The main thread writes a brief, hands it over, and receives a report. It does not see what the subagent read, which pages turned out to be useless, what it tried first, or what it decided to ignore. It sees the answer.

The closest ordinary version is a contractor who does not sit in your office. Everything they need has to be in the brief, because they cannot lean over and ask. Everything they worked out and did not write down leaves with them when the job ends. Both halves of that are true of a subagent, and both matter more than people expect going in.

## Context isolation is the benefit and the bill

There is one mechanism at work here, and the case for splitting and the case against it are the same sentence read from two directions.

Read forward, it is the reason to do this at all. A broad research sweep fills a context with fetched pages, dead ends, and documents that turned out to be about something else. Run that in your main thread and the useful conclusion arrives buried in the wreckage that produced it, and every task you do afterwards happens in a thread still carrying all of it. Hand the sweep to a subagent and the conclusion comes back on its own. The wreckage stays with the agent that made it.

Read backward, it is the reason most splits fail. Whatever the subagent worked out and did not put in the report is gone. It cannot notice the thing you said forty minutes ago, because it was never there for it. It cannot stop halfway and ask which of two readings of the brief you meant. If the part that makes a task hard is knowing what has already been decided and why, isolation removes exactly what you needed.

So the question is never whether something can be parallelized. It is whether the work needs the context that splitting takes away.

## The tasks that survive a split

Three shapes come up often enough in marketing work to be worth naming.

**Breadth-first sweeps.** Reading forty competitor pages, or a category's worth of search results, or every post on your own site tagged a certain way. Each read is independent of every other read, so nothing agent three finds changes what agent seven should be doing. The output is a pile of small findings you were going to have to read anyway, and the only thing you give up by farming it out is the intermediate mess, which you never wanted.

**One checklist against many items.** A few hundred pages checked for the same handful of problems: a title and an H1 that disagree, schema that does not parse, orphans, thin or duplicated body copy. The judgment here is not in the agents at all. It is in the checklist, which you wrote once, in advance. Consistency across the run is a feature rather than a risk, and it is easier to get from ten agents reading the same checklist than from one thread getting gradually looser about it over two hundred pages.

**Several deliverables that are one task only because of the calendar.** Four drafts from four approved briefs. Nothing is being divided. Four separate pieces of work landed in the same week, and the agent framework runs them at the same time.

The pattern under all three is the same: the work was already separable before any agent touched it. Splitting a task across agents does not make it separable. It only reveals whether it was.

## The tasks that get worse

Two failure shapes, and between them they cover almost every split we have regretted.

**The second step needs the first step's judgment.** Keyword research, then a brief, then a draft. It is tempting to see three jobs and hand out three agents. But the brief is a set of decisions made about what the research turned up, and a brief agent that starts before the research is done writes a brief for an article that does not match what was found. The usual repair is to run them in order instead, which is a single thread with extra handoffs, and lossy ones, since each agent receives only what the last one thought to write down.

**The agents have to agree on something.** Five agents writing five sections of one report will each pick a slightly different emphasis, a slightly different definition of the thing being measured, and a different number to lead with. Every version is defensible on its own. None of them agree. Putting them together is not editing, it is making the shared decision nobody made up front, and it reliably costs more than writing the report once would have.

There is a third case that is less about mechanics than about honesty. When the hard part of a job is taste, a split does not help: positioning, or what to say to a client whose situation does not resemble the last five, or which of two strategies to recommend. Dividing a hard judgment among five agents does not produce a better judgment. It produces five of them, and you still have to make the call.

**The test before you split.** Could you hand each piece to a different freelancer who has never spoken to the others, and would you accept what came back? If the honest answer is that you would want them on a call together first, keep it in one thread.

## Writing a brief that comes back as an answer

The most common way a split goes wrong is not a wrong answer. It is a file dump. The subagent goes off, reads everything, and returns a careful summary of everything it read, so now you read all of it a second time in compressed form. That is not delegation. It is reading with extra steps.

Almost always the brief caused it. A brief for a subagent has to survive being read by something that cannot ask a follow-up question, which means carrying things a request to a colleague would leave implied.

- **Name the decision, not the topic.** "Find out whether any of these five competitors has a page targeting this term, so we can decide whether to build one" has a stopping point in it. "Research competitor content for this term" does not, and an agent with no stopping point keeps going until it runs out of room.
- **Specify the shape of the report.** Three findings at most, one sentence each, with the URL. Or a table with these four columns and one row per page. Or a yes, a no, and the reason. Vagueness here is where dumps come from.
- **Say what not to send back.** "Do not list the pages that passed" is one line and it removes most of the volume. Agents are thorough by default, and thoroughness with no bar set looks exactly like a dump.
- **Hand over the context it cannot reach.** Which client, which constraint, what you already ruled out last week. None of that was in the conversation your request came out of, and the agent has no way to go looking for it.
- **Give it a stop condition.** Enough sources, enough pages, enough attempts, then report what you have, including the part you could not finish.

The report is the deliverable, not the work behind it. An agent that did excellent work and reported it badly has produced nothing you can use, and from the outside you cannot tell that case apart from an agent that did nothing much.

Once you have written the same brief three times it has stopped being a brief and become a procedure, and it belongs in a file rather than in your head or your scrollback. That is where this joins up with [Claude Skills for SEO teams](https://www.winstondigitalmarketing.com/playbooks/claude-skills-for-seo-teams/), which is the same move applied to the instructions instead of the run. If what every one of your agents needs is the same live data, your analytics, your search console, your CMS, then the thing to fix is access rather than the brief, and that is [MCP servers for marketing teams](https://www.winstondigitalmarketing.com/playbooks/mcp-servers-for-marketing-teams/).

## The review step that stays human

A second agent can check the mechanical things, and should. Does the JSON parse, does every claim have a source attached, did anything on the banned list get through, do the numbers in the summary match the numbers in the table. Those are checks, and checks are exactly the kind of work that survives being split.

What a reviewing agent cannot do is notice that a finding is correct and irrelevant. That the audit flagged forty real problems and the one that mattered is not among them. That the draft is accurate and tells the client nothing they did not already believe. Nobody has made that step cheap, and splitting the work does not remove it.

Parallel work makes the review harder in a specific way, too. Every subagent reports in the same steady, confident register whether it found something solid or reconstructed it from two thin pages, and the report does not show you which. In a single thread you at least watched it happen. Then five outputs arrive at once, all of them reading as finished, which is the exact moment people skim. The throughput you gained is real, and it lands squarely on the one step you cannot hand off.

That is the same division of labor that holds everywhere else in this kind of work: the machine takes the volume, a person holds the quality. If you are running as a team of one, the prior question is whether you have repeatable workflows at all, which is [AI workflows for a one-person marketing team](https://www.winstondigitalmarketing.com/playbooks/ai-workflows-for-a-one-person-marketing-team/).

## What it costs

Nobody should hand you a ratio here, so here is the mechanism instead.

You pay for the brief once per agent. Context a single thread establishes once and then reuses for the rest of the session gets established again for every agent you start. You pay for each report twice, once when the agent writes it and once when the main thread reads it. And you pay for whatever work gets done twice because two agents independently decided the same background question was worth answering.

Against that, the main thread stays small. A single thread running the same sweep carries every page it read for the remainder of the session, so every later task in that session is more expensive and, past a certain point, worse. Several agents reading at once also finish in roughly the time the slowest one takes rather than the sum.

Which gives a rule of thumb rather than a number. A genuinely parallel job split across agents usually costs more total tokens, takes less wall-clock time, and leaves you a cleaner thread to keep working in. A job that was never parallel and got split anyway costs more of all three, and then there is a merge. The whole discipline is telling those two apart before you start.

## Where to start

1. Take a job you already run that is slow because it is wide rather than because it is hard. A crawl to review, a competitor set to read, a backlog to check.
2. Write the checklist or the question as if you were sending it to someone who cannot reach you.
3. Say what the report has to look like, including how long it is allowed to be and what to leave out of it.
4. Run it on five items first, in one agent, and read what comes back. If the report is not usable at five, more agents only produce more of it.
5. Then widen it. Keep the review on yourself, and keep it on the findings rather than on the process that produced them.

Every split we run in production came out of a job that was already being done and had already got too wide to do by hand. None of them came from looking at an agent framework and asking what could be parallelized. That order matters more than any of the mechanics above. Building the workflows first and putting agents where the width actually is, is the work behind our [AI marketing service](https://www.winstondigitalmarketing.com/services/ai-marketing/).

## Frequently asked questions

### What is a Claude subagent?

A subagent is a separate context that receives one job, does it, and reports back. It does not share the main thread's history, so it starts from whatever the brief hands it, and the main thread never sees what the subagent read or tried. It sees the report. That isolation is the whole mechanism: the main thread stays clean because the work happened somewhere else, and the subagent works blind because everything it was not told is unavailable to it. Running several at once is the parallel case people usually mean, and it is the same mechanism repeated rather than a different feature.

### When should you split a marketing task across several agents?

When the pieces were already independent before any agent touched them. Three shapes qualify most often: a breadth-first sweep where each item is read on its own, like forty competitor pages or a category of search results; the same checklist run against many items, like auditing a few hundred pages for the same handful of problems; and several deliverables that are one task only because they landed in the same week, like four drafts from four approved briefs. The test is whether you could hand each piece to a different freelancer who has never spoken to the others and accept what comes back. Splitting does not make work separable. It reveals whether it already was.

### When do subagents make the work worse?

In two cases. The first is when a later step needs judgment produced by an earlier one, like a brief that depends on what the research actually found. Run those in parallel and the later agent works from a guess. Run them in sequence and you have rebuilt a single thread with a lossy handoff between every step. The second is when the agents have to agree on something. Five agents writing five sections of one report each pick their own emphasis, their own definition, and their own number to lead with, and every version is defensible. Reconciling them is not editing, it is making the decision you skipped, and it usually costs more than writing the thing once.

### How do you write a brief for a subagent?

Write it for someone who cannot ask you a follow-up question. Name the decision the answer feeds rather than the topic, because an agent told to research a topic will research it until it runs out of room. Specify the shape of the report, down to how many findings and which columns. Say what not to send back, since most file dumps are an agent being thorough where nobody set a bar. Include the context it has no way to reach, because it was not present for the conversation your request came out of. Give it a stop condition. The report is the deliverable, and an agent that did careful work and reported it badly has produced nothing you can use.

### Do subagents cost more tokens than doing the work in one thread?

For the same work, usually yes. Context a single thread establishes once gets established again for every agent, and every report is paid for twice, once when the agent writes it and once when the main thread reads it. What you buy is wall-clock time and a main thread that is not carrying the debris of the research that produced the answer, which compounds, because everything you do after a long sweep in one thread happens in a context full of pages you have already finished with. Anyone quoting you a fixed ratio is guessing. It depends on the length of the brief, how much each agent reads, and how much of the output you keep.