The parallel agent bug that returns a wrong answer instead of an error
Branches silently overwrite each other. Most graph frameworks default to last-write-wins on a shared state key, so a fan-out that rejoins without a defined merge produces a plausible but incorrect result. Nothing throws, nothing alerts, and the client is the one who notices.
Why parallel is worth doing anyway
A linear chain serialises work that has no dependency on itself. Enrichment across five sources takes five times longer than it needs to. Fanning out and rejoining is the correct shape for most agent workloads.
What breaks at the join
Three branches each write to the same state key. Without a declared reducer, the framework takes the last one to finish. Because branch completion order is nondeterministic, the same input can produce different outputs on different runs — and every one of them looks like a valid answer.
This is materially worse than a crash. A crash is loud, reproducible and gets fixed on the day it appears. A silently wrong merge is discovered by a customer, weeks later, and by then nobody trusts any of the output.
The rules that prevent it
- Declare an explicit reducer at every join. Never rely on the default.
- Keep parallelism within a stage; keep stages sequential. You cannot model the economics of a process that has not been mapped.
- Never let two nodes write the same record.
- Sort branch outputs by a stable key before hashing or comparing, or your evaluation suite will flap and the team will learn to ignore it.
- Cap concurrency against each provider’s real rate limit, minus headroom.