Delegate in parallel: subagents

What is a subagent?

A subagent is a separate process that handles a task independently. It's the closest analogy to an "AI employee": you hand it a well-scoped mission, it works on its own with the context and tools it needs, then brings you back the result. The main agent — the one you're conversing with — becomes a conductor: it splits the work, delegates, and assembles the results.

Your main /post skill will delegate to subagents and collect their results. Since they run in parallel, independent tasks (publishing to 4 platforms) happen simultaneously instead of one at a time. That's this chapter's change of scale: we go from an assistant that does things fast to a system that does several things at the same time.

The real superpower: isolated context

The time saving is the visible benefit, but there's a second one, subtler and just as valuable: each subagent works inside its own context window. Remember chapter 2: noise degrades answers. When a subagent adapts your post for Instagram, it loads the Instagram rules, the Instagram samples, runs its drafts — and none of that volume pollutes the main conversation. The main agent only receives the final, clean result.

Without subagents, publishing to 4 platforms would fill your context window with four times all that intermediate work, and the session would become confused well before the end. With them, your main conversation stays a readable logbook: mission, delegation, results. That's why subagents are useful even for bulky sequential tasks — exploring a big codebase, analyzing ten documents — not just for parallelism.

Defining specialized subagents (optional but powerful)

Claude Code can spin up generic subagents on the fly — that's what your skill will do. But you can also define named, specialized subagents, with the /agents command or by creating files in .claude/agents/. Each file describes a role: its name, its description (which Claude uses to know when to call on it), the tools it's allowed, and its system prompt.

---
name: instagram-writer
description: Adapts content to the Instagram format (caption + hashtags) in the brand voice. Use for any Instagram publication.
tools: Read, Write, Bash
---

You are the brand's Instagram specialist.
You read brand-voice.md before writing anything.
Format: strong hook, airy caption, 3 to 5 hashtags at the end.
You never publish without an attached media.

The value of specialization: an "Instagram writer" subagent with a precise role and restricted tools is more reliable than a generalist, exactly like in a human team. And restricting its tools (no network access for a proofreader, for example) is a free security measure. For Lea's project, the skill with on-the-fly subagents is enough — but keep this card in mind for your more ambitious systems.

Skill, hook, subagent: who does what?

At this point in the course, you have three extension mechanisms. From a distance they look alike, but each answers a different question — and confusing them is the most common beginner mistake:

The three combine naturally: the skill describes the procedure, which delegates to subagents, each of whose actions passes under the hooks. That's exactly the architecture of Lea's system.

Taking the skill multi-platform

update the /post skill to support "all":
/post "topic" all

when the platform is "all":
- create the visual only once
- launch one subagent per platform (twitter, linkedin, instagram, facebook)
- each subagent adapts the text to the platform's format, limits, and voice
- all publish in parallel
- log all the results

Note the detail "create the visual only once": that's an architecture choice. Generating the visual is expensive and the result is shared — so it stays in the main agent, before delegation. Only the genuinely independent work (adapting the text, publishing, logging) goes parallel. Identifying what's shared and what's independent is the heart of designing a parallel system.

Then run: /post "our zero-waste commitments" all. Claude creates one visual, writes the variants in your voice, asks for your approval, then launches the subagents. You'll see several task blocks executing simultaneously in the interface — that's your team at work.

flowchart TD
  M["/post topic all"] --> V["Visual created only once"]
  V --> S1["Twitter subagent"]
  V --> S2["LinkedIn subagent"]
  V --> S3["Instagram subagent"]
  V --> S4["Facebook subagent"]
  S1 --> J["Log + URLs"]
  S2 --> J
  S3 --> J
  S4 --> J

Why not sequentially?

Each publication is asynchronous: Claude sends the post then polls the API every few seconds until the status reads "published" (5 to 30s depending on the platform). 4 posts in series = up to 2 minutes of cumulative waiting, during which nothing useful happens. 4 subagents in parallel = one single wait, the slowest one's.

Each subagent manages its own async cycle: send, poll, process the response, log. Writing the variants and the approval, however, stay in the main agent — you approve once, then everything goes out in parallel. And if one subagent fails (API down, quota exceeded), the other three finish normally: you only retry the failed platform, not the whole batch.

The limits of parallelism

The "parallelize everything" reflex would be a mistake. Parallelism has a cost: each subagent consumes its own tokens, and orchestration carries its own complexity. It's only worth it if the tasks are genuinely independent (none needs another's result) and long enough for the cumulative waiting to matter. Adapting four posts: perfect. Three steps where each depends on the previous one (research → write → publish): no parallelization possible, it's a chain.

The good test: draw your flow like the diagram above. Branches that leave the same node and never touch again are parallelizable; anything chained vertically isn't. Two minutes of sketching saves hours of needlessly complex architecture.