To have a robot grab a can of soda sounds like a trivial task.

But every step of the action could go wrong: failing to clearly see the soda can, an incorrect grasping posture, path planning colliding with a table corner, fingers pinching empty air, or after finally picking it up, placing it in the wrong spot the next second. Finally, you get a very unhelpful feedback: Task Failed.

This is like a program crashing, but the log only contains a single simple error line. You know it broke, but you don't know why; you want to fix it, but you don't know how.

On July 2, a new paper titled 'ASPIRE: Agentic Skills Discovery for Robotics', led by NVIDIA and featuring Zhu Yuke and Jim Fan, with participation from institutions such as UMich, UIUC, UC Berkeley, and CMU, addresses exactly this kind of problem.

ASPIRE stands for 'Agentic Skill Programming through Iterative Robot Exploration'. The paper defines it as a continuous learning system for robots: it enables Embodied AI agents to automatically write and modify robot control programs under the 'code-as-policy' paradigm, and accumulate experiences gained from repeated debugging into a reusable Skill Library.

If Codex-style programming agents can already read logs, modify code, run tests, and fix bugs, ASPIRE takes this workflow into the realm of robot training.

It does not demand that robots never fail; rather, it makes failure valuable: after a failure, the agent reviews execution trajectories, identifies the root cause, writes corrective code, re-executes for verification, and then stores the successful fix in an experience repository. Robots are no longer just executing strategies; they begin to resemble engineers who conduct post-mortems.

Learning from Failure: Robots Finally Have 'Debuggable Logs'

The first module of ASPIRE is the Robot Execution Engine.

Past robot programming agents typically received only coarse-grained task-level feedback. The system knew a task had failed but did not know which primitive action caused the failure. However, robot failures are rarely single-point issues. They may stem from multimodal perception, motion planning, grasp generation, or contact dynamics. While all result in task failure, the correction methods differ significantly.

Therefore, ASPIRE decomposes and records the robot's execution process. For every perception, planning, grasping, and control call, the Robot Execution Engine saves the corresponding interface, input, output, return status, and as much multimodal evidence as possible, including RGB keyframes, image overlay annotations, grasp candidates, object poses, and motion planning results.

A key design here is that the agent does not receive full videos but instead receives keyframes, annotations, and return values before and after each primitive action call. This approach prevents the agent from getting lost in massive visual data while preserving sufficient evidence to locate faults.

The paper provides a vivid example using the 'navigate and pick up the radio' task from BEHAVIOR-1K.

Initially, the robot can locate the red radio, indicating that its perception is functioning correctly. However, it repeatedly fails to approach the target, causing the task to stall. Execution trajectory analysis reveals that the issue is neither recognition failure nor grasping failure, but rather that the navigation interface repeatedly returns a PLANNING_ERROR. Upon further inspection of the logs, the Agent identifies that the navigation target point is too close to the table's edge—within approximately 20 cm—triggering cuRobo’s obstacle avoidance buffer, which causes the planner to reject the path.

This illustrates the value of execution trajectories.

If one only looks at the final outcome, the Agent might mistakenly conclude that it should change the perception prompt or switch to a different grasping action. However, ASPIRE recognizes that the target has already been located; the real problem is that the approach pose is unreachable.

Consequently, the Agent writes a repair logic for a 'Multi-Angle Approach': sampling multiple approach directions around the object (e.g., rotating by 45°, 90°, or 180°) to find an accessible position outside the collision buffer, then re-perceiving and attempting the grasp. After re-execution, the robot successfully approaches the radio and completes the pickup.

This is not blind trial-and-error, but targeted repair based on evidence of failure.

It resembles debugging in software engineering: rather than randomly modifying code upon seeing an error, one first locates the call stack and then fixes the function that actually contains the bug.

Accumulating Through Learning: A Robot's Skill Library

If ASPIRE can only fix the current task, it is merely a robot version of a programming agent.

More importantly lies the second module: the Skill Library.

A key sentence in the paper states: Robot program failures tend to recur across tasks, but truly reusable knowledge is rarely an entire task program. In other words, the system should not save "complete programs for picking up a radio," but rather more abstract repair knowledge.

ASPIRE's skill library stores these verified repair knowledge pieces. These can be localization experience, perception prompts, grasping constraints, navigation recovery strategies, motion primitives, scene understanding workflows, or debugging workflows.

These categories are not pre-defined by humans. The paper emphasizes that skills come from verified repairs: The agent first diagnoses failure from execution trajectories, then modifies the program, and verifies the repair in a debugging environment. Only if the repair is effective not just for the current case but also has reusability value will the coordinator add it to the shared skill library.

Each skill typically contains several types of information: what the failure characteristics are, when to use it, what the repair strategy is, and, if necessary, accompanied by a representative code sketch.

For example, in the earlier radio task, ASPIRE did not save the task program for "picking up the red radio," but rather a navigation recovery mode:

When the planner repeatedly encounters errors near obstacle boundaries and candidate target points may fall into collision buffers, do not persistently pursue the original direction. Instead, sample alternative approach directions around the object, then re-attempt perception and grasping.

This provides transfer value.

In the future, regardless of whether the target is a radio, a cup, or another object, if the failure modes are similar, this skill could prove useful.

The skill library in the paper covers many types: localization, motion primitives, navigation, object-level grasping, scene understanding, and debugging. Examples shown in the figure include "multi-object disambiguation," "linear pushing," "multi-angle approach," "handoff pushing," "waypoint jumping," and "tabletop perception workflows."

This is actually where ASPIRE most closely aligns with human engineering experience.

Human engineers do not cram the complete context of every bug fix into their memory; instead, they remember certain patterns: seeing this type of execution trajectory likely indicates this cause; encountering this scenario suggests trying this fix first.

ASPIRE enables robots to develop this 'experience compression' capability.

The paper also introduces a coordinator-executor architecture. The coordinator manages a shared skill library and distributes tasks among multiple executor agents. Each executor is responsible for writing programs, executing them, diagnosing issues, and performing repairs. However, executors do not exchange full chat histories or raw task trajectories with each other; they only share transferable experiences through the skill library.

This is crucial. If every agent were to share its entire history, the context window would quickly become overwhelmed. But by sharing only compressed and validated skills, subsequent tasks can inherit prior experience within a limited context window.

In other words, ASPIRE does not ask robots to remember all their failures, but rather teaches them to organize failures into reusable knowledge.

Accumulate to Evolve: Evolutionary Search that Draws Inferences

The third module is evolutionary search.

Why does the paper require it? Because debugging based on execution trajectories, while significantly better than blind trial-and-error, can still lead to local loops. Agents may repeatedly patch the same failing strategy instead of stepping back to explore entirely different solutions.

ASPIRE treats debugging as a small-scale program evolution process.

In each round, the programming Agent proposes a set of candidate programs based on the current task, the existing skill library, the historically best-performing programs, and the failure trajectories left by previous executions. The paper refers to this collection of candidates as the population, with size K.

Each candidate program is sent to the robot execution engine. After execution, the system obtains two things: a task score and a new execution trajectory package. The next round of search then continues generating new candidates based on the best-performing program and remaining failure modes.

This differs from ordinary "try a few times" approaches.

Standard retries may simply involve repeatedly generating programs, hoping that the next model sampling yields better results; ASPIRE's evolutionary search is memory-driven, evidence-based, and subject to selection pressure. It retains superior candidates, utilizes failure trajectories to guide subsequent rounds, and ultimately extracts verified repair patterns into the skill library.

The algorithmic workflow in the paper can be translated into plainer language as follows:

First, execute the initial program to obtain the current best score and execution trajectory; add this program to the historical collection; then conduct multi-round searches, where in each round the Agent proposes K repair candidates based on the best-performing program and failure records; execute these candidates one by one to update the historical collection; if a program reaches the success threshold, stop the search; finally, re-verify on the validation set and extract verified repair patterns from the entire search process.

There is also a detail here: ASPIRE distinguishes between the debug set and the validation set.

This is similar to the development and test sets in software engineering. An agent can modify programs in a debugging environment, but ultimately needs to re-validate them in a verification environment. Only fixes that pass validation qualify as skills.

Therefore, ASPIRE does not simply record an occasional success into the skill library; it aims to ensure that the fix actually works across environmental variations.

The ablation studies in the paper also illustrate the roles of these two modules. Without the robot execution engine and evolutionary search, the system's average success rate was only 14%; adding the robot execution engine increased it to 62%; and further incorporating evolutionary search brought it up to 72%.

This indicates that the most significant improvement comes from fine-grained execution trajectories, as they enable the agent to identify where repairs are needed; while evolutionary search helps the system break out of single-path limitations in difficult tasks, exploring more potential program strategies.

How Far Are We From a Continuous Learning System for Robots

ASPIRE’s technical approach cannot be simply understood as training robots using large language models to write code.

It is more like building a continuous learning system for robots.

This system includes an execution environment, multimodal execution trajectories, programming agents, a debug-verify closed loop, a scalable skill library, and evolutionary search in program space. Robot capabilities no longer come solely from one-time training but from a cycle of execution, failure, repair, verification, and accumulation.

The paper's experiments also follow this logic.

In simulation experiments, ASPIRE uses Claude Code and Claude Opus 4.6 with a 1,000,000 token context window to write executable Python robot programs within the CaP-X framework. The evaluation covers three benchmarks: LIBERO-Pro tests robustness against object, target, and spatial perturbations in short-horizon manipulation; Robosuite tests contact-rich single-arm and dual-arm manipulation; BEHAVIOR-1K tests long-horizon household mobile manipulation.

ASPIRE achieves up to a 77 percentage point improvement on perturbation tasks in LIBERO-Pro; improves from 20% to 92% on dual-arm handover tasks in Robosuite; and reaches up to a 32 percentage point improvement on long-horizon household tasks in BEHAVIOR-1K.

More notably, there is zero-shot transfer.

ASPIRE transfers the accumulated skill library from LIBERO-90 to unseen long-horizon tasks in LIBERO-Pro Long. Without additional debugging, retries, or task-specific skill library updates, the complete skill library yields a 31% success rate, compared to approximately 4% for prior methods.

This demonstrates that the skill library is not merely decorative. It indeed enables repair experiences learned from short-horizon tasks to be transferred to longer-horizon composite tasks.

The paper also performed sim-to-real transfer. Researchers selected three skills discovered in Franka simulations: can grasping, placing a bowl on a plate, and drawer pushing/pulling, and provided them as context guidance to an OpenAI Codex GPT-5.5 Agent on a real dual-arm YAM robot.

The results showed that skill transfer not only improved success rates but also significantly reduced the debugging costs for real robots. For example, can grasping improved from 13/20 to 19/20, with total tokens decreasing from 61.94M to 6.58M; drawer pushing/pulling went from 0/20 without skills to 11/20 with skills added, reducing total tokens from 334.917M to 81.67M.

Of course, the paper clearly states its limitations.

ASPIRE is not yet a fully autonomous lifelong learning robot in the real world. Real robots are not as easily auto-reset as simulations, nor is it cheap to perform large-scale success detection. The system relies on cutting-edge large models, and its effectiveness for smaller models has not been verified. It also depends on predefined perception, planning, and control interfaces; if a task requires capabilities beyond these interfaces, the Agent remains constrained. As the skill library grows, issues such as outdated, redundant, overly specific, or misleading skills for new tasks may arise, necessitating stronger retrieval, pruning, ranking, and re-validation mechanisms.

But these limitations恰恰 indicate that ASPIRE points to more than just a model—it represents a set of infrastructure.

This also resonates with the judgment of Xie Chen, founder and CEO of Guanglun Intelligence, regarding Embodied AI. Xie Chen has mentioned on multiple public occasions that the bottleneck for Embodied AI is not just the model itself, but data. The autonomous driving industry has vast amounts of vehicles continuously collecting real-world scenarios, but the robotics world still lacks millions of robots constantly trial-and-erroring in homes, factories, and open environments.

Data is not fuel, but an educational system; robot training requires a continuous learning ecosystem.

The value of ASPIRE resonates precisely with this judgment.

It does not merely ask 'where does the data come from?', but goes further: How are failure data interpreted? How is the execution process structurally recorded? How are repair experiences verified? How do verified experiences solidify into skills and get reused in future tasks?

This is what makes bringing Agent tools into the robot training arena truly interesting.

Codex-style Agents changed software engineering not just because they can write code, but because they entered a runnable, testable, and feedback-driven engineering closed loop. ASPIRE attempts to migrate a similar closed loop to the physical world: making robot tasks into systems that can be executed, observed, debugged, and accumulated upon.

The future competition in Embodied AI may hinge on who can build a better learning closed loop: one capable of generating sufficiently complex tasks, exposing sufficiently realistic failures, understanding those failures, repairing them, and turning failures into assets for future success.

In short, the most noteworthy aspect of ASPIRE is not how many benchmarks robots complete using it, but rather the new paradigm of capability growth for robots that it demonstrates.

—Building a continuous learning system for robots.