How do you pick subtask granularity when an agent decomposes a goal?

## What granularity means here When an agent turns a goal into a plan, it emits a list of subtasks. Granularity is how much work each of those subtasks represents — the difference between *do the due diligence*, *review all contracts*, *review the 14 supplier contracts signed after 2023*, and *read page 3 of contract 7*. All four describe the same underlying work at different resolutions. Choosing the resolution is one of the few decisions in decomposition that reliably decides whether the run succeeds. ## The verification floor The lower bound on coarseness is verifiability. A subtask exists so that the agent — and whoever audits the run — can say "this is done" and move on. If completion cannot be checked, the agent has no signal, and the usual outcome is a confident claim of success over work that was never finished. *Review all contracts* fails this test twice over: the set is unbounded (which contracts? in which repository?) and the verb is unmeasurable (what does "reviewed" produce?). A useful drill is to write the check before the task. If the check is "a list of contract IDs with a boolean auto-renewal flag, one row per contract in the named set", the subtask writes itself. If no check can be written in a sentence, the subtask is still a theme and needs to be split until each piece has one. Verification also determines whether a subtask can be safely handed off. A step whose output is a small, named artifact can be produced by anyone — a later stage, a fresh session, or a separate subagent — and the caller can judge the result without redoing it. A step whose output is "understanding" cannot be handed anywhere. ## The overhead ceiling The upper bound on fineness is cost. Every subtask carries fixed overhead: at minimum a model turn that re-reads the plan and the relevant context, and often a tool round trip, a status write and a token bill for restating what the previous step already established. Splitting a coherent piece of work into a dozen micro-steps multiplies that overhead without buying accuracy — and each additional hop is another place where the agent can misread state or drift off the goal. So the practical band is: fine enough that failure is localized and checkable, coarse enough that a step is worth the turn it costs. A good test is whether the step's *body* is substantially larger than the *bookkeeping* around it. If restating the context takes more tokens than doing the work, merge it upward. ## Heuristics that hold up - **Bound the input set explicitly.** "The 14 supplier contracts signed after 2023" beats "the relevant contracts" — the agent cannot silently redefine the scope mid-run. - **Name the output artifact.** A file, a table, a list, a patch. "Analyze X" produces nothing; "write findings for X to `findings/x.md`" does. - **One verb, one resource class.** A subtask that both fetches documents and judges them is two steps whose failures are indistinguishable from the outside. - **Match the tool's natural unit.** If a tool returns a page at a time, a per-page subtask is fine; if it returns a corpus, a per-corpus subtask is fine. Fighting the tool's unit is what creates either 200 tiny steps or one unbounded one. - **Size to the verification you actually have.** With a programmatic checker (tests, a schema, a diff), steps can be larger, because failure is caught mechanically. With only human review, keep steps small enough that a person will actually read the output. ## Signals you chose wrong Too coarse looks like: a step that runs for many turns without producing an artifact; a step marked done with a summary rather than an output; two runs of the same step producing incomparable results. Too fine looks like: adjacent steps whose outputs are trivially concatenated; a plan longer than the work; most tokens spent restating context rather than doing anything. ## Interview framing What separates a strong answer is treating granularity as a *decision with two opposing costs* rather than a style preference, and naming the verification test as the thing that resolves it. Weak answers assert that smaller is safer, which is the intuition from human project management and does not transfer: for an agent, each extra step is another opportunity to lose state, not another checkpoint of safety. Strong answers also note that granularity is workload-dependent — the right size shifts with how reliable the tools are, how expensive a step is, and whether an automated verifier exists.