September 3, 2026
Parallel generations that do not scramble the timeline
Ask for three images and the agent really does request all three at once. Letting them land in whatever order they finish builds a different video every run.
"Generate three images: a lighthouse, a harbour and a fishing boat" comes back from the director as three generation calls in one step. Running them one after another is slow. Running them all at once is wrong. Both of those turned out to be worth taking seriously.
The obvious danger, and the subtle one
The obvious danger is corruption. Every generation ends in a read-modify-write: find where the track ends and then append, or read the whole layer stack and then reorder it. Overlap two of those and either two clips claim the same start time, or one reorder silently throws the other away.
The subtle danger is ordering. Whichever provider answers first lands first, so the same sentence builds a different video on every run. We proved it to ourselves: with parallelism on and the ordering gate removed, our test timeline came back as
[boat, harbour, lighthouse], exactly reversed, because the fake latencies were seeded backwards.Non-determinism you can't see is the worst kind. Nothing errors. The video just isn't quite the one you asked for, and only sometimes, which is how you lose an afternoon.
So the waiting overlaps and the commit doesn't
Generations start together and wait together, but the change each one makes is applied strictly in request order. A slow first request still commits before a fast second one. You get the latency of the slowest generation instead of the sum of all of them, and a timeline identical to the sequential version.
Held in place by a test that fails two ways
The regression test fails if the work goes back to being sequential, and fails differently if it goes parallel without the ordering gate. A single-assertion test would have passed happily on the day someone optimised the gate away.
Opt in, not on
Parallelism is opt-in per tool instead of a global switch. A tool only qualifies when its commit is genuinely order-independent, or when it goes through the ordered path. The default stays sequential, because the cost of being wrong here is a film that's quietly not the one you built.