What this is
These are three sub-agent workflow design principles drawn from practice: write a shared standard before dispatching, design an explicit merge step, and test at small scale first to confirm the task actually suits splitting. The common problem these three principles address is that the sub-agent concept sounds intuitive, but actually designing it into a reusable workflow easily goes wrong at inconsistent standards, sloppy merging, or tasks that weren't actually suited to splitting in the first place.
The three principles map to three stages of a sub-agent workflow: before dispatch (writing the standard), during merging (designing the check step), and before rolling out fully (small-scale validation) — covering the complete process from designing a sub-agent workflow to actually shipping it.
Why this exists
These three principles matter because the parallel-processing architecture of sub-agents inherently produces two structural problems — inconsistent standards and blindness to each other — rather than these being occasional operational mistakes. Each sub-agent is an independent instance; without an explicit shared standard, each one filling in ambiguous instructions with its own interpretation is something that inevitably happens under this architecture, not bad luck. Likewise, each sub-agent only seeing its own slice of data is an inherent limitation of the parallel architecture — it doesn't get automatically solved just because a sub-agent 'works more carefully.'
The point of these three principles is addressing these two structural problems at the workflow design stage, preventing them upfront rather than discovering something's wrong after the results come back and having to fix it retroactively. The third principle (small-scale testing) exists because how much dependency tasks actually have is often hard to accurately assess in advance — only running an actual batch reveals whether the merge cost is worth it, which is why this can't rely on upfront judgment alone and needs a validation step built in.
How this affects your decisions
If you're evaluating whether to use sub-agents for a batch task, these three principles change your planning order. You might have previously thought 'this task can be split' and gone straight to dispatching — now you should first ask yourself three questions: can this task have a specific, workable shared standard written for it; could the merged sub-agent results plausibly contradict each other or contain dependencies that should have been cross-referenced but got handled separately; and if unsure, has this been tested at small scale on two or three items first. Only after thinking through all three should you decide whether to roll it out to the full dataset.
This also changes how you allocate time. You might have assumed 'sub-agents should save time' and put all your time budget into waiting for them to finish — now you should reserve part of that time for the merge-check step, since it isn't an optional finishing touch, but the step that actually determines whether the whole workflow's quality is reliable.
Advanced applications
Advanced users can design the merge-check step itself as a dedicated sub-agent, rather than handling it manually back at the main task. In practice, this means alongside the sub-agents doing the actual work, dispatch an additional 'merge review sub-agent' — one that doesn't process the raw data at all, but only reads the outputs of the other sub-agents, specifically checking for contradictory judgments or missed cross-references. The benefit here is that merge review can approach the problem from a different angle than the original task, focused on finding problems rather than doing the task — which usually catches issues more reliably than the main task casually reviewing its own results.
Another advanced technique is having Claude help design the shared standard itself, rather than relying entirely on your own thinking. In practice, this means first asking Claude to list the ambiguous edge cases for this type of task — places different sub-agents might plausibly interpret differently — then writing each of those edge cases out clearly one by one. This step is essentially a check on 'is the standard itself specific enough' done before dispatching, which is far more efficient than discovering the standard was ambiguous only after each sub-agent has already interpreted it differently and merging reveals the mess — and it heads off the standard-inconsistency problem from Principle One at the source.
The concept of sub-agents sounds intuitive: split work that can run in parallel across multiple independent instances instead of processing it in sequence, and finish far faster. But knowing the concept and actually designing it into a reusable workflow are two different things — many people's first attempt at sub-agents runs into merged results that are a mess, sub-agents applying inconsistent standards to each other, or the whole thing taking longer than just processing sequentially would have. This piece lays out three design principles drawn from practice that help a sub-agent workflow actually ship, rather than staying stuck at the 'sounds impressive' stage.
The most common way sub-agents go wrong is that each one receives instructions too vague, so each fills in the gaps with its own interpretation, and the merged results end up wildly inconsistent in style and judgment standard. Ask three sub-agents to each review a contract with only 'check this contract for any problems,' and sub-agent A might focus on payment terms, sub-agent B might focus on breach liability — the merged result looks like everything got reviewed, but the actual angles of review were completely different, making them impossible to compare side by side. The fix is spending time before dispatching to write a short, specific shared standard — something like 'review against these three points: payment terms, penalty ratio, unilateral termination clauses, and give a compliant/non-compliant judgment for each.' This way every sub-agent works from the same ruler, not its own subjective read.
The inherent limitation of sub-agents running in parallel is that each one only sees its own slice of data — not what the others are doing. If the tasks actually have dependencies — say, the payment terms sub-agent A reviews happen to affect how sub-agent B should judge a non-compete clause in a different contract — that connection is easy to miss when each is working in isolation. So merging can't just be pasting three results together and calling it done; it needs to be its own explicit step: have the main task (or a dedicated merge sub-agent) re-read all the results, specifically checking for contradictory judgments or hidden dependencies that should have been cross-referenced but got handled separately instead. This merge-check step is exactly what compensates for the structural limitation of sub-agents not being able to see each other.
Not every task that looks parallelizable actually becomes more efficient once split. If the dependency between tasks turns out higher than expected, splitting into sub-agents can end up taking longer overall than sequential processing once you factor in the cost of the merge-check step. The more reliable practice is testing with sub-agents on two or three items at small scale first, confirming the merged result quality holds up and the merge step isn't eating excessive extra time, before applying the whole workflow to the remaining data. If the small-scale test already shows merging takes a lot of time, or sub-agents frequently contradict each other's judgments, that usually signals the task has more inherent dependency than initially assessed — and adjusting how it's split, or simply sticking with sequential processing, will be more efficient than forcing sub-agents onto it.
If you've already started using sub-agents for batch work but feel the merged results aren't quite reliable, or you're spending more time than expected organizing the output, you've likely missed one of these steps — the shared standard wasn't written clearly, merging was just formal pasting-together, or the task actually wasn't well suited to splitting in the first place. Treating these three principles as a pre-design checklist for sub-agent workflows significantly narrows the gap between 'sounds impressive' and 'actually reliable in practice.'