Subagents

Split big jobs across focused helpers.

Some jobs want a team. A subagent is a helper your main agent spins up to handle a piece of work on its own: one explores your project while another writes the new feature, side by side, then both report back. The work parallelizes; you wait less.

But speed isn't the deep reason subagents exist. Remember the context window: everything the main agent reads crowds its memory. A subagent gets its own fresh context, so it can go read thirty files, digest them, and send back a three-line summary. The main agent gets the conclusion without the clutter. Skills say how to do work; subagents also control who does it, with which model and which tools.

Defining one looks a lot like defining a skill: a file where the header carries the settings and the body carries the instructions.

---
name: security-checker
description: Reviews changes for exposed secrets and missing access rules   (always loaded)
model: haiku
tools: read-only
---

You are a security reviewer.
Check for hardcoded keys, missing RLS policies,
and anything secret reaching the browser.
Report findings as a short list…

Two settings to notice. Read-only tools mean this helper can look but never touch, so it's safe to send anywhere. And model lets each helper run a different brain: cheap-and-fast for grunt work, heavyweight for the hard part. (Same economics as Foundations, applied per-helper.)

You won't need subagents for a landing page. You'll be glad they exist the first time a task sprawls (“audit every page for broken links,” “add dark mode across the whole site”), when one agent splitting the work across four helpers turns an afternoon into a coffee break. The Agentic workflows chapters, next, take this idea all the way.

AI Clubhouse · Vibe Coding Guide