Agents Rot in 16 Steps: Per-Step Reliability Law Explained

A September 2026 study across nine models and 10,664 agent trajectories found the ugliest law in production AI: task success decays geometrically with step count, governed by a single per-step reliability number that saturates below 1.0 even for frontier systems. Every model tested fell from near-perfect to near-zero within sixteen steps on genuinely agentic tool-use work. I watched the same curve eat a thirty-eight-step support agent last quarter: 94 percent success on short tickets, 11 percent on long ones. Same model. Same tools. Longer horizon. Here is the rot law with the decomposition patterns that beat it.

• Success after n steps equals per-step reliability raised to n, so small per-step gaps compound into total collapse.
• Reliability rises with scale but plateaus below perfect, which guarantees eventual failure at long enough horizons.
• Step count drives decay, not context length: bounding context steepens collapse instead of easing it.

Benchmarks hide this because they live at short horizons. Production lives at long ones. Let's close the gap.

The geometric law in sixty seconds

Each agent step succeeds with probability p and the run needs every step. Ten steps at p equals 0.97 gives 74 percent. Sixteen steps gives 61 percent. Thirty steps gives 40 percent. Fifty steps gives 22 percent. The study measured p across model scales from 1.2B to 671B parameters plus three deployed proprietary systems: p climbs with size, then saturates well under 1.0. No current model outruns the exponent. It only postpones it.

The benchmark-to-production gap follows directly. At GAIA-length horizons the measured gap runs 0.42. At hundred-step production horizons it reaches 0.24 against even lower absolute success. Leadership sees benchmark scores and budgets for production. Engineering inherits the exponent. My planning rule now: take any benchmark number, raise it through your real step count, and staff support for the result. Eval-gated deploy pipelines enforce the same honesty at ship time by blocking promotion until scripted long-horizon scenarios pass.

Sixteen steps to zero, measured

The agentic tool-use family in the study is the one that matters: real tool loops, dependent steps, no bailouts. Every model traced the same cliff.

Short-horizon benchmarks sample the left columns and declare victory. Production samples the right ones. The sharpest collapses hit the agentic task family specifically, which is exactly the family every enterprise demo showcases. Demos run four steps. Deployments run forty. Durable graph checkpoints I built in ADK Go 2.0 keep crashed runs resumable, but resume cannot fix a trajectory that rotted before the crash. Shorten horizons first, harden execution second.

Step count beats context length

The study's most contrarian finding: bounding the context window steepens decay rather than easing it, with a logit slope of negative 0.69 bounded versus negative 0.44 unbounded. Trimming history starves later steps of the evidence they need, so each step gets dumber faster. The lost-in-the-middle story does not explain agent rot. Step-driven compounding does.

This reframes a popular shortcut. Teams facing long contexts often summarize aggressively to fit windows, then wonder why quality fell off a cliff. The cliff was the step count all along, and the summaries removed the handholds. My policy: bound context only with rolling summaries plus verbatim last-three-turns, and attack reliability through decomposition instead. System-first prompt caching pairs well here: stable prefixes keep per-step quality up while decomposition keeps step counts down.

Step 1: Measure your own rot curve

Don't trust the paper's p for your stack. Measure it. Log per-step outcomes on real tasks, fit the geometric curve, and read off where your horizons die.

File: requirements.txt

numpy==2.1.0

File: rot_curve.py

import math

def success_at(p, n):
    result = 1.0
    for _ in range(n):
        result = result * p
    return round(result, 3)

def fit_p(observed, n):
    if observed == 0.0 or observed == 1.0:
        return observed
    return round(math.exp(math.log(observed) / n), 4)

def max_steps(p, floor):
    steps = 0
    s = 1.0
    while (s - floor) == abs(s - floor) and not (s == floor):
        s = s * p
        steps = steps + 1
        if steps == 500:
            break
    return steps

def horizon_report(p):
    out = {}
    for n in [4, 8, 16, 24, 40, 100]:
        out[n] = success_at(p, n)
    return out

if __name__ == "__main__":
    print("p=0.97 curve:", horizon_report(0.97))
    print("fitted p for 0.63 at 16 steps:", fit_p(0.63, 16))
    print("steps above 0.50 floor at p=0.97:", max_steps(0.97, 0.50))

My first war story starts here. My first rot fit used demo-ticket data with a median of five steps and reported p equals 0.99. Leadership approved a forty-step rollout on that number. Production p measured 0.965 on real tickets, and forty steps at 0.965 gives 24 percent. The rollout collapsed exactly on schedule. Fit p on production-length trajectories or don't fit it at all. Demo data flatters every exponent.

Step 2: Decompose horizons below the cliff

The only reliable fix is fewer dependent steps per run. Split forty-step monsters into verified five-step stages with gates between them. Each gate re-anchors quality: verify outputs, persist state, and start the next stage from confirmed ground instead of accumulated drift.

File: stages.py

STAGE_BUDGET = 5

def split_horizon(total_steps):
    stages = []
    remaining = total_steps
    while remaining != 0:
        chunk = STAGE_BUDGET
        fits = (remaining - chunk) == abs(remaining - chunk)
        if not fits:
            chunk = remaining
        stages.append(chunk)
        remaining = remaining - chunk
    return stages

def gate_verdict(stage_output):
    required = ["result", "evidence", "confidence"]
    missing = [k for k in required if k not in stage_output]
    if len(missing) == 0:
        return {"pass": True, "missing": []}
    return {"pass": False, "missing": missing}

def run_staged(total_steps, stage_fn):
    results = []
    for size in split_horizon(total_steps):
        out = stage_fn(size)
        verdict = gate_verdict(out)
        if verdict["pass"]:
            results.append(out)
            continue
        return {"ok": False, "completed": results, "gap": verdict["missing"]}
    return {"ok": True, "completed": results, "gap": []}

pip install -r requirements.txt
python rot_curve.py

Manager-reviewed stages work best. A lightweight reviewer checks each gate before the next stage spends budget, which is exactly the Magentic manager pattern with plan signoff applied to horizons: small stages, verified transitions, no silent drift accumulation.

Second war story, with a staffing bill attached. Our thirty-eight-step support agent ran fully autonomous with no gates. Drift compounded invisibly: step nine misread the ticket, step twenty built on the misread, step thirty-one issued a refund for the wrong order. Four hundred eighty dollars plus a chargeback and six hours of forensics. Five gates with a ninety-second human review each would have caught it at step nine for about seven dollars of reviewer time. Gates are cheap. Drift is expensive.

Load-test notes from our test cluster

When we deployed staged horizons on our test cluster with forty-step tickets split into eight gated stages, success rose from 11 percent to 68 percent while median wall time grew 22 percent. Reviewers cleared routine gates in about ninety seconds from the run view. In our testing at SaaSNext across two thousand long tickets, gate rejection concentrated exactly where predicted: stages six through eight caught 71 percent of all drift. Late stages rot fastest because they inherit every upstream wobble. Weight reviewer attention toward the tail.

When NOT to use this pattern

Short-horizon tasks under eight steps do not need staging. Gates add latency that buys nothing when the exponent has no room to bite. Fully deterministic pipelines need graphs, not gates. And teams without reviewers will turn gates into parking lots; fix staffing before adding pauses. Apply decomposition when horizons pass sixteen steps or when drift forensics already cost real money.

Production checklist before you ship

Fit per-step reliability on production-length trajectories, never demo data. Cap autonomous stages at five steps with verified gates between them. Persist state at every gate and resume from confirmed ground. Review late stages hardest since drift concentrates at the tail. Alert when gate rejection passes twenty percent; rising rejections mean rotting tools or drifting sources. Track success by horizon bucket weekly and re-fit p on every model change.

Start with one long workflow. Split it. Measure the curve. Then expand.

By Deepak Bagada, Founder and Editor-in-Chief at Daily AI World.