Parallel chunks: when splitting helps and when it fragments

Cowork "breaks complex work into smaller tasks and coordinates parallel workstreams to complete them", and "for complex tasks, Claude may coordinate multiple sub-agents working simultaneously."

Read that carefully for what it does not say. There is no switch, no chunk size, no way to ask for one worker or five. Splitting happens during planning, automatically, when Claude judges the task complex enough.

What is actually documented, and what is not

Worth being plain about the evidence here, because it is thinner than for most of Cowork.

Documented: that splitting happens, that sub-agents may run simultaneously, and that it is part of how Claude structures complex assignments.

Not documented: how many run, how work is allocated between them, what each one can see, whether they share context, or any limit. The help centre states the capability and stops.

So treat claims about Cowork's parallel mechanics — including ones extrapolated from how Claude Code's subagents work — as inference until Anthropic publishes more. The architectures are related and that is not the same as identical.

What you control is the goal

Since you cannot direct the split, the lever is upstream: a goal that decomposes cleanly gets split cleanly.

Work with independent units splits well. Twenty documents to summarise, a folder to reorganise, several sources to check — each piece can be done without knowing what the others found.

Work where step two depends on step one's answer does not. Neither does work with a single judgement at the end that needs everything in view at once. Ask for that in one instruction and you are relying on the coordination to hold something together that would have been easier undivided.

Writing a goal an agent can finish is the page that governs this. Parallelism just raises the cost of getting it wrong.

Where it fragments

Two places, and neither is about correctness of the individual pieces.

Consistency between chunks. Workers producing similar output can make different reasonable choices — a different date format, a different heading level, a different judgement call on an edge case. Each is defensible alone. The combined artefact reads as if several people wrote it, because in effect several did.

The trail. Reading the step trail for one linear task is straightforward. Reading it across concurrent workstreams is harder, and it is the main record you have of what actually happened, since Cowork has no documented undo.

Try this

Give it a task with clearly independent parts and watch the trail. Then give it one where a later step depends on an earlier answer, and compare how legible each is afterwards.

You are not measuring speed. You are measuring how hard it is to reconstruct what happened, which is what you will need when something is wrong.

What goes wrong

Expecting a control that does not exist. Prompting for "three parallel workers" is asking for something the interface does not expose.

Splitting a task with a single judgement at the end. The pieces come back fine and the synthesis is the part that needed one view of everything.

Accepting a combined artefact without a consistency pass. The individual chunks are each right, and the seams are where the errors live.

Reading the trail as though it were linear. Concurrent steps interleave.

How to check it worked

Read the joins rather than the pieces. Where two chunks meet, is the formatting consistent, is a term used the same way, does a fact stated in one contradict the other? Individual chunks are usually right, and the seams are where parallelism actually costs you something.