Claude Code Subagents for a Content Factory

Claude Code lets you spawn subagents that run in parallel. Used well, this turns a single-threaded session into a small team. Used badly, it burns tokens for output that doesn't match what you'd have written serially.

I run a 30-piece content factory inside Claude Code. Here's the pattern that works.

What "content factory" means

A spec document defines a batch of content pieces — blog posts, guides, landing-page sections, product cards. Each piece has a brief (topic, audience, voice notes, length). The factory produces all of them in one command.

For a 30-piece batch, this is hours of work serially. With subagents, it can be 15-20 minutes wall-clock.

But you have to set it up right or the output is junk.

The dispatch pattern

Step 1: Orchestrator prepares. The main session reads the spec, builds a list of pieces with each one's brief. Verifies the directory structure exists. Reads the voice samples and patterns.

Step 2: Orchestrator dispatches in waves. Not all at once. Waves of 4-6 subagents.

For a 30-piece batch: 6 waves of 5 subagents. Each subagent gets: - Its specific brief - The voice samples (read into the context, not by reference — subagents can't see what the orchestrator read) - Pattern examples (3-5 reference pieces showing the structure) - Specific file path to write to - Explicit instructions on what NOT to do

Step 3: Orchestrator reviews each output. After a wave completes, the orchestrator does a fast pass on each output. Length check. Voice check. Pattern compliance. Anything weird gets re-dispatched with corrections.

Step 4: Final aggregation. Once all 30 are clean, the orchestrator runs any cross-piece verification (no duplicate slugs, consistent terminology, proper internal linking).

The subagent prompt template

This is the structure I use:

``` You are writing one piece in a {batch_type} batch. Your job is exactly one piece. Do NOT exceed scope.

Brief: Slug: {slug} Title: {title} Audience: {audience} Length target: {word_count} Reader benefit: {benefit} Key points to cover: {points}

Voice samples (study these for tone, sentence rhythm, vocabulary): {3-5 verbatim samples}

Banned (this will get flagged in review): - {voice_banned_list, e.g. "leverage", "robust", "seamless"} - Em-dash used to join clauses (LLM tell) - Sentences over 35 words - {any project-specific banned phrases}

Output file: Write to: {file_path} Format: {data file format expected}

Verification steps before you finish: 1. Count words in body. Confirm within ±15% of target. 2. Read the first paragraph aloud (mentally). Does it sound like the voice samples? 3. Check banned list once.

You will NOT review or edit other pieces in this batch. You will NOT dispatch additional subagents. ```

The "you will NOT" lines are essential. Without them, subagents try to be helpful in ways that break the factory.

What burns tokens

Subagents reviewing each other's work. They don't have the context. They'll second-guess each other and rewrite. Disable this explicitly.

Subagents reading the entire spec. They only need their slice. Pass the slice. Skip the rest.

Subagents loading the codebase for context. Most content factories don't need the codebase. If a subagent thinks "let me explore the project structure," tokens are burning.

Recursive dispatch. If a subagent thinks the work is too big and wants to spawn its own subagents, you've lost control. Explicit "do not dispatch additional subagents" line catches this.

What I've shipped this way

A 30-piece blog batch in 18 minutes wall-clock (vs about 5-6 hours serial). The output required about 20% editing time on top.

A 60-card Asana board content pass in 25 minutes wall-clock. Output was about 80% ready as shipped.

A 12-section landing page rewrite in 9 minutes. Output was 60% ready — landing pages have more cross-section coupling so subagents struggled with consistency. I'd do this serially next time.

Where the pattern fails

Heavy cross-piece consistency. Landing pages, integrated essays, anything where piece N depends on what piece N-1 said. Subagents can't see each other's work in flight.

Code that needs to interconnect. Same reason. Each subagent doesn't know what the others are writing.

Highly creative work where you want emergent surprises. The dispatch pattern enforces consistency. That kills the upside of "what if the AI writes something we didn't expect."

What works best

Templated content where structure is enforced. Blog posts in a defined format. Cards with consistent fields. Industry pages following the same scaffolding.

Bulk research and summarization. Subagents each take one source, summarize it, return. Orchestrator aggregates.

Repetitive code generation. Each subagent generates one similar module. Orchestrator wires them together.

The orchestrator's job

The orchestrator is not generating content. The orchestrator is: - Preparing the right context for each subagent - Dispatching in waves - Verifying outputs against the spec - Re-dispatching with corrections - Aggregating the final state

If the orchestrator tries to write content too, it loses focus. Keep the orchestrator narrow.

What I'd tell a new Claude Code user

Don't reach for subagents until you've felt the pain of doing something serially. The dispatch overhead is real. Subagents earn their tokens on batch work where you'd otherwise be context-switching across many similar tasks.

For one-off complex tasks, stay serial. The orchestrator pattern is for production lines, not for craft work.

When you do use it: tight briefs, explicit "do not" lines, waves not all-at-once dispatch, and an orchestrator that reviews before declaring done.

That's the entire pattern. It's mostly discipline. The technology gives you the cars; you still have to drive the assembly line.