Lesson 9: Sub-agents and agent teams, running a whole crew by yourself

After this lesson, you'll know how to split work among Claude Code's “sub-employees” running in parallel, know the three sub-agents worth building for every user, understand how the agent teams feature works, and, just as important, know when not to use these flashy things, so you don't waste money.

What a sub-agent is and why it overcomes two built-in weaknesses

A sub-agent is a small Claude session spawned by the main session (the parent agent) to hand off a sub-task. It is born with a clean, separate memory: it only knows the task it was given, returns the result to the parent and disappears. Sounds simple, but that structure addresses exactly the two weaknesses you learned about in lesson 6:

One, no clutter. Any job that means “reading a mountain to pull out a handful” (50 pages of documents, 1,000 rows of data) clutters the desk of your main session if you do it there. Hand it to a sub-agent: it holds that whole mountain in its own memory and sends back only a summary of a few hundred tokens. The parent's desk stays clean.

Two, much cheaper. Sub-agents can run on cheaper models (Sonnet, Haiku) while the parent keeps the premium model. The heavy lifting runs on low-cost soldiers, and only synthesis and decisions use the general. That is the task-splitting principle from lesson 6, now built into a proper structure.

And the biggest payoff: that runs. The email labeling task from lesson 8 took 36 seconds for 100 emails when run sequentially. Split across 10 sub-agents running at once, the original course measured: nearly 1,000 emails done in about a minute. A three-hour sequential job shrinks to about ten minutes, like a team of ten doing the work of one, except this team shows up at the press of a button.

There's nothing to memorize about setting this up: sub-agents are definition files that live in .claude/agents/ (the same family as skills), and you can simply ask Claude Code to build them: “turn the Gmail labeling skill into a sub-agent, I want 10 running in parallel, use the Sonnet model, test it and time it for me.” One small note: after building an agent you must open a new session before that session can see the agent, like hiring someone today who only shows up to work tomorrow.

Two hard-won rules for delegating to the troops

Rule 1: the brief you give a sub-agent must be small and bare. Sub-agents run on cheaper models, so they're less smart than the parent, and this is where 11th-grade probability comes back to collect: if each one is 95% right, 3 in a row are all right only 85% of the time, 10 drop to 59%, and 50 drop to 7%. The more troops, the lower the odds that “the whole team runs smoothly.” The fix: give each one a single, tightly scoped job (“classify these 100 emails using label set X”) and don't make it carry a whole chain.

Rule 2: spell out what the troops are allowed to send back. The original course hit exactly this bug: 10 agents returned the full text of a thousand emails to the parent, the parent ran out of memory, and the whole run failed. The fix is one instruction: “sub-agents must not return the full text, only the classification result.” Soldiers report numbers; they do not read the whole ledger aloud to the boss.

Three sub-agents worth building for everyone

1. The researcher. It takes a question, spins up several parallel searches across sources you've pre-approved (trusted sites, official documentation), and returns a synthesis. All the clutter from the digging stays in its own memory.
2. The reviewer. This is the sharpest one: its value lies in the fact that it knows nothing. Right after finishing a product, the parent session is full of the bias “what I did is right,” just like a craftsman who has worked 10 hours in one direction. Hand the product to a fresh pair of eyes with no context and it spots the blind spots of people too close to the work. Big software companies make “someone else reviews the code” (code review) mandatory for exactly this reason; MONA does the same, and everything a machine builds for a client passes through fresh eyes, both human and machine.
3. The tester (QA). Write tests for the product you just built, run them, report pass or fail, fix what failed. This is the “verify” beat from lesson 3, now packaged as a dedicated team member.

Chain these three into the standard workflow recorded in CLAUDE.md: the parent builds, the reviewer inspects, the tester runs the tests, the parent fixes based on both reports, and only then does it ship. For a personal toy it's a bit much; for anything meant for other people, this rhythm is your safety line.

Agent teams: a higher rung, and a higher bill

Sub-agents are troops that only report to the parent. Agent teams add another layer of management: a team-lead agent splits work among team members on its own; each member is a full Claude session, reads its own CLAUDE.md, runs its own skills, and talks to the others through a shared task board (like the internal assignment board in project management software). You stand outside like a company owner: give the team lead the goal, and occasionally poke in to message one member directly. This feature is experimental and must be enabled manually in settings.json (ask the machine to switch it on and you're done).

It sounds great, and social media is hyping it to the skies. Time for a necessary splash of cold water, with figures from Anthropic itself: an agent team uses about 7x the tokens of a single session, because each member carries its own full memory plus the “meeting” overhead between agents. Left unwatched, it can literally burn tens of millions of VND in a day. The official recommendation: use cheap models for members, keep the team very small, give very tight briefs, and disband the team as soon as the work is done.

We'll close with the principle we want you to carve into memory: how impressive a tool is should never be the goal. If a single session does the job well, use a single session. If the work splits into many independent, identical pieces, use sub-agents. Only when the work truly needs several roles coordinating and debating do you reach for an agent team, with an eye on the bill. Most of the business value sits in the first two rungs.

Try it yourself before moving on to lesson 10

1. Ask the machine to build the reviewer and the tester .claude/agents/, and record the “build, review, test, fix” workflow in CLAUDE.md.
2. Take a skill you built in lesson 7, run it through the new process, and read the two reports to see what errors it catches.
3. Try a real split job (classifying a few hundred rows of data) with 5-10 sub-agents, and time it against a sequential run.
4. If you want to play with agent teams: enable the feature, give it a small brief like “3 members each build one of 3 options for an About page, then open them for me to compare,” and look closely at the token bill afterward.

Lesson 10, the last lesson of the course: git worktree how to run several sessions on the same project without stepping on each other, and how to put your product live on the internet. When you finish, you'll have gone the full loop: from installation to a product alive in the real world.