Breaking Big Tasks into Claude Code Subagents: A Workflow That Actually Ships
Claude Code subagents let your main agent delegate independent work to fresh Claude instances — and only receive the conclusion. Here's when to use them, how to scope tasks that don't come back shallow, and how to keep your main context from filling up mid-session.
You know that feeling: one task, one goal — but somehow you’re managing ten browser tabs. You’re tracing how a function is used across the codebase, checking a library’s latest API, holding onto why a test is failing, and trying to actually make a decision, all at the same time. Every context switch rebuilds the same mental state from scratch. By the time you get back to the actual judgment call, the cognitive load of switching is what’s eaten your afternoon.
Claude Code subagents exist to solve this. They let your main agent hand off the work it doesn’t need to do personally — the wide searches, the file-by-file explorations, the noisy middle ground — to a separate Claude instance that runs it in isolation and returns only a summary. Your main thread stays focused. This article covers three things: when a subagent is worth spawning, how to write a task brief that doesn’t come back vague, and how to stop your main context from accumulating weight you’ll never actually need.
What are Claude Code subagents?
A subagent is a fresh Claude instance: its own context window, launched by your main agent, given a self-contained task brief, and when it’s done, it sends back one summary message. That’s it. The 50 files it read, the searches it ran, the dead ends it tried — that all stays inside the subagent’s context and gets discarded when the task completes.
(For the full setup — custom system prompts, tool restrictions, how to invoke one — see the Claude Code subagents documentation.)
That “process stays inside, only the conclusion comes back” design is where subagents get all their value. It gives you three things:
- Isolation: large search results, full file contents, extended trial-and-error — all contained inside the subagent’s context, not bleeding into your main thread
- Parallelism: independent subtasks can run concurrently instead of queuing up one by one
- Specialization: you can tune agents for specific work — search, code review, exploration — with their own prompts and tool permissions
Once you understand these three properties, the “when should I use one?” question becomes a checklist, not a gut call.
When should you use a subagent?
The two-condition test
A subtask is a good fit for a subagent when both of these are true:
- It generates a lot of intermediate output you don’t need to read word-for-word. “Find every call site for this API across the repo” means reading dozens of files — but what you actually want is a list.
- You can fully specify it in one brief, with no back-and-forth. If you can write down “find this, search here, return it in this format” and the subagent can run to completion without checking in, it qualifies.
The three most common scenarios that pass both conditions:
- Open-ended search and exploration: “How does this feature connect across files?” “Where is X defined?” The cost isn’t the answer — it’s the traversal to get there.
- Work that’s parallel by nature: reviewing three modules simultaneously, researching four library changelogs at once. When there’s no ordering dependency between the tasks, run them in parallel.
- Protecting your main context: when a task will produce large output but you only need a distillation, push it into a subagent and get back a clean summary.
When NOT to use a subagent
Some situations look like good subagent candidates but aren’t. Forcing them in slows you down:
- The target is already known. If you already know the file and the line number, just read it. Spawning a subagent to open a known path is pure overhead.
- The task needs tight iteration. Some work requires seeing your response at each step before deciding the next one. That conversational rhythm breaks badly when cut into one-shot subagent returns.
- Steps have hard dependencies. If step two can’t start without step one’s output, they can’t be parallelized. Splitting them just adds handoff cost.
One-sentence rule: use a subagent when the handoff cost is lower than the context and time you’d save. Otherwise, don’t.
How do you scope a task for a subagent?
This is where most people go wrong — and where most shallow, generic subagent results come from. The scoping isn’t what’s broken; the brief is.
The key premise: a subagent has zero memory of your conversation. It’s a smart colleague who just walked into the room. It doesn’t know what you’ve tried, what you’ve ruled out, or why this matters. A good task brief is self-contained:
- State the goal and the why: what you’re trying to achieve and what depends on it
- Hand over what you already know: what you’ve checked, what you’ve ruled out — so the subagent doesn’t retrace steps you already eliminated
- Specify the return format and length: “give me a bullet list” or “200 words max” — without constraints, it’ll default to exhaustive
- For lookups, give commands; for investigations, give questions: if you know the exact thing to find, give the instruction. If you’re genuinely exploring, give the question — rigid steps become baggage when your premise might be wrong
There’s one principle that’s easy to miss: don’t delegate understanding.
Don’t write “based on what you find, fix the bug.” That sentence pushes the actual synthesis — the judgment — onto the subagent, which doesn’t have the full picture. The pattern that works: you digest the subagent’s findings yourself, then send back a specific instruction: which file, which line, what to change. The subagent handles the legwork. You keep the judgment.
Here’s the contrast made concrete:
Too vague: “Look into our auth flow and fix the login bug.”
Actually scoped: “Read
auth/session.ts. Check whether the token expiry handler correctly clears the cookie on early return around line 40. Report back: is my hypothesis right, and if not, where does it actually break?”
The second version comes back usable. The first version costs you three more rounds.
How do you keep the main thread’s context from blowing up?
Even with the right scenarios and a well-scoped brief, your main thread can still accumulate weight over time. Three practices that keep a solo workflow running clean for hours at a stretch:
Push reading, keep thinking. Anything that generates volume — traversing a repo, scanning dozens of files, crawling a long log — push it into a subagent. That raw content burns in the subagent’s context; you receive a distillation. Your main thread carries conclusions, not source material.
Specify return length explicitly. Left to its defaults, a subagent tends toward thoroughness — it’ll describe everything it did. Ask for “a bullet list,” “under 300 words,” “pass or fail and where it breaks” — whatever minimum signal you actually need. You want the answer, not the work log.
Parallelize, but don’t duplicate. Running independent tasks in parallel is fine. Running the same search in your main thread while a subagent is already doing it is not — you’ll burn context on both ends and risk getting conflicting conclusions. If you’ve delegated a piece of research, wait for the result.
One more thing worth stating directly:
A subagent’s summary describes what it intended to do — not necessarily what it actually did. When it writes or modifies code, check the real diff before calling the work done.
Trust but verify. A summary is an intent statement, not evidence. This matters most when the subagent touched code: open the actual diff before you mark anything complete.
One person, the shape of a team
Pull this together and you see what subagents are actually changing. It’s not speed, or at least not only that. It’s the ceiling on how much task complexity one person can hold and move forward at the same time.
Before subagents, the constraint was linear: finish this search, come back, start the next one, assemble at the end — everything running through one context, one thread of attention. With subagents, you become the dispatch-and-integrate layer. You send the independent work out, run it in parallel, and focus your attention on the part only you can do: the synthesis, the judgment, the call on what comes next.
That’s what LUCE has been building toward with what we call the “AI one-person company” model — not more tools, but a smarter division of labor where scarce attention only goes where it compounds. If you want to put this kind of workflow into practice in your own operation, that’s exactly what LUCE’s AI One-Person Company engagement is built around.
Start with the task you have right now: the one that feels like one goal but sprawls into multiple tabs. Find the piece that doesn’t need your direct attention. Write a self-contained brief. Hand it off. See what comes back. Then expand from there.
FAQ
How is a subagent different from opening a new chat window?
When you open a new chat window, you manually re-paste the background, the relevant files, and the goal — and then manually carry the result back into your main session. A subagent is launched by the main agent with a self-contained task brief already loaded, and it returns one summary message directly to the main thread, with no intermediate output flowing back. The difference isn’t whether you can delegate — it’s whether you pay the handoff and transfer cost yourself.
How many subagents can you run at the same time?
Tasks without ordering dependencies can be launched in parallel — reviewing multiple modules simultaneously, researching several libraries at once. The practical question isn’t a numerical cap; it’s whether the tasks are actually independent. If task B needs task A’s output before it can start, they can’t be parallelized, and forcing it just adds coordination overhead.
Can a subagent see my conversation history?
No. Every subagent is a fresh Claude instance with no memory of the conversation. This is exactly why the task brief needs to be self-contained: include the goal, the motivation, what you’ve already ruled out, and the return format you want. Without that context, the subagent has nothing to work from except the task itself — and vague briefs come back vague.
What tasks shouldn’t go to a subagent?
Three situations where subagents add overhead instead of saving it: when the target is already specific (you know the file and the line — just read it directly); when the task needs tight iteration where you see each intermediate result before deciding the next step; and when steps have hard sequential dependencies and can’t be run in parallel. The rule of thumb: if the handoff cost exceeds the context and time you’d save, skip the subagent.