Parallel Sub-Agents Change How You Plan, Not Just How You Build

You can plan a day around what you can do, or around what you can decide. Until recently those were the same plan, so it never mattered which you meant. Parallel sub-agents pull them apart — and the interesting part isn't that the work goes faster. It's that what you're planning changes underneath you.

For years I planned my days around a single number: how much work I could personally get through. Six, maybe eight focused hours, and I'd fill the day to that line. I thought I was planning the work. I was planning me — my hands were the bottleneck, so my capacity was the plan.

That number is now wrong, and staying anchored to it leaves most of the day on the table.

Two kinds of work, and only one is yours

Almost any task is a blend of two kinds of work that behave nothing alike.

Mechanical work — reading files, summarizing, extracting, drafting first cuts, bulk-editing. It has no internal dependencies: item 7 doesn't need item 6. Hand it to a fleet of sub-agents and it happens all at once.

Judgment work — deciding what to do, setting priorities, cutting the dead project, reviewing what came back and saying yes or no. Each call leans on the ones around it and on context only you hold. It can't be handed off, and it can't be parallelized.

For most of knowledge work's history, these two were welded together. You couldn't make the decisions without first doing the reading, so the reading time was simply "the work," bounded by how fast you personally moved through it. Parallel dispatch pulls the two apart. The mechanical half moves to the machine. The judgment half stays exactly where it was — with you, one call at a time.

So your scarce resource was never really time — it was judgment, trapped inside a lot of mechanical hours that hid the difference.

If that sounds like delegation, it isn't — not quite. Delegating to people never exposed this, because a human team has its own execution hours and coordination cost; the mechanical time just moved — it didn't vanish. Collapse that mechanical time toward zero, and your judgment is the only wall left.

The number that sets a day's capacity changed

Once the mechanical half isn't yours, the question that sizes a day flips. It's no longer "how much can I execute?" It's "how much can I decide and review?" — and those numbers are nowhere close.

Here's the concrete shift in my own planning. I used to schedule my days at six to eight hours of work — the amount I could actually do with my own hands. Now I plan them at fifteen to twenty hours of work — measured as what it would have cost me by hand — while spending only a few hours steering it.

Not because I got faster, and not because I started grinding longer. Because most of those hours are mechanical, and mechanical hours aren't mine to grind through anymore. My few hours go to the part that's still mine: deciding what to send off, and judging what comes back — and the judging is real work, not a rubber stamp. Some output is faster to redo than to salvage; catching plausible-but-wrong results is the tax on the leverage.

The plan stopped being a list of what I can do. It became a list of what I can decide — and each decision now pulls far more finished work behind it than it used to.

Why the old estimate quietly wastes the day

If you keep planning against your execution hours, you make the same mistake I did for a while: you under-load the day and never notice.

You block the calendar for the eight hours you can personally work, fill it with eight hours of tasks, and feel fully booked. But the machine that could have carried the mechanical bulk of that work sat idle, because you never scoped for it. You were busy the whole day and still left most of the day's real capacity unused — not because you ran out of hours, but because you ran out of plan.

The fix is to budget the resource that's actually scarce. Estimate the day by your decision-and-review hours, then load work onto it until those hours are full — not until your execution hours are. The mechanical bulk rides along underneath; it isn't what you're pricing.

In practice I scope a day or a sprint at roughly 2–3× what my old execution-bound estimate would have said, then correct from there. (That multiplier is my own calibration from planning-heavy weeks, not a benchmark — yours will track how much of your work actually decomposes into machine-runnable pieces.)

When the split isn't there

This only rewrites your planning when there's a mechanical half to hand off. Often there isn't, and it's worth being honest about where:

• Sequential design — where each step depends on the last decision — is judgment end to end. There's nothing to offload, so your execution hours are still the ceiling.

• A single hard artifact — one proof, one gnarly file, one architecture — has no surface to split.

• An external bottleneck — a slow CI run, a deploy, a human reviewer — doesn't care how many agents you have. The agents just wait in parallel.

For that kind of work, plan the old way: you are the executor, and six-to-eight is honest. The reframe only pays off to the degree your week decomposes — and more of it decomposes than you'd guess once you look for the seam.

Stakes are a different axis, not an exception. Higher stakes don't hand the mechanical work back to you — they make the review half deeper, so you steer less in a day. The split holds; the price of your half goes up.

The skill that actually changes

The instinct says adopting parallel sub-agents means learning to drive a fleet. The prompting is the easy part. The skill that changes is planning itself: seeing the judgment inside your work separately from the machinery around it, and sizing your days by the judgment alone.

Plan your decision-and-review hours, not your execution hours. The day holds as much work as you can steer — which is a great deal more than you can do. And the next time you fill a day to eight hours and call it full, ask what the machine could have been carrying while you did.

I'm a Technical Architect writing about the AI systems I design and how they change the way I work. The capacity numbers above are from planning my own knowledge system; treat them as a starting point to tune, not a law.