“95% success” reads like a solved problem. One failure in twenty, a rounding error away from reliable, surely fixable with more data.

Then you ask how many steps are in the task.

The arithmetic

Independent steps multiply. A policy that succeeds 95% of the time on each step completes a two-step task 90% of the time, a ten-step task 60% of the time, and a twenty-step task 36% of the time. Nothing changed about the policy. Only the length of the job.

The shape of that curve is the whole argument. At 99% per step you still finish four tasks in five. At 90% you finish one in eight. The gap between 99% and 90% sounds like nine percentage points and behaves like a different product category.

This is also why per-step numbers are the ones that get published. They’re the flattering frame, and they’re not wrong — they’re just not the number a buyer needs.

Independence is the optimistic case

The multiplication above assumes each step is independent: a slip at step 3 doesn’t make step 4 harder. Real manipulation doesn’t work that way.

A misplaced part changes what the next grasp sees. A slightly-off approach leaves the gripper in a pose the policy never trained on. The robotics literature is direct about this — errors, as one 2026 survey puts it, “may therefore compound and surface only later in the rollout as a larger physical safety failure.” A Stanford dissertation on deployment reliability makes the same point about composition: “reliable execution of individual behaviors does not guarantee reliable outcomes when those behaviors are composed over time.”

Neither paper offers a clean formula for how much worse than independent the real case is, and I haven’t found one that does. But the direction is not in dispute. Treat the curve above as a best case.

What that looks like when someone measures it

The 2025 BEHAVIOR Challenge is about as fair a test as this field currently has: 50 long-horizon household tasks in photorealistic simulation, requiring bimanual manipulation and navigation, averaging 6.6 minutes each, with 200 expert demonstrations per task and 1,200 hours of demonstration data in total.

The winning entry scored a q-score of about 0.26 — and a full task success rate of 0.124.

Read those two numbers together, because the gap between them is the entire point. The q-score awards partial credit. The success rate asks whether the task actually got done. The best system anyone entered, on a benchmark it could train against, finished about one task in eight.

The winners are candid about the mechanism. In their own write-up: “longer tasks simply have many more steps, which makes full success harder, but partial success remains very achievable.”

That sentence is the compounding curve, stated by the people who topped the leaderboard.

Partial credit is not a business model

A factory does not pay for 80% of a folded box. Most industrial work is all-or-nothing at the unit level: the part is placed or it isn’t, the case is packed or it isn’t. Partial credit is a research metric — a good one, because it tells you whether learning is happening at all. It just doesn’t convert.

My read is that this is where a lot of investor-facing robotics analysis goes wrong. Progress on partial-credit metrics is real progress, and it will keep looking impressive while the number that determines unit economics stays low. Those two things are not in tension. They’re the same curve seen from different ends.

What it means for the money

Last time I argued that throughput is availability divided by cycle time, and that the operator-to-robot ratio decides whether a humanoid deployment is labour arbitrage or labour relocation. Compounding is where that ratio comes from.

If a task takes twenty steps and the policy runs at 95% per step, roughly two attempts in three need a human at some point. That is not a fleet one supervisor can watch. Push per-step reliability to 99% and the same task needs intervention about one time in five — a different staffing model, a different margin structure, a different business.

The distance between those two worlds is four percentage points of per-step reliability. That is the number to watch, and almost nobody publishes it.

Where I could be wrong

Task decomposition changes the arithmetic. If a system can checkpoint — recognise a failed step, retry it, and continue — then failures stop multiplying and start costing time instead. Retry loops turn a success-rate problem into a cycle-time problem, which is a much better problem to have. Work is aimed squarely at this: the dissertation cited above introduces runtime monitors that catch impending failures “by identifying inconsistencies in closed-loop policy behavior and deviations in task progress.”

And “steps” is doing a lot of work in my framing. A twenty-step count is a modelling choice, not a measurement; a system that solves the same job in six coarser steps faces a far kinder curve. If step granularity is itself something a policy can learn, the pessimism here is overstated.

Both are testable, and both would show up in the same place: the full-task success rate, published alongside the benchmark score rather than instead of it.