If you split a big job into tiny pieces for many AI agents to handle at once, do the pieces really stay separate — or secretly depend on each other?

This explores whether splitting a task into pieces really gives you parts that many agents can work on separately, or whether the parts stay tangled together. The corpus suggests decomposition can produce independence, but it is something you build and check, not something you get for free. The most striking evidence comes from MAKER Can extreme task decomposition enable reliable execution at million-step scale?. It finished million-step tasks with zero errors by cutting the work into the smallest possible steps and having several small agents vote on each one. Look at what made that work: voting only helps if the agents' mistakes are independent, so MAKER also had to watch for errors that were correlated. Independence was the property the whole design depended on, and the system kept checking it rather than assuming it.

The first place independence breaks is the cut itself. When a standard LLM splits a task into steps, it matches the right step structure only about 34% of the time, and this granularity problem turns out to be the main bottleneck for everything downstream What blocks skill retrieval in task decomposition?. If the pieces are cut too coarsely, too finely, or in the wrong places, the subtasks end up sharing hidden assumptions, so agents working 'independently' are really leaning on each other's context. One answer is to make decomposition a separate job. Systems that split the planner from the solver do better, and the skill of decomposing carries over to new domains while the skill of solving does not Does separating planning from execution improve reasoning accuracy?. LLM Programs take this a step further: an ordinary algorithm handles control flow and shows each LLM call only the context that step needs Can algorithms control LLM reasoning better than LLMs alone?. In other words, independence comes from deliberately hiding information, not from the task naturally falling apart into clean pieces.

The most surprising evidence comes from safety research, and it is the part a curious reader probably didn't expect. SafeFlow shows that a harmful goal can be spread across subtasks that each look harmless on their own. The harm only appears when the pieces are put back together Can task decomposition hide harmful intent across agents?. That is the independence assumption failing in a precise way. Each subtask is independent enough to pass inspection, but the meaning lives in how they combine. Any property that only shows up in the combination, whether harm, correctness, or coherence, cannot be guaranteed by checking the pieces one at a time.

There are also signs that full independence may not be the right goal. The Thread Inference Model handles recursive subtask trees inside a single model, pruning its working memory as it goes, and it argues this can replace multi-agent setups altogether Can recursive subtask trees overcome context window limits?. You get the structure of decomposition while keeping the shared context. IMACS separates independence along a different axis: team roles, coordination rules, and how results get merged become swappable layers Can multi-agent teams swap roles, coordination, and algorithms independently?. DyLAN scores how much each agent contributes and drops the ones that add nothing Can multi-agent teams automatically remove their weakest members?. That is a reminder that many agents' outputs overlap rather than adding separate value.

So can decomposition achieve the independence swarms need? Yes, at very fine granularity, with an outside controller, and with explicit checks for correlated errors. Without those, the subtasks stay quietly coupled. The corpus does not have a direct study measuring how independent swarm subtasks really are. The evidence here comes from neighbouring work on reliability, retrieval, and safety.