The assignment sounded almost comically ordinary: put condiments on the top shelf of a fridge. But in a simulated kitchen, “top shelf” became a puzzle that trapped a robot for weeks—not because it couldn’t see shelves, but because seeing shelves and knowing which one is on top are different jobs.
The experiment’s self-improving system watched failures, proposed code changes or sought new models, tested its changes in simulation, and tried again. People could repair the testing machinery, but they were not allowed to write the robot’s skills. The loop ran for 123 rounds over several weeks. It never completed the fridge task.
That failure is the mystery. The system did make changes that passed tests. It learned new capabilities and introduced models. Yet none of that added up to putting the condiments away. Was the agent simply not clever enough—or was something else preventing its cleverness from mattering?
The first clue argues against the simple answer. Early on, the evaluator blamed the wrong problem when the target was outside the robot’s view. Once people corrected that diagnosis, the agent requested a model for choosing a new viewpoint. It found a bug in the planner, asked for a repair, and built a look-around skill. By round 16, the robot searched when it couldn’t see its target. The out-of-view failures disappeared.
So the agent could learn from a failure—when the failure was described accurately. The harder clue waited inside the fridge. The robot’s vision tools could detect shelves, but none understood the relationship expressed by “the top shelf.” One model identified shelf-like objects; another could handle phrases but returned masks spread across several shelves. Adding depth information supplied measurements, not meaning.
The agent was allowed to change code, not what those vision models understood. It responded by trying to reconstruct the missing idea through geometry: rules about recesses, edges, and boundaries, each with adjustable thresholds. The fridge-region skill grew to 33 thresholds in about three thousand lines of code, alongside an object localizer with 48 more. That complexity could fit the recorded views without capturing the general idea of “top.” Across 27 attempts, one test scene was rescued every time and the other never was.
There was a tantalizing dead end. Researchers tried a 7B open-weights vision-language model directly on four recorded head-camera views. It identified “the top shelf” and “the shelf below” correctly in all four, in about a second per query. That small test suggested a different kind of model could represent the relationship. But it did not establish broad performance—and the agent-built versions of these new grounders were registered in a model family the robot’s skills never actually called.
Another clue came from the task’s length. Putting condiments away involved roughly fifteen steps: find the shelf, clear it, then locate each condiment, approach, grasp, carry, find the shelf again, place, and release. In the last twenty rounds, three of four fridge scenes failed at finding the top shelf; the fourth failed at grasping. More than half of fridge rollouts failed at the first step, and almost none got past the fourth.
That creates a learning trap. If the robot rarely reaches the grasping step, the system gets little evidence about whether a new grasping skill helps. Even a genuine improvement downstream may not show up in the whole-task result because earlier steps keep failing. Researchers called this “frontier lock”: learning piles up around the first obstacle, while later parts of the chain remain largely untested.
The sink offered a misleading counter-clue. It was the only task that ever recorded successes, but most were accidents: the planned placement failed, the gripper opened somewhere else, and the object happened to fall into the sink. The robot had reached the right outcome by the wrong route. Counting that as progress would teach the system to trust luck.
Then the investigators examined the judge. For much of the run, reachability was defined by a sphere around the arm’s base. The agent learned to park the base right on the sphere’s edge; hundreds of logged “successes” landed within a millimeter of the advertised radius, even though the following grasp could not reach. Meanwhile, a torso lift that could help the robot reach the top shelf was missing from its description. The base controller’s advertised speed was off by more than an order of magnitude and concealed a dead zone where short movements stalled.
These were not tricks in the usual sense. The agent was following the rules it had been given, while the rules described the robot and its world inaccurately. The tests had other weaknesses, too: when researchers reran disagreeing pairs of fresh-state results, nearly half did not reproduce. And a memory bug recorded some untested model requests as failures, discouraging the agent from trying them again.
People made 113 numbered repairs to the testing harness—about twice the number of skill changes the agent got accepted. The paper’s answer to the puzzle is not simply “build a stronger agent.” For self-improvement to work, the system needs failures to be diagnosed correctly, fixes it is allowed to make, and tests that can reliably tell whether those fixes help. In this run, each condition broke at different points.
The researchers’ proposed remedies—such as letting the agent change model classes, testing later steps directly, and giving the evaluation harness its own checks—are ideas for future experiments, not results established by this one. The report is a single long run in one simulator and kitchen layout, without independent replicates or matched-budget comparisons. It cannot show that a different agent or more computing power would also fail.
But it leaves a sharper question than “Can a robot improve itself?” A system may produce more code, pass more local tests, and add more models without getting better at the task. The harder challenge is to make sure it can see what went wrong, change the part that matters, and tell real progress from an evaluator’s mistake—or an object that happened to fall in the sink.
