The 99 percent trap

Ninety-nine percent sounds like the end of the engineering. It is the number that closes the pilot, the score on the vendor slide, the moment a team decides the agent is ready. Now give that agent something long. A task of 1,000 steps, each one done correctly 99 times out of 100, finishes clean with probability 0.99 multiplied by itself a thousand times: roughly 0.004 percent. Four clean runs in a hundred thousand attempts. That is the trap. An agent that is almost always right, pointed at a task that is long enough, becomes a machine that almost always fails.

This is a field synthesis with an unusual evidence profile, so we will be precise about it up front. The arithmetic that carries the first half of this article is ours: plain multiplication, checkable on any calculator, requiring no authority. The result that carries the second half is one research team's reported finding, on a synthetic benchmark, in a preprint that has not yet passed peer review. We use the first as fact and the second as principle. Together they explain the most common disappointment in working with AI agents: why a system that feels reliable in a demo fails almost every long job it is actually given.

Section OneThe arithmetic nobody runs

Start with the only equation in this piece. If each step of a task succeeds independently with the same probability, the chance the whole task succeeds is that probability multiplied by itself once per step. Everything else follows from watching that product decay.

Take an agent that gets each individual step right 99 percent of the time. Two steps: 0.99 × 0.99, about 98 percent. Ten steps: about 90 percent. So far the intuition holds: small losses, still a working machine. Then the curve turns. By 69 steps, the cumulative odds drop below one half: the "reliable" agent is now a coin flip. By 1,000 steps, the scale of a genuinely long agent run, the success probability is 0.99 to the thousandth power: about 0.0000432, or 0.004 percent. Type 0.99^1000 into any calculator. We will wait.

You do not need a thousand steps for the trap to close. A twenty-step process (an invoice intake, a customer onboarding, a monthly report assembled from a dozen systems) run by an agent that is right 95 percent of the time per step, completes cleanly about 36 percent of the time (0.95²⁰ ≈ 0.3585). Roughly two runs in three break somewhere along the chain.

And raising the per-step number barely helps. An agent that is right 999 times in 1,000 (a spec most production systems would envy) still finishes a thousand-step task only about 37 percent of the time (0.999^1000). To get back to a mere coin flip on 1,000 steps, per-step accuracy has to reach about 99.93 percent. All of this is our own arithmetic, deliberately: there is nothing here to trust and nothing to peer-review. It is multiplication.

The agent didn't get dumber at step 400. The odds ran out.

Section TwoA systems property, not a model property

The instinct this arithmetic usually triggers is to wait: the next model will be smarter, and the problem will dissolve. The multiplication says otherwise. Model progress raises the per-step number, and the per-step number is the wrong lever: the exponent is doing the damage. As long as one error anywhere can sink the whole run, every long task lives on the steep part of the decay curve, whatever the model.

Which means the reliability of a long task was never a property of the model at all. It is a property of the system around the model: how the work is cut into steps, what gets checked between them, and what happens when a step goes wrong. Those are not machine-learning questions. They are the oldest questions in management (job design, quality control, escalation) wearing new hardware.

Section ThreeA million steps, zero errors

In November 2025, a team from Cognizant AI Lab and the University of Texas at Austin, led by Elliot Meyerson, posted a preprint whose central claim reads like a typo against the arithmetic above: they describe, in their own words, "the first system that successfully solves a task with over one million LLM steps with zero errors." Not a million steps with acceptable losses. Zero errors.

arXiv, E. Meyerson et al. (Cognizant AI Lab & UT Austin), "Solving a Million-Step LLM Task with Zero Errors," arXiv:2511.09030, submitted November 12, 2025.

The system is called MAKER, and the acronym is the method: Maximal Agentic decomposition, first-to-ahead-by-K Error correction, and Red-flagging. Translated out of paper-speak: the task is shredded into the smallest steps the authors could define, each handled by its own microagent; every step's answer is decided by a vote among several independent attempts, accepted only once one answer pulls K votes ahead; and attempts that show suspicious signs are thrown out and re-run rather than argued with. The authors' one-sentence summary of the mechanism is the line worth keeping: "The high level of modularity resulting from the decomposition allows error correction to be applied at each step through an efficient multi-agent voting scheme."

Two qualifiers, stated plainly, because they matter. The benchmark task is synthetic (constructed so that a million steps can be defined and verified at all), and the paper is a preprint, not yet peer-reviewed. We are not citing it as proof that your workflow can run error-free tomorrow. We are citing it for the principle it demonstrates: the gap between 0.004 percent and a clean million-step run was closed without a smarter model. The models involved were ordinary. The architecture was not.

The gap was not closed by intelligence. It was closed by never letting one error travel.

Section FourThe management translation

Strip the acronym and MAKER's three moves are three management decisions, each of which a competent operations lead has made before, just never about software.

Decomposition is job design. Cut the work until each step is small enough that "correct" can be checked at a glance: one decision, one transformation, one answer. A step you cannot verify is a step you have chosen not to manage.

Voting is independent verification. No output counts because the worker says it is done. Several independent attempts must agree before an answer enters the record. That redundancy sounds expensive until you price the alternative: at machine costs, running a small step five times is cheap; re-running a failed thousand-step task is not.

Red-flagging is a stop-condition. When an attempt looks wrong (malformed, overconfident, out of pattern), the system does not coax it toward a fix. It kills the attempt and starts fresh. Abandonment is made cheaper than persuasion.

The practical move for anyone running agents today is not to rebuild MAKER. It is to steal its posture. Write the steps down. Define "done" per step, not per project. Put a check between steps that the worker cannot skip. And make throwing a bad run away cheaper than debating with it. Every one of those is a decision a manager can take this week, with the models already in the building.

Section FiveDecomposition is legibility

Here is the through-line to everything else we publish. A task an agent can actually succeed at is a task whose steps, checks and stop-conditions have been made small and readable. That is not a coincidence of engineering; it is the same property we keep pointing at from the outside of companies. Decomposition is legibility: the discipline of making work readable to the machine that has to do it.

We run our own studio on agents, and we run it on this arithmetic. The tasks that succeed here are never the heroic thousand-step prompts; they are the numbered stages with a human gate between them, each stage small enough that a failure is visible before it travels. When a run fails, the question we have learned to ask is not "why was the agent dumb" but "which step was allowed to be this long." The answer is usually embarrassing, and always fixable.

In ClosingThe machine reads before it works

Machines can only act on what they can clearly read. Outside your company, that decides whether AI assistants can see your brand at all when a buyer asks. Inside your company, it now decides whether your agents can finish what you hand them: a legible task survives its own length, an illegible one is eaten by multiplication. The winners of the agent era will not be the teams with the smartest model. They will be the teams whose work was readable enough to be done a small, checkable step at a time.

If you want to know how legible you already are to the machines on the outside, you can measure it at /signal-index/. Or write to us at /contact/.