From sequential to parallel

Automating one step inside an unchanged process buys you an incremental gain and sometimes a slower system. The larger win comes from asking which dependencies are real — and running the rest at once.

Scope, honestly: The redesigns described here are ones I built and measured on my own systems. In an enterprise process the analysis is the same; the constraint is organisational agreement, which I have negotiated in delivery but not for an AI programme.

The most common disappointing AI result has a recognisable shape: the process was left exactly as it was, one step inside it was automated, and the overall gain was a few percent. Occasionally the result is negative, because a review step was added around the automated part and the queue got longer.

The reason is that most business processes are sequential for historical reasons, not logical ones. Step B waits for step A because a person did both, or because a system in 2009 could not hold state, or because the sequence encodes an approval hierarchy nobody has revisited. When the executor stops being a single human, most of those dependencies dissolve — but only if someone goes looking for them.

The questions that break a sequence open

Which dependency is real? B genuinely needs A’s output, or B has simply always come after A?
What if waiting were zero? Design the process for zero latency and see what the shape becomes; then work backwards to what is achievable.
What if no human touch were required at this step? Not as a target — as a thought experiment to expose which touches are controls and which are habits.
Is this check a control or a comfort? Some manual verification is genuinely load-bearing. Some exists because removing it would feel reckless, which is not the same thing.
What is the hidden cost of the current shape? Usually a queue: the customer who abandons, the decision that arrives after it mattered.

What I did

Generation and validation, fanned out. Building a large bilingual body of structured content, the obvious design was a loop: generate an item, check it, fix it, move on. It would have worked, and it would have taken a very long time. The redesign split the corpus into batches and ran generation across parallel agents, then ran a separate validation pass across a second, larger fan-out. The sequence that mattered — generate, then validate, then repair — was preserved as a contract; the sequence that did not — item after item — was discarded. Throughput went from a day-scale problem to a minutes-scale one, and, importantly, the validation stage got better rather than worse, because running it as its own pass meant it could apply consistent criteria instead of drifting item by item.

A verification chain that stopped gating itself. In an extraction pipeline, one eligibility decision had been wired as an AND across two independent signals: a text match and an image-derived match. It read as prudent — two confirmations are better than one. In practice it meant that whenever either signal was weak, a correct result was thrown away. The fix was to stop treating the chain as sequential gates and let each signal contribute on its own terms, with the weaker one no longer able to veto. Same components, different topology, materially better output.

And a redesign I reversed. Parallelising is not free. On one path I split work that shared downstream state, and the result was two branches making incompatible corrections to the same record — a race that produced plausible, wrong output rather than an obvious failure. I reverted it and kept that step sequential. The lesson stuck: the question is not “what can run at once” but “what can run at once without sharing mutable state”. Parallelism that corrupts is worse than a queue that is slow, because a slow queue announces itself.

What this stage produces

A process map with every dependency labelled either requirement or history, the sacred cows named, and the redesigned flow costed against the old one. The deliverable is not “we added AI to step four”. It is “this process has three real dependencies instead of eleven, and here is what that is worth”.

How this transfers

Complex enterprise processes — due diligence, claims handling, onboarding, procurement review — are almost always sequential by inheritance. The analysis above scales directly; what changes is that each removed step has an owner who will want to know why, and each parallel branch needs an explicit answer for what happens when two branches disagree. That is a governance question as much as a design one, and it belongs in the plan from the start rather than being discovered in the pilot.