March of Nines

Reliability engineering has long described availability targets by their number of nines. The earliest exact phrase found in this review is Elon Musk's `long march of nines` on Tesla's July 2020 earnings call about autonomous driving. In October 2025, Andrej Karpathy applied the metaphor to software agents, saying that years at Tesla made him skeptical of demos and that successive reliability levels each demanded another substantial block of work.

Sources: s1, s2, s3

Averages conceal the production gap. A workflow may look useful while its failures cluster in unusual users, tool states or long task chains. The metaphor directs teams to define success at the end-to-end task level, measure failure severity as well as frequency, inspect long tails, and budget for recovery, monitoring and escalation. It also challenges forecasts that infer deployment speed directly from a prototype's apparent capability.

Sources: s2, s4, s5, s6

A team evaluating a support agent could freeze a representative task set, record tool calls and final outcomes, separate harmless formatting mistakes from unauthorized actions, and rerun the suite after every change. Arithmetic, policy checks and state transitions that can be deterministic should leave the model path. Residual failures need validators, retry limits, observability and a human handoff instead of an unsupported claim that a benchmark percentage makes the agent production-ready.

Sources: s3, s4

The metaphor must not be read as a mathematical law. Adding a nine reduces the remaining error rate by an order of magnitude; it does not prove that labor, calendar time or cost rises by exactly 10x. Multiplying per-step probabilities is valid only under the stated model, especially independence, and can mislead when errors are correlated, retried, detected or recoverable. Availability nines measure service uptime, whereas an agent may be available yet semantically wrong. Required reliability depends on task distribution, failure consequence and human safeguards; safety-critical release decisions need domain-specific evidence and review.

Sources: s2, s3, s4, s5