What exactly is a Sub-agent, and how is it different from what I'd normally call a 'multi-step task'?
A sub-agent is a self-contained piece of work that the main task hands off entirely to a separate, independently running Claude instance. That instance handles the work and reports the result back — the main task never needs to know how the sub-agent got there. This is quite different from a typical multi-step task, where a single Claude instance works through step one, step two, step three in sequence, all sharing the same Context Window. As steps pile up, earlier information tends to get crowded out or blurred.
A sub-agent avoids that entirely: each one gets its own clean, dedicated context window holding only its assigned slice of work, untouched by anything else happening in the main task. Say the main task is 'review these 20 vendor contracts.' The typical approach reads through them one by one in the same conversation — by contract 15, details from contract 1 may already be fuzzy. With sub-agents, the 20 contracts get split across several instances, each focused only on its own batch, with no interference from what came before.
What are the risks of using sub-agents, and which one gets overlooked most often?
The risk most often overlooked is coordination cost. Sub-agents run fast because they work in parallel, but each one only sees its own slice of the picture — not what the other sub-agents are doing. If tasks actually have hidden dependencies (say, a clause Sub-agent A reviews should affect how sub-agent B judges a different contract), splitting the work into sub-agents can cause that connection to get missed entirely, since no one is responsible for tying the two pieces together unless the main task does a cross-check afterward.
The second overlooked risk is inconsistent output quality. Because each sub-agent runs independently, if the task description isn't precise enough, different sub-agents may interpret the same ambiguous instruction differently, leading to results that don't quite match in style or standard once merged back together. This is especially dangerous for work that demands a strict, uniform standard — compliance review or legal document comparison, for instance — because on the surface it looks like everything got reviewed, but the strictness may vary from one sub-agent to the next.
When does it make sense to use sub-agents, and when doesn't it?
The core test is whether the tasks are genuinely independent, can run in parallel, and don't need to reference each other's results. Checking code quality across three different modules in a project, researching three competitors' pricing strategies at once, or summarizing meeting notes from three separate clients — these can all run simultaneously without affecting one another, which makes them good candidates for sub-agents.
It doesn't make sense when tasks are tightly dependent — when a later step genuinely needs the result of an earlier one to know what to do next. Analyzing a market report first, then deciding whether to dig deeper into a specific issue based on that analysis, is this kind of 'conclusion-first' task. Splitting it into sub-agents adds coordination overhead, since sub-agents can't exchange intermediate results in real time; a single sequential flow works better, letting each step see the full reasoning of the one before it. A simple test: ask whether these sub-tasks could all be fired off at once, or whether they genuinely need to happen in order. If the answer is 'at once,' sub-agents are the right call.
How should advanced users design Sub-agent tasks to get more consistent results?
The key move for advanced users is standardizing the criteria before dispatching work, rather than discovering inconsistencies afterward and going back to fix them. In practice, this means writing a short, explicit shared brief upfront — covering the judgment criteria, Output Format, and which fields need to be flagged — so each sub-agent receives not just 'review this contract' but 'review this contract against these five criteria, mark each as compliant or non-compliant, and cite the specific clause number as evidence.' Even though each sub-agent still runs independently, a shared starting brief keeps the merged results far more consistent in style and rigor.
A second advanced technique is designing an actual merge step, rather than simply stitching sub-agent outputs together. Once the main task receives all the sub-agent results, it should run a cross-check pass, specifically looking for contradictions between sub-agents or hidden dependencies that should have been cross-referenced but were instead handled in isolation. This merge-and-check step is exactly what compensates for the structural blind spot of sub-agents not being able to see each other — and it's usually the dividing line between reliable and unreliable sub-agent output.
Say you need to review 20 vendor contracts for payment terms and breach clauses. Instead of reading them one at a time yourself, you could first write a shared review standard — payment terms shouldn't exceed 60 days, penalty clauses shouldn't exceed 10% of contract value, no unilateral termination clauses — then have the system split the 20 contracts across multiple sub-agents working in parallel. Each one receives the same standard, focuses on its own batch, and the judgments get merged into a single comparison table at the end. That's far faster than working through them sequentially, and because the starting standard is shared, the strictness of review stays consistent across all 20 contracts. The practical takeaway: batch, splittable review work — especially where you can write out a clear standard upfront — is exactly where this pattern saves the most time while keeping quality consistent.
The biggest advantage of sub-agents is speed — work that can run in parallel actually runs in parallel, instead of queuing up one task after another. This is especially valuable for batch, low-dependency repetitive work. The cost is coordination overhead: each sub-agent only sees its own slice of information and can't see what the others are doing, so hidden dependencies between tasks are easy to miss and require an extra merge-and-check step to compensate. Sub-agents fit well when there are many tasks, they're genuinely independent, and the judgment criteria can be clearly written out in advance. They don't fit when tasks are tightly interlinked, need to reference another step's intermediate results in real time, or when the criteria themselves are vague and need to be adjusted on the fly. In short, sub-agents trade time efficiency for coordination complexity — whether that trade is worth it depends on how low the actual dependency between tasks really is.