You've seen it happen in design review - someone pulls out a calculator, multiplies 0.95^5, gets 0.77, and suddenly the entire pipeline architecture is dead. Three months of work pivots to agents based on eleven seconds of arithmetic.
That math is correct. But the compounding-error argument has a fatal flaw: it's computed for the option you're rejecting, never for the option you're authorizing.
Here's what actually matters:
๐๐ฎ๐ฌ๐ฌ๐๐ซ'๐ฌ ๐๐๐ฐ ๐ก๐๐ฌ ๐ ๐ฉ๐ซ๐๐๐จ๐ง๐๐ข๐ญ๐ข๐จ๐ง. The product rule for reliability only holds if stage failures are statistically independent. Nobody checks that precondition anymore. Real pipelines share inputs, models, prompts, and retry logic - stages fail together, not independently.
๐๐ก๐ ๐๐๐ฅ๐๐ฎ๐ฅ๐๐ญ๐ข๐จ๐ง ๐ข๐ฌ ๐๐ฌ๐ฒ๐ฆ๐ฆ๐๐ญ๐ซ๐ข๐. 0.95^5 = 0.77 gets computed exactly once, to kill the pipeline option. Nobody runs the same math on agent reliability, error recovery loops, or hallucination rates under dynamic execution. You're comparing a measured number against an unmeasured one.
๐๐ก๐ ๐๐จ๐ซ๐ฆ๐ฎ๐ฅ๐ ๐๐๐ฆ๐๐ง๐๐ฌ ๐ข๐ง๐๐จ๐ซ๐ฆ๐๐ญ๐ข๐จ๐ง ๐ข๐ญ ๐ง๐๐ฏ๐๐ซ ๐๐ฌ๐ค๐ฌ ๐๐จ๐ซ. Does the pipeline succeed when all stages work, or when any one works? Can later stages undo earlier mistakes? Do shared inputs create correlated failures? The calculator takes none of this as input and returns a number anyway.
๐๐๐ฉ๐๐ง๐๐๐ง๐๐ ๐๐ฎ๐ญ๐ฌ ๐๐จ๐ญ๐ก ๐ฐ๐๐ฒ๐ฌ. When stages fail together because they share an input, the correlation can actually improve reliability - a bad input fails fast instead of cascading. But you'll never know, because the arithmetic stops at 0.77.
The real decision isn't pipeline vs. agent. It's whether you've measured the actual reliability of your system under your conditions. The compounding-error argument lets you skip that work by converting an unexamined assumption into a number that looks like evidence.
Read the full analysis here:
https://ranjankumar.in/genai-architectures-level-3-compounding-error-arithmetic
Follow for more practitioner-focused architecture breakdowns.

Top comments (0)