Scaling Beyond One Agent

Everything so far has covered one agent doing one thing. That's fine, until it isn't. Sooner or later a single agent stops being enough for the amount of work actually sitting in front of you, and that's exactly the point where scaling questions start to matter.

Running more than one session at once

Once your task, execution, and verification steps live in CLAUDE.md, multiple Claude sessions can run the same kind of workflow side by side, each one following the same instructions without you having to repeat yourself to any of them. Nothing stops you from doing this today. The main limit in practice is your own usage or token budget, not the tool itself.

I demonstrated this directly. I instructed Claude to adapt a generated website for a specific client: extract the client's real information, drop it into the existing layout, keep the visual direction intact, and keep going with the screenshot loop until the result actually looked professional. I've also floated a bigger version of the same idea: feed Claude three reference designs plus CLAUDE.md instructions, and it could plausibly run three independent build-and-compare loops, presenting all three options after five or ten minutes. That's my own projection, not something I've demonstrated live in the course, so treat it as an idea worth testing yourself rather than a proven result.

Coordinating several agents at once is a skill you build with practice, not something you're handed on day one. The upside is speed: several projects moving forward together. The cost is constant context switching, since you still have to monitor each one and step in when it needs you. The one thing to actively avoid: letting a session sit idle while it waits on you. If a session spends more than roughly ten to twenty percent of its time just waiting, that's a real signal you've opened too many tabs at once. I personally run three or four sessions at a time, depending on how demanding each project actually is.

Giving Claude a memory

Auto-memory lives at a fixed path inside your home folder, and its first two hundred lines load into the system prompt automatically every time a session starts. Claude can read it. Claude can also update it mid-session, without you asking it to.

Here's the distinction that actually matters: CLAUDE.md holds instructions you wrote, the rules you sat down and typed out yourself before Claude ever touched the project. Memory holds observations Claude made on its own.

FIGURE 17 — Memory vs. CLAUDE.md. CLAUDE.md holds what you wrote; memory holds what Claude noticed on its own.

I proved this works with a small test: I told Claude to remember my brother's name, then opened a brand-new, unrelated conversation and asked again. It answered correctly. The fact had survived outside the conversation that created it, which is the entire point of the feature.

Subagents: work with its own separate context

A subagent starts fresh. It gets its assigned task and its own instructions, but none of the parent conversation's history comes along for the ride, which is exactly what keeps its context small and focused instead of dragging in everything that came before. Here's what a real subagent definition actually looks like on disk, before getting to the three roles it's typically used for.

FIGURE 18 — Subagent definition anatomy. Six front-matter fields, then a plain-language instruction body.

Three roles matter here. Figure 19 shows them together, each one solving a different problem that would otherwise pile up quietly inside a single, already-crowded conversation over time, left to accumulate until it slows everything down.

FIGURE 19 — Three subagent roles around one parent agent. Each spoke solves a different problem, token cost, bias, or context noise, so picking only one role misses what the other two are for.

Research exists mainly to protect tokens. It can spend fifty to a hundred thousand tokens gathering and analyzing information, and still hand back only about two thousand tokens of summary to the parent. That specific ratio is my own example, not a guaranteed outcome you should expect on every task. Figure 20 shows just how lopsided that trade genuinely looks once you actually draw it to scale.

FIGURE 20 — What a research subagent spends vs. what it returns. The short bar is the point: a subagent can spend enormously and still hand back almost nothing, which is exactly why it's worth using one. Cheaper models work fine here, since the child doesn't need the parent's full capability to do this kind of legwork.

Reviewer solves a completely different problem: bias, not cost. An agent that wrote some code tends to keep justifying its own choices, the same way a person does after committing to a decision they already made. A reviewer with zero prior context has no such attachment. It can catch problems, question strange choices, and suggest something simpler, precisely because it never had a stake in the original approach to begin with.

QA (quality assurance) solves a different problem. It keeps test output out of the parent's context entirely, running verification independently so the parent doesn't have to absorb every line of test noise along the way.

A fourth reason to reach for a subagent: raw throughput

Research, reviewer, and QA all answer why to reach for a subagent in the first place. There's a fourth reason I haven't covered yet. It's less about any one subagent's own reasoning and more about raw parallel throughput: split one expensive step across many identical workers running at once, then merge what comes back.

I already had a real number to test this against. The Gmail-labeling Skill I built earlier processes 100 emails in about 36 seconds, and the breakdown tells you exactly where that time goes: roughly 34 of the 36 seconds is classification. Fetching and applying labels together barely register. That's not a subtle imbalance. Classification is nearly the whole cost, so it's the only step actually worth splitting up. Parallelizing a step that's already fast wouldn't move the total by much.

So I asked Claude to convert the Skill into a Subagent-based workflow: spawn 10 Subagents in parallel, divide the classification work between them, combine the results, apply the Gmail labels, and measure how long the new version takes. One more instruction went with it. Research the official Subagent specification if needed, and build the workers on Sonnet 4.5.

FIGURE 21 — Fan-out to ten Subagents, then merge. Only the classification stage runs as ten parallel copies; everything else in the workflow stays exactly as it was.

Rather than guessing at a structure, Claude looked the mechanism up first: searched for how Claude Code Subagents actually work, checked the workspace for any existing Subagent patterns, and pulled the real documentation before writing anything. Read before you build. That's the same discipline I've seen it apply elsewhere in this course, not the other way round. It then defined a narrow email-classifier Subagent: hand it one chunk of Gmail messages, and it sorts each into the same three categories the rest of the workflow already uses. Claude updated the existing Skill to call these workers and combine what came back, instead of classifying the full batch itself.

I ran it. The fan-out and the merge showed up as separate, visible steps. Ten independent task results came back, each covering its own chunk of the batch. Once every worker finished, Claude merged the pieces into one 100-email result (7 Action Required, 0 Waiting On, 93 Reference) and fed that combined set into the same Gmail-labeling step the sequential version already used. Only the classification stage changed; everything downstream of it kept running exactly as before.

FIGURE 22 — Ten Subagents cut the bottleneck, not the whole job. A 1.8x win on the one step that got split up, not a 10x win on the whole workflow.

The payoff is real. The sequential run took about 36 seconds total, roughly 34 of which were classification. The parallel version takes about 30 seconds overall, and classification specifically drops from about 34 seconds to about 19, somewhere around a 1.8× improvement in the one step that got split up.

Ten Subagents didn't make the whole workflow ten times faster. That's not a disappointing result, it's an accurate one: classification was only ever part of the total time, and spawning ten workers, waiting for all of them, and merging their output back together all cost something too. Parallelizing a step speeds up that step. It doesn't erase everything happening around it. Measure first, find the actual bottleneck, and split up that step specifically, rather than throwing parallelism at a workflow indiscriminately and hoping the whole thing gets faster.

Try this with AI "Here's a multi-step workflow I run repeatedly: [describe it]. Help me figure out which single step is actually eating most of the time, and whether that one step could run in parallel without breaking the steps around it."

Skills: teaching the same agent a trick

A subagent is a separate agent with separate context. A skill is different in kind, not just in degree. It teaches the parent agent itself a repeatable process to run inside the current session, rather than spinning up anything new, the same session and the same memory, just a different set of instructions to follow. Figure 21 lays the distinction out side by side.

FIGURE 23 — Skill vs. subagent. Same agent, same context versus a fresh agent with none of it, that one distinction decides which mechanism actually fits a given task.

One example from the course: a skill for shopping on Amazon through a browser-automation tool, built with an explicit safeguard, it must stop and ask before actually placing an order, and it carries extra instructions for handling anything payment-related safely. Given a real task, Claude used it to search, compare a handful of options, and return a table sorted by price, rating, and delivery time. I recommend against letting any skill complete a purchase fully on its own. Buying stays a human decision. The safer pattern lets Claude add items to a cart and leaves the actual purchase to you.

Skills don't have to be written by hand, either. You can describe a workflow in plain language and have Claude research the right format and produce the file itself. And they improve the same way anything else does here: test a new skill on a fresh session with zero prior context, note where it fails, fix it, and test again, the cycle below.

FIGURE 24 — Skill-creation cycle. Skills improve the same way anything else here does: test, fix, test again.

Try this with AI "I do [describe a recurring task] roughly the same way every time. Help me turn it into a Skill: what should the goal, inputs, and step-by-step process be?"

It's not instant. My own rough progression, accurate maybe seventy percent of the time at first, climbing to roughly eighty, then ninety, then landing near ninety-eight or ninety-nine percent after several rounds of this, is my estimate from repeated use, not a formal measurement anyone ran in a lab.