Five Stages at 95 Percent Is Not 77 Percent

Someone opens a calculator in the design review. Five stages, ninety-five percent each, and the answer is 0.77. Once that number is on the whiteboard the room settles, the fixed pipeline is dead, and the team starts scoping an agent.

I have watched that calculation decide an architecture more than once. It takes about eleven seconds, and what follows it is usually three months of work.

That arithmetic is correct. 0.95 ** 5 really does come out at 0.7737809374999998, and nobody in the room is doing algebra wrong. My claim is about what that number is. The compounding error argument treats 0.95 ** 5 as a forecast of how the pipeline will do, when it is a forecast of P(every stage succeeds under independence), which is frequently not the event anyone in the room cares about. I am not saying pipelines are secretly more reliable than people think - I have no idea whether yours beats 0.77, and neither do you, and that symmetry is the point. Corrections to the number run in both directions by amounts nobody present has measured. And it gets computed exactly once, for the option it is used to reject, never for the option it authorises. An unsigned quantity computed for only one of two arms cannot support a comparison between them.

What the compounding-error argument actually says

This claim circulates in a few numeric dresses. Here it is at five stages, from a product director writing about agent reliability:

"Chain five agents at 95% reliability each and your end-to-end success rate collapses to 77%."

Here it is at twenty steps, from Towards Data Science in March 2026:

"A 95%-accurate agent on a 20-step task succeeds only 36% of the time. At 90% accuracy, you're at 12%. At 85%, you're at 4%."

The same piece then tells you how to read the number:

"That's one way to describe what happened. Here's another: it was arithmetic. Not a rare bug. Not a flaw unique to one company's implementation."

Arithmetic. That single word is doing all of the work here, because it moves the number out of the category of things that could be wrong and into the category of things that are simply true, and once it lands there nobody asks it for a track record.

I went looking for the canonical source. There is not one, and I could not find this argument stated in this numeric form by any first-rank named figure or major lab engineering blog. It propagates as folk arithmetic through vendor posts and practitioner newsletters, and none of the ones I read cite a source for the formula itself. That absence is not a gap in my research; it is the first piece of evidence.

Lusser's Law states an independence condition that 2026 dropped

This formula has a name and a history. Robert Lusser ran the reliability section at Redstone Arsenal under Wernher von Braun, and Lusser's Law says the reliability of a series of components equals the product of the individual reliabilities - if their failure modes are known to be statistically independent.

Read that conditional again, because it is the whole article. The precondition is an empirical claim about a specific system that somebody has to go and establish, and it is not a modelling convenience, it is the thing that makes the multiplication legal.

One honesty note about the history, since this article is about people quoting formulas without their preconditions. My sources for the conditional phrasing are a 1995 note in Safety and Reliability and the encyclopedia entry, not Lusser's own writing, which I could not reach. Whether he stated the condition explicitly or whether it is an implicit assumption of the series-system model that later authors made explicit, I cannot say from what I read. The defensible claim, and the one I am making, is that the product rule is valid only under independence and that every rigorous statement of it in reliability engineering says so.

The Towards Data Science piece invokes Lusser by name and does not carry the condition forward, and neither did any other statement of the argument I found.

The wrong way: an estimator that always returns a number

Here is the calculation as it happens in the room, written out.

def review_estimate(stage_accuracy: float, stages: int) -> float:    """The number that ends the argument. Always returns one."""    return stage_accuracy ** stages

>>> review_estimate(0.95, 5)0.7737809374999998

Nothing is wrong with the code itself, and everything that is wrong sits in the signature.

review_estimate is a total function over a domain where it should be partial. It accepts a per-stage accuracy and a stage count, and those two numbers are not enough to compute what it claims to compute. It needs to know whether the stages fail together, whether a later stage can undo an earlier stage's mistake, and whether the pipeline succeeds when all stages succeed or when any one of them does. It asks for none of that, and it returns a float regardless.

Readers of Part 2 will recognise the shape. That article named Answer Obligation: the unstated requirement that a decision path return an answer for every input it receives, inherited from the signature rather than chosen by anyone. review_estimate has it. The return type says float, the caller has no branch for anything else, so the function invents a number where its assumptions were never checked. Part 2 was about a router, and this is the same defect one level up, in the instrument you use to pick the router.

Its consequence is also the same. The caller cannot distinguish an estimate whose preconditions hold from one whose preconditions were never examined, because both arrive as a float.

Correction one: dependence, and why its sign flips

Start with the assumption Lusser named. Stage errors in a real pipeline are not independent, and the reasons are not subtle. Stages in one pipeline share an input document, and they often share a model family, a prompt lineage, a schema, and a retry policy as well. When the input is odd, several stages tend to have a bad time at once.

The closest measurement available comes from Kim and colleagues, who evaluated more than 350 language models at ICML 2025 and found that on one leaderboard dataset, two models that are both wrong are wrong in the same way 60 percent of the time. On four-way multiple choice, chance agreement conditional on both being wrong is about 33 percent, so 60 is a real signal and a smaller one than the bare figure suggests. Their more uncomfortable finding is that larger and more accurate models have more correlated errors, across distinct architectures and providers, which means the standard mitigation of putting a different vendor in each stage buys less independence than it appears to.

That is a measurement of two models on the same input. A pipeline is different models on different inputs doing different tasks, so carrying the result across is an argument rather than a measurement: shared input difficulty produces shared failure. It is the best evidence I have for the dependence premise, and it is evidence by analogy.

So dependence is real, which brings me to the part I got wrong when I started this article, and the part most people get wrong. I am not the first to notice that the compounding argument rests on assumptions nobody checks. Brando Miranda asked the same question at Stanford in May 2026, under a title that is my thesis phrased as a question, and identified the same three assumptions: a constant per-step error rate, independence, and unrecoverability. His scope is token-level autoregressive generation with verifier-guided recovery, and he does not sign the error. What follows is the workflow-level version, where the structure question exists and turns out to decide everything.

For a conjunctive pipeline whose stage outcomes are associated, end-to-end success is at least the independence product. Esary, Proschan and Walkup proved that in 1967: for associated random variables, the probability that all of them hold is at least the product of their marginals. That intuition takes a moment and then does not leave. Failures arriving together concentrate on fewer runs and leave more runs entirely clean, and in the limit of perfect correlation five stages at 95 percent gives you 95 percent end-to-end, because the same 5 percent of inputs break every stage.

Now read that bolded sentence again, because I nearly published a worse one. Association is not a synonym for positive correlation. It is a specific technical condition; association implies positive correlation and the converse fails once you have three or more variables; and nothing above establishes it for the stage outcomes of any real pipeline. Kim and colleagues measured pairwise agreement, which is a correlation statement.

So I have just done the thing this article accuses everyone else of doing. Lusser's popularisers drop an independence condition, and I was one clause away from dropping an association condition to buy myself a signed bound. That condition is an empirical claim about a specific system which somebody has to go and establish, and I have not established it either.

It matters, because negative dependence is easy to construct and common in production. A retriever tuned to return few chunks makes the answer stage easy and the citation stage hard, and tuned to return many chunks it reverses them, so the two outcomes move against each other through a shared upstream knob. Stages competing for one token budget do the same thing, since a verbose stage starves the next one. In pipelines shaped like that, conjunctive success falls below the product and the 1967 bound points the wrong way.

Correction one has no sign from structure alone. It has a sign from structure plus a dependence condition that nobody in the review has checked.

If you have ever heard someone argue that correlation makes compounding worse, they were reasoning about a different structure. Correlation does destroy redundancy. In a disjunctive system - retry, pass@k, best-of-n, majority voting, anything that succeeds if any attempt succeeds - shared causes defeat all the copies at once, and the independence formula overstates the benefit badly. That is the classical common-cause failure result, and reliability engineering models it with a beta factor: the fraction of failures that defeat every redundant channel at once. The standard illustration is three parallel channels that independence says will fail once in 10 ** 15 hours, against a reality set by a shared software bug or a single bad batch of capacitors.

A shared model family and a shared prompt lineage are beta-factor couplings with new names.

So correction one does not have a sign until you say which structure you are in. Conjunctive: the product understates. Disjunctive: the product overstates.

Two measurements, opposite directions

None of this is a blackboard argument, because both signs have been measured, in the same year, on real systems.

Evidence for the conjunctive case comes from work on conformal prediction for multi-stage pipelines. Three stages, each calibrated so that its own coverage is at least 90 percent. The independence product predicts that all three hold together 0.9 ** 3 of the time, which is 72.9 percent.

Measured joint coverage: 86.5 percent.

Evidence for the disjunctive case comes from a study of retry behaviour in agent pipelines, on SWE-bench Verified. Measured pass@1 on that set was 0.761, and if the attempts were independent then pass@3 would come out at 0.986.

Measured pass@3: 0.812.

Two systems where the independence prediction missed in opposite directions:

The first row is that paper's baseline arm rather than its proposed method, and the distinction matters: 86.5 percent is what ordinary independent per-stage calibration produced, not what the authors' pipeline-aware technique achieved.

These are different teams, different tasks, and different quantities, and conformal coverage in the first row is not task accuracy. They are not a controlled comparison and I am not presenting them as one. Neither row isolates dependence either. Each gap has at least two candidate mechanisms, dependence and marginals misspecified for the position they were used in, and neither source separates them. The retry row says as much itself: per-step error rose from 0.034 to 0.239 after a failed attempt, which is attempt two being a worse random variable than attempt one rather than a shared cause defeating independent channels.

For an article arguing that this number is unsigned, two unresolved mechanisms is not an embarrassment. It is the claim. What the pair shows is narrow and sufficient: the direction of the independence error is a property of the system, not of the formula.

The retry study also measured how much worse a contaminated attempt gets: a base per-step error rate of 0.034 rising to 0.239 after a failed attempt, a cascade ratio of about 7. If you cite the 17.4-point gap as evidence about a five-stage series pipeline, you have made the same category error this article is about. It is a pass@3 result, and it belongs to the disjunctive row.

Correction two: errors are not absorbing, and repair brings harm with it

A second assumption is that an error, once made, stays made. Real pipelines violate this constantly, because a later stage reads an earlier stage's output and quietly fixes it.

Barrak's 2025 work on role-specialised pipelines is the cleanest measurement I have found, because it defines the two events formally and then counts them. A repair is when the upstream answer was wrong and the downstream one is right. A harm is when the upstream answer was right and the downstream one is wrong, which is how a failure propagates rather than being contained.

Look at the last column. Repair beats harm in six cells out of six, so correction two does have a sign, and it points up. What varies is the size: from 40 to 1 down to 1.6 to 1, a spread of twenty-five times, across the same three models in the same two roles on the same benchmarks. Claude Sonnet 4 is the best repairer in the table as an executor and nearly the worst as a critic.

A correction that is signed but whose magnitude spans twenty-five times is no more usable in a comparison than an unsigned one. You cannot add it to 0.77 without knowing which end of that range you are on, and which end you are on is decided by which model sits in which slot.

Two things keep even that reading modest. Every cell here is a critic-or-executor pair, which is to say a pipeline built on purpose so that a later stage checks an earlier one. Your stage four is probably not a critic, so these six cells establish neither the sign nor the size of correction two for an arbitrary fixed pipeline. And the table prints six ratios without their denominators. Three cells share a harm rate of exactly 0.25 percent, which looks like one event over a common denominator rather than three independent measurements, so the 40-to-1 headline may rest on a single harm event. Part 5 had a rule for this: print the population beside the counter, or the counter gets read as a verdict. I am printing the counter and telling you I do not have the population.

A companion result on fixed pipelines separates two things that sound like one. A downstream stage can detect that upstream output is wrong and still fail to fix it. Across fourteen cohorts, the conditional miscorrection rate - given that the stage flagged a problem, how often its replacement is also wrong - ran from 53 to 94 percent, with a Wilson 95 percent lower bound above one half in thirteen of the fourteen. Detection rates themselves varied by more than an order of magnitude, from 1.3 percent to 21 percent, and one frontier model fired 7.3 times more often than another on the same benchmark.

Repair is real, and it arrives bundled with harm in a ratio you have not measured.

Correction three: the 95 percent was measured somewhere else

A third correction is the one I never hear raised.

Where did the per-stage 95 percent come from? Almost always from evaluating that stage in isolation, on clean inputs, against gold labels. That is the right way to evaluate a component. It is not the number the stage runs at inside the pipeline, because inside the pipeline the stage reads its predecessor's output, and that output is sometimes subtly wrong in ways that are not wrong enough to trip a validator.

Work presented at ICLR 2026 measured this directly and named the mechanism self-conditioning: models become more likely to make mistakes when the context already contains their own earlier errors. Per-step accuracy degrades as the step count grows, and the effect is not explained away by long-context degradation. What matters for architecture selection is that self-conditioning does not disappear as models get larger. Explicit reasoning reduces it, and scale does not.

That paper's headline argument runs against me and I should say so. Its title is The Illusion of Diminishing Returns, and its central claim is that small gains in per-step accuracy buy disproportionately large gains in achievable horizon length - which is the compounding formula taken seriously as a predictive model. My answer is that the horizon arithmetic works there because the authors measured per-step rates in situ, across the horizon, on the distribution the model was actually running on. That is the measurement the design review never makes. Their result is what the formula looks like when somebody earns it.

So the marginals you are multiplying were measured on a distribution the pipeline does not run on, and for average end-to-end accuracy that pushes true success down.

It pushes down more weakly on the quantity the formula actually computes, and the reason is worth following. p ** n is P(every stage succeeds), and on that path every predecessor was correct, so the stage is not reading an erroneous predecessor at all. Self-conditioning is largely absent on exactly the path being summed over. What survives there is format drift: an output that is task-correct but does not look like the gold input the stage was scored against. There is also a correction pointing the other way, which I have not seen priced anywhere. A stage evaluated on a full gold corpus but running only on inputs an upstream filter passed sees a narrower and easier distribution, and can run above its measured marginal.

I am not going to call this one stable either.

The Compounding Alibi: a number that justifies instead of predicting

That leaves four corrections, and it is worth laying them out plainly.

One is not a correction but a substitution of a different question. One has no sign. One is signed with a magnitude spanning twenty-five times. One has a sign that changes depending on which quantity you meant. The two measured gaps we have are thirteen and seventeen points, large enough to swamp the distance between 0.77 and most thresholds a review would set, though not large enough to carry it to 0.95.

I call this number the Compounding Alibi: a quantity produced to justify an architecture decision rather than to predict an outcome, and which nobody scores afterwards because it was never offered as a prediction. The two ideas in this article fit together in one sentence. The number is an alibi because it is unsigned and computed for one arm only - an estimate nobody can be wrong about is an estimate that can support any decision you already wanted.

An alibi is not a lie, it is a true-sounding statement that does a job other than the one it appears to do. Real arithmetic is what this is. It just is not doing forecasting work in that room, and you can tell because of what happens next: nothing. Nobody writes it down. Nobody comes back in six months to check the pipeline they built instead against the number that killed the pipeline they did not build.

Theodore Porter spent a book on why organisations reach for numbers like this one. Trust in Numbers argues that quantification is a technology for making decisions without appearing to decide, adopted most eagerly where authority is weakest and the decision most needs to look impersonal. His line is worth the whole design review:

"A decision made by the numbers (or by explicit rules of some other sort) has at least the appearance of being fair and impersonal."

An architecture review is close to that setting, though the transfer needs naming rather than assuming. Porter's mechanism is defensibility against an external challenger - a regulator, a court, a rival agency - and a design review is a room of peers, which is a higher-trust configuration. What plays the external party is the budget holder, or the post-mortem that has not happened yet. Nobody in the room has the standing to say "I think a pipeline is wrong here" and have it hold. 0.95 ** 5 says it for them, in a voice that sounds like mathematics rather than preference.

The irony runs at me too, and I would rather say it than have it said. My prescription is more numbers: a signed bound, a repair-to-harm ratio, fifty labelled runs, a dated prediction in a decision record. If Porter is right that quantification is a technology for deciding without appearing to decide, more quantification is a strange remedy. It survives, I think, on one distinction. The numbers I am asking for are ones somebody eventually has to be wrong about, and an alibi is precisely a number that nobody can be wrong about.

The strongest evidence for the alibi reading

I searched hard for a study that states a compounding-formula prediction for a specific fixed pipeline and then reports that same pipeline's measured end-to-end accuracy beside it, as a passive forecast rather than a target. I could not find one: not a paper, not a vendor postmortem, not an engineering blog. If you know of one, I would genuinely like to read it.

One paper comes close enough that I should name it rather than wait to be corrected. The million-step result discussed below states a compounding prediction, that a 1 percent per-step error rate fails within about a hundred steps, and then reports a measured outcome for the system it built. But it states the prediction as a specification to engineer against, not as a forecast of an untuned pipeline, which is the distinction the next section turns on. The cascading-errors work in natural language processing did something similar twenty years ago, modelling annotation pipelines as Bayesian networks rather than taking each stage's argmax, with Andrew Ng as third author. The problem is not new. The scoring is what is missing.

So the formula is quoted constantly and scored rarely, and in the passive-forecast form that ends architecture reviews, I could not find it scored at all. Every other number in your system has a residual somebody could compute. This one has been steering architecture decisions for years without one.

flowchart TD
    N["Stage accuracy p, stage count n.<br/>Nothing else established."] --> Q{"Which structure?"}

    Q -->|"conjunctive<br/>every stage must succeed"| C["Value is p to the n<br/>= 0.774"]
    Q -->|"disjunctive<br/>retry, pass@k, voting"| D["Value is 1 minus (1-p) to the n<br/>= 0.9999997"]
    Q -->|"not specified"| U["No value, no sign"]

    C --> R{"Failures associated?<br/>Marginals measured in place?"}
    D --> R
    R -->|"either one unknown"| U
    R -->|"both established"| S["A signed bound.<br/>Conjunctive: a floor.<br/>Disjunctive: a ceiling."]

    U --> A["The Compounding Alibi:<br/>a number that justifies<br/>rather than predicts"]

    style N fill:#FFD93D,color:#2C2C2A
    style Q fill:#7B68EE,color:#FFFFFF
    style C fill:#98D8C8,color:#2C2C2A
    style D fill:#98D8C8,color:#2C2C2A
    style R fill:#7B68EE,color:#FFFFFF
    style U fill:#E74C3C,color:#FFFFFF
    style A fill:#E74C3C,color:#FFFFFF
    style S fill:#6BCF7F,color:#2C2C2A

That diagram is the argument in one picture. The first question decides which arithmetic applies at all, the next two decide whether its answer can be signed, and the review asks none of the three.

The right way: an estimator that can refuse

Part 2 changed a routing function's return type so the caller had to look at what it was given. The same move works here, though I want to be careful about what is doing the work, because Part 2 was explicit that totality is not the distinction that matters. Provenance is. The estimator below is total too - it returns a value for every input, it just returns one that carries a record of which assumptions were checked.

Start with the arithmetic, because the two structures do not even share it.

from dataclasses import dataclassfrom typing import Literal, assert_neverStructure = Literal["conjunctive", "disjunctive"]def independence_value(stage_accuracy: float, stages: int, structure: Structure) -> float:    """What independence predicts, for the event this structure cares about."""    if structure == "conjunctive":        return stage_accuracy ** stages              # every stage must succeed    return 1.0 - (1.0 - stage_accuracy) ** stages    # any one attempt must succeed

>>> independence_value(0.95, 5, "conjunctive")0.7737809374999998>>> independence_value(0.95, 5, "disjunctive")0.9999996875

Stop on that pair, because it is worse than the unsigned problem and it is the thing I got wrong in my own first draft of this code. In a disjunctive system, 0.95 ** 5 is not a pessimistic estimate of success. It is the probability that all five attempts succeed, which is a quantity nobody running a retry loop has ever wanted to know. The number the room should be looking at is 0.9999996875, and the room is looking at 0.774. Not off by a correction term. Off by an event.

Now the estimator.

@dataclass(frozen=True)class Bound:    value: float    direction: Literal["lower", "upper"]    because: str@dataclass(frozen=True)class Unsigned:    value: float    reasons: tuple[str, ...]Estimate = Bound | Unsigneddef compounding_estimate(    stage_accuracy: float,    stages: int,    *,    structure: Structure | None,    failures_associated: bool | None,    marginals_measured_in_pipeline: bool | None,) -> Estimate:    """Return the independence value, signed only when all three facts are in.    Every keyword is a question the design review does not ask. `None` means    nobody has established it, which is the normal case rather than the    unusual one.    """    if not 0.0 <= stage_accuracy <= 1.0:        raise ValueError(f"stage_accuracy must be a probability, got {stage_accuracy}")    if stages < 1:        raise ValueError(f"stages must be at least 1, got {stages}")    if structure is None:        return Unsigned(            stage_accuracy ** stages,            ("structure not given; this is P(all stages succeed)",),        )    value = independence_value(stage_accuracy, stages, structure)    reasons: list[str] = []    if failures_associated is None:        reasons.append("dependence not characterised")    elif not failures_associated:        reasons.append("failures not associated; 1967 bound void")    if not marginals_measured_in_pipeline:        reasons.append("marginals measured off-distribution")    if reasons:        return Unsigned(value, tuple(reasons))    if structure == "conjunctive":        return Bound(value, "lower",                     "associated failures cluster (Esary 1967)")    return Bound(value, "upper",                 "association defeats redundancy (same theorem)")

Both signed branches come from the one 1967 theorem, which is tidier than it looks. Association gives P(all succeed) at or above the product, and it gives P(all fail) at or above the product of the failure marginals, so P(any succeeds) sits at or below the independence value. One premise, both directions. The beta-factor model is a way to put a number on the second case, not a second source for it.

Reading it back:

def read(estimate: Estimate) -> str:    match estimate:        case Bound(value=v, direction="lower", because=why):            return f"at least {v:.7f} - {why}"        case Bound(value=v, direction="upper", because=why):            return f"at most {v:.7f} - {why}"        case Unsigned(value=v, reasons=rs):            return f"{v:.7f}, unsigned: " + "; ".join(rs)        case unreachable:            assert_never(unreachable)

Run it with what the design review actually knows, which is the stage accuracy and the stage count and nothing else:

>>> est = compounding_estimate(0.95, 5, structure=None,...                            failures_associated=None,...                            marginals_measured_in_pipeline=None)>>> est.value0.7737809374999998>>> est.reasons('structure not given; this is P(all stages succeed)',)

And with the two facts a team most often half-has:

>>> read(compounding_estimate(0.95, 5, structure="conjunctive",...                           failures_associated=None,...                           marginals_measured_in_pipeline=False))'0.7737809, unsigned: dependence not characterised; marginals measured off-distribution'

Both reasons come back, not the first one to fail. A caller who is told about one gap, fixes it, and gets told about the second on the next call has been given a worse experience than one who sees the bill in full.

The number never disappears. It is in the value field of every return, and anyone who wants it can read it. What the caller can no longer do is mistake it for a bound, because the reason field says which questions went unanswered.

What the return type actually buys

Here I owe you the comparison Part 2 insisted on when it built route_total_fair rather than crediting its refusal path with gains that came from writing better rules. The same confound is available to me: compounding_estimate adds input validation, structure-aware arithmetic, three parameters and a reason string, and it would be easy to attribute the whole improvement to the union return type.

So here is the fair comparator, which keeps every one of those improvements and returns a bare float.

import warningsdef compounding_estimate_fair(    stage_accuracy: float,    stages: int,    *,    structure: Structure | None,    failures_associated: bool | None,    marginals_measured_in_pipeline: bool | None,) -> float:    """Same questions, same arithmetic, same warnings. Still returns a float."""    if structure is None:        warnings.warn("structure not specified; returning P(every stage succeeds)")        return stage_accuracy ** stages    if failures_associated is None or not marginals_measured_in_pipeline:        warnings.warn("estimate is unsigned; see docstring")    return independence_value(stage_accuracy, stages, structure)

That gets most of it. It fixes the arithmetic, which was the serious bug, and it says the word unsigned out loud. What it does not do is survive a caller who does not read warnings, and warnings are the most ignorable thing in Python after a comment. The union return type buys exactly one thing over this: a caller that type-checks cannot put the value in a comparison without first deciding what a refusal means. That is a narrow purchase and it is the whole purchase.

There is an easier objection than any of that, and it deserves an answer. Rename review_estimate to independence_product and its defect largely dissolves, because the name now says which event it computes. True, and it fixes the function. It does not fix the whiteboard, where the float still arrives unaccompanied and the person reading it out has not been asked anything.

When the formula is right

The compounding argument has a defence, and it is a good one.

In November 2025, a team at Cognizant AI Lab and UT Austin solved a twenty-disk Towers of Hanoi with a language model. That is 1,048,575 sequential steps, executed with zero errors, using GPT-4.1-mini. They open by taking the compounding model completely seriously: a system with a 1 percent per-step error rate is expected to fail after about a hundred steps, so a million-step task should be impossible.

They got there by engineering the assumptions into existence. Maximal decomposition so each step is tiny, a fresh context per step so errors cannot condition later ones, first-to-ahead-by-k voting, and explicit red-flagging to reduce correlated errors. Measured per-step error came out at 0.22 percent.

Do the arithmetic on that pair and it looks impossible, which is the point. A 0.22 percent raw error rate over 1,048,575 sequential steps predicts failure with a certainty that has no useful decimal representation. The raw rate is not the executed rate: the voting layer sits between them, and it is what closed a gap of roughly two thousand orders of magnitude. On the unengineered system the compounding formula was perfectly predictive. The engineering is what defeated it.

Read that as the strongest possible version of the counter-argument, because it is. The formula is a valid design constraint for a system deliberately built to satisfy its assumptions. It tells you what independence and non-recoverability would buy you, and if you are willing to pay for fresh contexts and k-way voting on every step, it becomes predictive.

That is the opposite of how it gets used. In the design review it is applied as a passive forecast to a system nobody has decorrelated, nobody has decomposed, and nobody has measured. The million-step result is evidence for the formula as a specification. It is not evidence for the formula as a prediction about your untuned pipeline.

The honest counter-argument

The strongest objection to this article is that I am arguing about error bars while pipelines are genuinely failing, and that the compounding intuition is directionally right even if the arithmetic is unearned.

Real evidence supports that objection. A reliability study across ten models, 396 tasks and 23,392 episodes found graceful degradation scores in software engineering falling from 0.90 to 0.44 as task duration grew. Long-horizon degradation is not imaginary.

But look at what the same study found next to it. Document processing held at 0.74 to 0.71 over the same duration increase, on a composite graceful-degradation score rather than an accuracy, so neither figure can be read as a per-stage p.

Reliability decay is domain-stratified. That does not by itself refute the one-p assumption, since the formula assumes one rate across stages within a pipeline and not one rate across domains. What it does establish is that decay has structure the formula does not model, and the within-pipeline version of that structure is the one that bites: stages of genuinely different difficulty, which is every pipeline anyone has built.

A second objection is sharper, and it comes from someone who has done a measurement. Writing in August 2026 about a structured planning benchmark, Craig Wright concludes that compounding error is "real, and not the binding constraint at the top of the range." His numbers: for the strongest model, planning errors ran at 0.11 per task against execution errors at 0.02, roughly five to one, and 29.4 percent of tasks failed on gear selection alone with clean execution. It is a single-author benchmark published two weeks before this article, with self-reported numbers from one structured world, so weigh it accordingly.

Weighed accordingly, he has found a correction I left out, and it is the most actionable of the lot. His argument is that n itself is overstated: loops and repeated structure collapse a thousand actions into perhaps thirty genuinely independent decisions, so the exponent is wrong before the base is even discussed. That correction has a stable sign and it points up.

Add it to the table above and the picture gets worse rather than better. Now two corrections are signed and they point in opposite directions, with unmeasured magnitudes on both. Wright and I have the same target and different verdicts, and the difference is exactly this: he prices his correction and concludes the formula overestimates failure, which is a signed claim replacing one forecast with a better one. I am claiming that once you price all of them, nothing is left to compare with. His position is the more useful one when somebody has characterised the structure. Mine is the more useful one when nobody has, which describes every design review I have sat in.

How this connects to the Zero Row and the Induction Gap

Part 2 introduced the Zero Row: what you get when you measure the deterministic implementation of a task before any model exists, recording both its cost and its refusal rate. Every later claim that a rung improved something is a comparison against that row.

The compounding argument is a claim about a rung with no row under it. It compares a pipeline that was never built against an agent that was never built, using a number derived from stage accuracies measured on a distribution neither system will run on. There is no measurement anywhere in it.

Part 5 named the Induction Gap: you cannot assemble evidence to remove a rung, because your logs only contain traffic that ran with the rung in place. Part 5 also said that adding a layer is authorised by a single case, an existence claim, which is the cheap direction.

Level 3 is the case Part 5 did not cover. Here the addition is authorised by no case at all - not one observed failure of the pipeline, because the pipeline was never built. Only arithmetic, computed once, for the option being rejected. Descending has no artifact. Climbing has one, and it is frequently counterfeit.

Both parts land on the same uncomfortable place. A ladder you cannot justify climbing and cannot justify descending is not a ladder you are choosing to stand on. It is one you happened to stop on.

What to do in the room instead

None of this is about winning a design review by citing a 1967 theorem. It is to replace an eleven-second calculation with a slightly longer one that can be wrong.

1. Ask which structure the pipeline is. Does every stage have to be right, or does one attempt out of several have to be right? Until that is answered, the product has no sign, and the answer is often "both, in different places" - a conjunctive spine with a retry loop in stage three. Those two halves need different arithmetic.

2. Ask where the per-stage accuracy was measured. If it came from evaluating that stage on gold inputs, it is not the rate the stage will run at behind another stage. Say so out loud. It is the one correction with a reliable direction, and it points down.

3. Measure repair and harm before arguing about compounding. Run fifty inputs through the pipeline you already have, label each stage's output and the final output, and count the runs where a later stage fixed an earlier one and the runs where it broke a correct one. Fifty gives you a direction, not a rate. The published spread across model-slot assignments is twenty-five to one, so the direction is worth an afternoon.

4. Write the prediction down before you build the alternative. If the arithmetic says 0.77 and it is load-bearing enough to change the architecture, put it in the decision record with a date. Then measure the thing you built instead. This is the step that has apparently never been performed by anyone, and doing it once would make you the first.

5. Do not let the number decide a rung on its own. A pipeline that cannot hit its target is an argument for fixing the stage that misses, or for adding a verifier, or for the decomposition-and-voting design that got a million steps right. It is not automatically an argument for autonomy. An agent has correlated errors too, it repairs and harms too, and its per-step rates were also measured somewhere else.

Point five is the one that matters most, and it is the one the arithmetic obscures. The corrections that make 0.95 ** 5 unsigned do not go away when you climb. They apply to the agent you build instead, in the same directions and for the same reasons, and nobody recomputes the number for the rung they are moving to. The calculation gets performed exactly once, against the option it is used to reject.

Why Level 3 gets rejected by a number nobody scored

Level 3 gets rejected more often than any other rung on this ladder, and it gets rejected by a number that has never been checked against an outcome.

I am not asking anyone to trust fixed pipelines. I am asking for the arithmetic to be held to the standard we hold every other number in a production system to, which is that somebody eventually finds out whether it was right. Compute the product, then say which direction its error runs and why. If you cannot say, the honest output is the number plus the sentence "this is unsigned," and a team that hears that sentence will make a different decision than a team that hears "seventy-seven percent."

Reliability engineering has always carried the condition alongside the law. Recovering it costs one clause.

Eleven seconds bought a number that felt like a fact. The pipeline it killed was never measured, the agent it authorised was never compared against it, and the calculation was never scored. That is not a modelling error; it is a decision that was already made, wearing arithmetic as an alibi.

References

• Esary, J. D., Proschan, F. and Walkup, D. W. (1967). "Association of Random Variables, with Applications." The Annals of Mathematical Statistics 38(5):1466-1474. https://projecteuclid.org/euclid.aoms/1177698701
• Tait, N. R. S. (1995). "Robert Lusser and Lusser's Law." Safety and Reliability 15(2). https://www.tandfonline.com/doi/abs/10.1080/09617353.1995.11690648
• Lusser's law. Wikipedia. https://en.wikipedia.org/wiki/Lusser%27s_law
• Rausand, M. Root Causes and Coupling Factors; CCF Definition; Beta-Factor Model (course notes, chapter 6). NTNU. https://www.ntnu.edu/documents/624876/1277590549/chapt06-ccf.pdf/760263e4-db1e-46fb-8501-c34faec7aeca
• Kim, E., Garg, A., Peng, K. and Garg, N. (2025). "Correlated Errors in Large Language Models." ICML 2025. arXiv:2506.07962. https://arxiv.org/abs/2506.07962
• Kotte, V. (2026). "PASC: Pipeline-Aware Conformal Prediction with Joint Coverage Guarantees for Multi-Stage NLP and LLM Pipelines." arXiv:2605.18812. https://arxiv.org/html/2605.18812
• Yang, Z. (2026). "Why Retrying Fails: Context Contamination in LLM Agent Pipelines." arXiv:2605.08563. https://arxiv.org/html/2605.08563
• Barrak, A. (2025). "Traceability and Accountability in Role-Specialized Multi-Agent LLM Pipelines." ASEW 2025. arXiv:2510.07614. https://arxiv.org/abs/2510.07614
• Nilayam, P., Ramanna, K. and Tumbade, P. (2026). "Detection Without Correction: A Two-Parameter Decomposition of Multi-Stage LLM Pipelines." arXiv:2605.27559. https://arxiv.org/html/2605.27559v1
• Sinha, A., Arun, A., Goel, S., Staab, S. and Geiping, J. (2026). "The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs." ICLR 2026. arXiv:2509.09677. https://arxiv.org/abs/2509.09677
• Meyerson, E., Paolo, G., Dailey, R. et al. (2025). "Solving a Million-Step LLM Task with Zero Errors." arXiv:2511.09030. https://arxiv.org/html/2511.09030v1
• Khanal, A., Tao, Y. and Zhou, J. (2026). "Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents." arXiv:2603.29231. https://arxiv.org/abs/2603.29231
• Finkel, J. R., Manning, C. D. and Ng, A. Y. (2006). "Solving the Problem of Cascading Errors: Approximate Bayesian Inference for Linguistic Annotation Pipelines." EMNLP 2006, 618-626. https://aclanthology.org/W06-1673/
• Porter, T. M. (1995). Trust in Numbers: The Pursuit of Objectivity in Science and Public Life. Princeton University Press. https://press.princeton.edu/books/paperback/9780691208411/trust-in-numbers
• Schluntz, E. and Zhang, B. (2024, December 19). Building Effective AI Agents. Anthropic. https://www.anthropic.com/engineering/building-effective-agents
• Rajan, K. (2026, March 20). The Math That's Killing Your AI Agent. Towards Data Science. https://towardsdatascience.com/the-math-thats-killing-your-ai-agent/
• Chavez-Mattos, L. (2026, May 17). Multi-Agent Reliability Math: Why Chaining 5 Agents Drops Success Rate to 77%. MindStudio. https://www.mindstudio.ai/blog/multi-agent-reliability-compounding-problem-77-percent
• LatentEval (2026, April 18). Multi-agent LLM failure modes, and how to contain error propagation. https://latenteval.ai/analysis/multi-agent-failure-modes
• Miranda, B. (2026, May 26). Autoregressive Models + LLMs Exponential Error-Compounding Argument - Is It Real or Fiction? Stanford CS. https://cs.stanford.edu/people/brando9/2026/05/26/ar-error-compounding-real-or-fiction.html
• Wright, C. (2026, August 8). One Wrong Premise, Faithfully Executed. https://singulargrit.substack.com/p/one-wrong-premise-faithfully-executed
• Kumar, R. (2026). The 7 GenAI Architectures: A Field Guide to Choosing the Right AI System - Before You Overbuild It. Chapter 6, "Architecture 3 - The LLM Workflow." https://7genai.ranjankumar.in/

Related Articles

AI Engineering

• Why Your RAG Chunks Are Lying to Your Retriever

System Design

• Why Your Default Branch and Your LLM Are the Same Architecture
• Descending: Why You Cannot Delete an Idle AI Agent Layer
• The 7 GenAI Architectures Every AI Engineer Should Know