Can a robot learn to fix its own failed coffee runs without a human showing every step?

Why a dropped cup is not just a missed grasp

A slipped object in a long household task can hide three different mistakes. The robot may have chosen the wrong next action, missed part of the scene, or executed a sound plan badly enough to drop the item. The difficulty is that a household task does not stay still. Goals may shift when the user gives a new instruction, while the robot sees only part of the world and its grasp can fail for physical reasons.

Grasping, pouring, or reaching are attempts that the world may reject. Each turn follows a fixed causal order, in which the agent sends an action before the world changes and feedback arrives. Only after that does the robot receive its next observation. Feedback comes from the state actually reached after execution, not from whether the chosen action was logically valid. A good plan can still produce failure because of physical execution, while a bad plan can sometimes produce plausible-looking feedback if the world happens to move in an expected way.

The hidden task has a goal and active rules that change only when a new instruction arrives. Tool feedback updates what is known about the world, but it does not itself alter the goal or the rules. Some structured attributes are maintained by the system, fully observed, and updated deterministically from actions and events. The simulated benchmark contains 279 held-out tasks across four household-style scenarios: making coffee, warehouse sorting, laundry, and color sorting. Tasks run from 3 to 18 high-level actions, so a single early slip can sit inside a much longer chain.

A fixed recovery suite of 60 tasks injects execution errors such as missed detections, failed grasps, or unreachable-object feedback. Recovery asks whether the agent can still complete the active subgoal after that error. This separates local repair from full-task success. A method may finish more disturbed steps and yet still lose later stages because accumulated errors change what the robot believes it has done.

A hidden coach proposes fixes and the simulator tests them

When a robot plan breaks in simulation, the system does not accept the first explanation it hears. A privileged coach watches the failure with information that the deployed policy cannot see, such as the active goal or a rule that has just changed. It points to an earlier decision where things likely went wrong. The coach offers one of two repairs, replacing the suspected bad action with another valid high-level move or inserting a recovery step after the failed moment.

Each proposed fix is treated like a hypothesis, not a command. The simulator returns to the exact physical state before the failure and reruns the candidate under matched conditions. Disturbances and observation noise are sampled once for that stage and held fixed across sibling branches, so differences in outcome come from the chosen action rather than from luck. The original failed path and each repaired path grow into a small tree of possible continuations.

This testing step is what keeps the coach honest. A repair may look sensible while still leading to another missed grasp or an impossible placement. In the simulated comparison, a policy that learned from these tested repairs reached a 26.25 percent recovery rate on a fixed suite of tasks with injected execution errors, about 9.6 percentage points above the strongest retry-based baseline.

Only branches that improve progress become training data

A failed rollout does not become useful training material by default. At each reached state, the pipeline considers several candidate actions, whether they came from the policy or from a proposed repair. For every candidate, multiple continuations are run forward using the current policy. Each continuation then faces the same stage-level uncertainties that were sampled once for all sibling branches.

The candidate is scored by how often those continuations complete the relevant task stage. Only the single best-scoring action at a state is kept as a training example, and it is kept only if its validated continuations succeed at least once. States where no available action leads to any downstream success are discarded rather than used for training. This rule ties supervision to observed improvement instead of trusting a diagnosis alone. A policy-generated answer can win if its continuations work better than a proposed repair.

To keep the rollout tree manageable, successful partial trajectories are released stage by stage rather than pushed through an entire long task. At each stage, a pool of successful branches is kept, but only a limited set becomes parents for the next stage. Branches that share nearly identical earlier decisions are down-sampled so one early choice does not dominate. If later stages run short of viable parents, the limit is relaxed and more upstream branches continue. This avoids both exponential branching and premature collapse onto a single trajectory.

The filtering helps explain why the pipeline reaches the best mean recovery rate in simulation, at 26.25 percent. It beats the strongest baseline by about 9.6 percentage points while using a smaller rollout model. The same policy also records 16.79 percent cumulative success and 30.74 percent completed-goal fraction before the first unrecoverable failure. Absolute long-horizon success remains low for every method, because errors compound over sequences of up to 18 high-level actions. Partial observation and execution uncertainty make each step a place where small mistakes can spread.

A failed grasp, checked twice, becomes training data

The most useful lesson is that robots can learn from mistakes when those mistakes are checked before they become training data. A hidden coach points to a bad decision and proposes a small repair. The system then replays the moment in simulation to see whether the repair helps. That test turns guesswork into evidence. Only fixes that improve later progress survive, so the policy learns from failures it could plausibly meet again.

Household work shows why recovery is a bigger prize than flawless execution, because long tasks contain small breaks such as missed objects, failed grasps, or changing rules. A robot that recovers from one break may finish more of the task, even if it still fails at the end. The simulated results show this pattern, with better recovery and longer progress before an unrecoverable stop. On real hardware, gains shrink because perception and grasping keep producing new errors that no high-level plan can fully absorb.

The opportunity is a training path that grows from compact task definitions rather than hours of human recording. The obstacle is that validation still leans on simulation, hidden information, or a way to return to an earlier state. If future systems can verify repairs in the physical world without privileged access, failure data could become a steady source of improvement instead of a pile of confusing examples.