Parallel work and the synthesis bottleneck

A research task that splits into independent questions can be run in parallel: an orchestrator writes one sub-question per worker, each worker is a separate model call with its own sources, and a lead model merges what comes back. The film runs one such task four ways on one bench. On the left the orchestrator’s desk splits the question into cards, in the middle four worker lanes draw each model call as a bar against a shared seconds clock, and on the right the synthesis table holds the findings and the merged answer, quoted word for word from the recording.

The task is a product decision for a small coffee subscription: should Fernbrook Coffee add fortnightly delivery at the same monthly price. The sources are a fixed pack of six short documents written for the film, so every figure can be checked: a subscriber survey, an in-app pilot, a courier quote, a finance note, a packing operations note and a list of thirty rival subscriptions. The survey says 38% would switch, the pilot saw 9.1% actually switch, and the packing line has room for 2,600 extra parcels a month, so which demand figure is right decides whether a second shift is needed. Every run was recorded on 11 September 2026 with `google/gemini-3.8-flash` through OpenRouter at temperature 0, five runs per plan, with strict JSON output from each worker. Latencies are wall-clock times measured around each request, network included.

The clean split is the case parallelism is for. Demand, cost, packing capacity and rivals are independent questions over different documents, so four workers can run at once. In the first run they finished in 2.2 seconds, against 7.2 seconds for the same four calls one after another. Then the merge took 2.6 seconds on its own. It was the slowest step in all five runs, and in one run it took 14.3 seconds, because the lead reasons over everything the workers found and writes the only long answer. Splitting shrinks the research, never the merge.

Overlapping questions waste the split. Asked for demand and for customer appetite over the same two documents, both workers came back with the same two figures, 38% and 9.1%, and in five runs the second never added a figure the first had not. It cost about 600 tokens each time. Duplicates can also mislead the merge: two findings that agree look like corroboration, when they are one reading of the same sources.

The non-obvious part is the merge. When the split is by source rather than by question, the survey and the pilot go to different workers, and neither worker sees that they disagree. Only the merge holds both. Merged by key, with one slot per question filled as workers finish, the later demand finding silently overwrote the other: the pilot’s figure in three runs, the survey’s in two, decided by which model call returned last. Handed both findings with no rule, the lead mentioned both figures in four of five runs but never once said they disagree, blending them into interest that exists, and all ten no-rule answers advised against launching. With a two-line merge rule, keep every figure with its source, and when two disagree state both, all five answers named the conflict and said the decision about a second shift depends on which figure is right.

A parallel step is as slow as its slowest branch. One worker was asked to check all thirty rivals row by row, wrote about two thousand tokens, and took between 9.4 and 12.0 seconds while the other three were done in under 2.5. Everything waited for it. With a six-second deadline, the orchestrator went ahead with the three findings in hand and told the lead which one was missing, and all five answers said so. The practical rules are the takeaway: split only questions that do not overlap, give every branch a deadline and a stated fallback, and write the merge rule before you split.

The honest caveat is scale. This is one question, six short invented documents, one model and five runs per plan, and the plans were written by hand to isolate each effect rather than produced by a model planning its own split. The rivals worker also miscounted, returning fourteen rivals with a fortnightly option where the list has fifteen, and no merge rule can catch an error that only one worker saw. Latencies include OpenRouter’s queue and vary from run to run, so the film quotes the first run and the scoreboard counts across all five.