How do you break a large task into agent-sized tasks?

The instinct is to divide by size, which produces pieces that are convenient to run and useless to check, because a portion halfway through a process has no state anyone can evaluate. The productive criterion is the handover test: at the end of this piece, is there an artefact a different person could receive, inspect and continue from? Where the answer is yes, the seam is real. Where it is no, the division exists only in the plan and the work will have to be carried across it anyway.

In practice the good seams are usually the same ones a human process would have. Gathering is separable from deciding. Analysis is separable from writing. A migration separates at the point where the transformed data exists but has not been loaded. A code change separates where the interface is agreed but not implemented. Each of these ends in something inspectable, which means it also ends in something an agent can be judged against before more work is built on top of it.

The second criterion is dependency rather than sequence. Two pieces that could be done in either order are genuinely separate; two that must be done in a fixed order because the second consumes the first are one piece with a checkpoint in the middle, and calling them separate tasks does not make the second one runnable in isolation. This matters because it determines whether pieces can be given to different runs at all, and mistaking a checkpoint for a boundary is the usual reason parallel attempts produce conflicting work.

The third is that each piece needs its own completion condition, and the ability to write one is a good test of whether the division was sound. If a piece's finished state can only be described as having made progress, it is not a piece. This is the most useful practical filter available, because it is quick and it catches divisions that were made for convenience.

There is a cost to dividing, and it should be counted rather than assumed away. Every boundary is a place where context must be re-established, where something known in the first piece is unavailable in the second, and where a handover document has to be written and read. Over-division produces a run that spends most of its effort on orientation. The right number of pieces is the smallest number that keeps each one inspectable, not the largest number the work can be cut into.

The output of the division is worth keeping as an artefact in its own right. A written plan naming each piece, its input, its finished condition and its dependencies is what allows work to resume after an interruption, be split across sessions, or be picked up by a different run. Without it, the division exists only in the context of the session that made it, which is the same as not existing.