ASPIRE: Agentic /Skills Discovery for Robotics

1. Why a failed rollout is not enough

A robot program combines perception, localization, grasp selection, motion planning, control, and long-horizon coordination. A failed episode reports that the task did not finish, but it rarely identifies the responsible subsystem. The robot may have detected the wrong object, chosen an unreachable target, entered a collision buffer, missed a grasp, or lost a valid object state during recovery.

Code-as-policy systems make the behavior editable. A model can inspect a Python program, rewrite a perception prompt, replace a target pose, or rearrange a sequence of primitives. That is useful only when the model receives evidence specific enough to distinguish those hypotheses. A single success flag cannot support that reasoning, while a full raw video stream can bury the relevant frame in irrelevant visual detail.

ASPIRE treats execution feedback as an interface-design problem. Its runtime does not expose an arbitrary dump of simulator memory. It records structured traces around public robot calls and lets the coding agent request the evidence surrounding a suspected failure. This creates a middle layer between the task-level metric and low-level state.

The second problem is memory. Conventional coding agents solve one task and discard the local repair that made the program work. The next task begins without the previous debugging experience. Human robot engineers do not operate this way: they retain recovery patterns, identify the conditions under which those patterns apply, and become faster at diagnosing similar failures.

ASPIRE attempts to reproduce that accumulation in text rather than in model weights. A successful repair is distilled into a compact skill containing a failure signature, a usage guard, a repair strategy, and sometimes a short code sketch. Later agents retrieve the relevant skill as in-context guidance. The underlying language model remains frozen.

2. The search problem is defined over executable programs

For a task $\tau$, let $P$ be a robot program, $S_{\mathrm{dbg}}$ the debug seeds, and $S_{\mathrm{eval}}$ the held-out seeds. Execution returns both a score and a trace bundle rather than only a terminal success bit:

$$ \operatorname{Execute}(P,S)=(r,Z) $$

The trace $Z$ summarizes tool inputs and outputs, completion status, timing, frame references, and diagnostic evidence. This changes the search target. ASPIRE searches over executable code $P$, but evaluates each candidate through actual simulator interaction. A compelling explanation that does not run has no fitness.

The initial history is built from a baseline program and its debug execution:

$$ \mathcal{H}=\{(P^0,r^0,Z^0)\} $$

At each evolutionary round, model $M$ proposes $K$ repairs conditioned on the task, the top three histories, the current skill library $\mathcal{L}$, and previous failure traces:

$$ \{P_i^k\}_{k=1}^{K}\leftarrow\operatorname{ProposeRepairs}(M,\tau,\operatorname{Top3}(\mathcal{H}),\mathcal{L},\mathcal{H}) $$

Every candidate is executed on the debug split. The best candidate in the round is

$$ k^\star=\arg\max_k r_i^k, $$

but it replaces the incumbent only if $r_i^{k^\star}>r^\star$. Search stops when the best score reaches threshold $\theta$ or the budget of $T$ rounds expires. After search, the selected program is evaluated once on the held-out set:

$$ (r_{\mathrm{eval}},\cdot)\leftarrow\operatorname{Execute}(P^\star,S_{\mathrm{eval}}). $$

This separation is an important methodological choice. The evaluation seeds do not drive evolutionary selection, and the final program is not regenerated for every test seed. The comparison is therefore closer to “learn one reusable program, then test it” than to “let the agent retry until each individual rollout succeeds.”

3. From trace attribution to a skill library

3.1 Per-primitive traces expose the causal boundary

For each perception, planning, grasping, or control call, the execution engine retains the API name, arguments, returned values, failure code, and relevant visual evidence. Frames are stored immediately before and after motion primitives instead of exposing every frame of a continuous video. The actor can inspect the call chain around the failure and follow return values backward toward its source.

The BEHAVIOR-1K radio-pickup episode is a concrete example. Perception successfully returned a radio pose, but repeated navigation calls produced planning errors. The trace showed that the generated target was less than roughly 20 cm from the table edge, inside the collision-avoidance buffer. The correct repair was not a better radio detector. The actor introduced a multi-angle approach that sampled a reachable side of the table before grasping.

3.2 Skills capture transferable repair rules, not complete episodes

The library contains localization heuristics, perception prompts, grasp constraints, navigation recovery routines, motion primitives, scene-understanding procedures, and debugging workflows. Its taxonomy is not fixed in advance. The actor reports a failure mode, a validated repair, and a proposed transferable pattern; the coordinator determines whether that pattern should persist.

A skill is more reusable than a complete task program because it can apply to a family of failures. “When planning repeatedly fails near an obstacle boundary because candidate poses fall inside the collision buffer, sample alternate approach directions before retrying perception and grasping” transfers to other objects and scenes without carrying the original table layout.

3.3 Admission requires independent reproduction

After a task actor proposes a skill, a fresh verifier receives that skill and attempts the source task on a subset of seeds. The verifier does not inherit the actor’s full conversation. The coordinator also checks whether the repair respects the public API policy. Only entries whose success can be reproduced are promoted.

This is not a complete answer to skill quality, but it separates execution evidence from narrative plausibility. It also keeps the shared context compact: agents exchange distilled repair knowledge rather than all raw trajectories and chat histories.

4. Search, curriculum, and backward transfer

Iterative debugging can become a local loop. If the first diagnosis is wrong, later edits may refine the same failed strategy rather than test a different decomposition. Evolutionary search addresses this by producing multiple executable repair candidates in parallel. The surviving programs preserve useful progress; their residual failure traces steer the next generation.

The coordinator adds a curriculum layer. It chooses which task to attempt next, can target a gap in the library, or can test a recent skill on another task from the same suite. Tasks completed early see a small library, while later tasks inherit more experience. A low early score may therefore reflect poor timing rather than an intrinsically hard task.

After the library is complete, the coordinator reruns selected weak tasks once. This produces backward transfer: knowledge discovered later is applied to earlier programs. On Claude Opus 5 LIBERO-Pro Long, suite success rose from 746/1000 (74.6%) to 822/1000 (82.2%), a gain of 7.6 percentage points. Four of the five rerun tasks improved, while one remained at zero.

flowchart LR
    Q[Curriculum picks task] --> P[Actor writes robot program]
    P --> X[Execute on debug seeds]
    X --> T[Inspect primitive traces]
    T --> R[Repair or alternate decomposition]
    R --> D{Best score reaches threshold}
    D -->|No| E[Propose K evolutionary candidates]
    E --> X
    D -->|Yes| H[Test once on held-out seeds]
    H --> V[Fresh verifier]
    V -->|Reproduced| L[Admit skill to library]
    L --> Q
    L --> B[Backward rerun of weak tasks]

5. What the public implementation makes concrete

The repository turns the paper’s execution assumptions into enforceable contracts. Generated Python is parsed into an abstract syntax tree before execution. A validator rejects private names, dunder attributes, class definitions, async constructs, global and nonlocal declarations, context managers, and all imports except math:

# src/cap_harness/runtime.py
tree = ast.parse(code, mode="exec")
_ProgramValidator().visit(tree)
compiled = compile(tree, "<generated-program>", "exec")

for spec in self._registry.all_specs(public_only=True):
    ...

The runtime constructs a fresh namespace from public tools in the registry. Sensitive fields such as ground_truth, reward, simulator state, raw observations, and privileged poses are filtered. This implementation detail matters for the paper’s claims: the coding model is not supposed to read evaluation truth or bypass the robot API with arbitrary Python.

The second code-level contract concerns evidence. Tool invocations are wrapped in timed spans, and motion calls create keyframes before and after execution. The artifact recorder also redacts credential-like keys and token strings before writing JSON.

# src/cap_harness/runtime.py
with self._recorder.span(
    name, category="program",
    inputs={"args": args, "kwargs": kwargs},
) as span:
    result = self._invoke_tool(name, function, args, kwargs)
    span.output(result, ok=ok)
if motion:
    self._recorder.keyframe(f"before-{name}")
    self._recorder.keyframe(f"after-{name}")

In src/cap_harness/artifacts.py, the recorder stores observations, actions, timing buckets, videos, termination reasons, and the final outcome. This is a compromise between observability and context economy: the trace is detailed enough to support causal diagnosis but does not hand the model every frame or every privileged simulator array.

A third implementation detail is that program_ok and task_success remain separate. A program can return an error while the environment has already latched benchmark success, and the repository’s tests preserve that distinction. This prevents a generated program’s self-report from overwriting the environment’s judgment.

6. Benchmark results: broad gains with uneven edges

The main simulation runs use Claude Opus 4.6 in Claude Code with a 1M-token context. LIBERO-Pro tests short-horizon robustness under object, goal, and spatial perturbations. Robosuite covers contact-rich single- and dual-arm manipulation. BEHAVIOR-1K evaluates long-horizon mobile manipulation.

The protocol uses disjoint debug and evaluation seeds. For LIBERO-Pro, ASPIRE learns on seeds 51-65 and evaluates one generated program on seeds 1-50. Robosuite learns on 101-125 and evaluates on 1-100. BEHAVIOR-1K learns on 26-35 and evaluates on 1-25. CaP-Agent0, by contrast, regenerates a program for each evaluation seed with test-time reasoning and retries.

LIBERO-Pro method	Object	Goal	Spatial	Overall
OpenVLA	0%	0%	0%	0%
π0.5	17%	1%	20%	13%
CaP-Agent0	22%	18%	12%	18%
ASPIRE, position perturbation	98%	81%	51%	77%
ASPIRE, task perturbation	95%	45%	60%	67%
ASPIRE, all perturbation average	96.5%	63%	55.5%	72%

The headline gain is substantial, but the decomposition is more informative. Object and spatial robustness improve sharply, while the Goal suite falls from 81% under position perturbation to 45% under task paraphrases. Executable traces help diagnose physical failures; they do not eliminate language grounding errors or incorrect interpretations of a rewritten task.

Robosuite shows the same pattern of high-value wins and a few regressions. The overall average rises from 68% to 81%. Bimanual handover jumps from 20% to 92% and nut assembly from 0% to 9%. Yet two-arm lift drops from 74% to 71%. The method is not uniformly superior on every task even when the aggregate improves.

Robosuite task	CaP-Agent0	ASPIRE
Two-arm handover	20%	92%
Two-arm lift	74%	71%
Nut assembly	0%	9%
Seven-task mean	68%	81%

BEHAVIOR-1K separates navigation from task success. This is necessary because a robot can reach the neighborhood of an object without completing the intended manipulation. On radio pickup, ASPIRE reaches 100% navigation and 88% task success, compared with 80% and 56% for CaP-Agent0. The multi-angle approach repair is directly visible in this result.

BEHAVIOR-1K task	Human nav / task	CaP nav / task	ASPIRE nav / task
Soda can	80% / 72%	84% / 72%	92% / 88%
Radio	88% / 36%	80% / 56%	100% / 88%

7. Does the library compound experience?

The strongest test of continual learning is transfer to tasks that were not used to build the library. ASPIRE constructs skill-library snapshots from $N\in\{0,25,50,90\}$ LIBERO-90 tasks and evaluates them on LIBERO-Pro Long without additional debugging, retries, or task-specific library updates.

Success increases monotonically with library size. The empty library scores 4.7% overall, followed by 13.7%, 21.5%, and 30.5% for 25, 50, and 90 source tasks. The appendix reports 22.6% on the position axis and 38.3% on the task axis. The main text rounds these to 23% and 38%, while the abstract rounds the overall result to 31%.

Library size	Position perturbation	Task perturbation	Overall
N = 0	0.0%	9.4%	4.7%
N = 25	5.6%	21.8%	13.7%
N = 50	13.8%	29.2%	21.5%
N = 90	22.6%	38.3%	30.5%

This trend supports the paper’s core claim that validated repair knowledge, not task-specific code alone, is transferable. It does not show that more skills always help. The per-task appendix contains reversals where a larger library lowers success, consistent with stale, redundant, or poorly matched entries being retrieved for a new context.

The backward-transfer experiment reinforces the sequencing problem. Five early low-scoring tasks were rerun with the completed library. Four improved, with gains of 20, 52, 72, and 8 percentage points; one stayed at zero. The full 20-task suite improved by 7.6 points. The library therefore changes future task attempts, and later learning can repair earlier outcomes.

8. Ablation and model dependence

Removing the execution engine leaves LIBERO-Pro at 14% macro-average success. Adding trace-guided repair raises it to 62%, and adding evolutionary search reaches 72%. The execution engine is the larger contributor: most gains come from observing the right primitive and validating the repair, not merely from generating more candidates.

Evolutionary search remains useful when iterative debugging becomes stuck. On Claude Opus 5, putting a mug in the microwave rises from 0% to 42%; on GPT-6 Astra, putting a bowl in the top drawer rises from 82% to 98%. Stronger models need fewer evolutionary corrections on average, but hard residual tasks still benefit from explicit exploration.

The model sweep covers twelve proprietary and open-weight models. On Goal tasks under position perturbation, GPT-6 Luna reaches 15%, Opus 4.6 reaches 56%, and Kimi K3 reaches 78%. Opus 5.5 and Sonnet 5.5 reach 99%. Sonnet 5.5 is Pareto-optimal at 98.8% and about 12 dollars per task; Opus 5.5 reaches 99.2% at about 18 dollars, while Opus 5 reaches 91% at about 60 dollars.

These results establish scaling with the underlying model, but they also expose a dependency. ASPIRE is not learning robot competence entirely from scratch. The language model supplies the hypothesis space for repair, the code-writing ability, and the interpretation of visual evidence. A weaker model can produce executable code yet fail to choose the right decomposition.

9. Real-robot evidence: guidance, not policy deployment

The cross-embodiment study uses a bimanual YAM platform with a different perception and control stack from the Franka-based simulation. The system does not transfer network weights. It retrieves simulation-derived text skills and gives them to a real-robot coding agent, which must still adapt and debug its own API calls against real execution traces.

Real task	Total tokens without skill	With skill	Success without	Success with
Bowl on plate	8.65M	5.11M	20/20	20/20
Lift soda can	61.94M	6.58M	13/20	19/20
Open or push drawer	334.92M	81.67M	0/20	11/20

The results are best interpreted as programming-effort reduction. Bowl placement is already saturated, so the skill mainly saves tokens. Soda lifting reaches 95% success with nearly an order of magnitude fewer tokens. Drawer manipulation reaches 55% after the no-skill run exhausts a larger debugging budget without finding a successful program.

Token reduction is not identical to better physical reasoning. A shorter run may reflect faster fault localization, a smaller context, or fewer irrelevant retries. The paper reports tokens until first success or budget exhaustion, so run-specific stopping rules and model behavior remain part of the measured effect.

The online Rubik’s Cube study goes further: ASPIRE accumulates skills from real-world interaction. GPT-6 Astra fails to solve the cube after 50 minutes 54 seconds in the first episode, then solves it in 39 minutes and 77 minutes 10 seconds. The recorded completed face turns are 3, 5, and 25, giving 1018, 468, and 185 seconds per turn.

Tokens per turn fall from 11.27M to 2.01M, and estimated model cost falls from 16.85 to 2.89 dollars. The accumulated text skills cover two-layer support, single-layer isolation, face-axis alignment, collision-aware handovers, and slip recovery. The full-episode amortized numbers include failures, recovery, and context compaction.

The experiment should not be read as stable convergence. The second and third episodes differ in completion time and number of completed turns, and only three runs are observed. The decreasing per-turn cost is evidence of within-session improvement, but not a substitute for a larger randomized study of cube states and repeated independent sessions.

The qualitative case studies explain why stronger models help. Under a shelf whose gap is too low for an upright book, Opus 5.5 knocks the book flat and pushes it, while Astra rolls it flat, releases it, and pushes. Facing a plate blocked by a bowl and a box, Opus 5.5 clears the obstacles before pushing, while Astra lifts the plate over the clutter.

10. Limitations and open engineering problems

The authors explicitly state that ASPIRE is not yet a fully autonomous real-world lifelong learner. In the Rubik’s Cube study, a human provides task guidance, scrambles the cube, and resets the scene. Real deployment still needs robust success detection, safe reset, monitoring, calibration maintenance, and recovery from physical disturbances.

Performance depends on a frozen frontier model. The same API, seed split, and execution engine can produce very different results depending on the coding model. The best results use proprietary models, and the best open-weight result in the representative Goal setting is 78%. The system amplifies model capability but does not replace it.

The predefined robot API is another boundary. It makes debugging safe and tractable, but limits the behaviors the agent can express. If a task requires tactile sensing, a new controller, or a primitive outside the registry, the agent must approximate it or wait for a human to extend the tool set.

The skill library lacks continuous governance. A verifier checks a skill when it is admitted, but entries are not repeatedly revalidated, deduplicated, or ranked against the current task distribution. The zero-shot per-task data already show cases where a larger library harms performance. Stale skills can be worse than no skill when retrieval is confident but the applicability guard is wrong.

Compute is a practical constraint. Debugging and evolutionary search require many language-model calls and many simulator or physical rollouts. The paper reports campaigns with billions of total tokens and thousands of dollars in estimated cost. Reuse can amortize that cost over later tasks, but the method is not yet a cheap always-on robot runtime.

Finally, evaluation breadth is uneven. Simulation results cover many seeds and several benchmark families, but the real-robot transfer study has three tasks and the online cube study has three sequential episodes. Longer task suites, more embodiments, broader object variation, and independent human comparisons would strengthen the causal claims about skill transfer.

11. Why this matters for robot-agent architecture

ASPIRE’s central contribution is architectural. It places an evidence-rich execution layer between the language model and the robot, then makes validated repairs persistent at a granularity smaller than a full task program. This avoids two common extremes: an end-to-end policy with no inspectable intermediate reasoning, and a coding agent that can only rewrite whole programs from coarse success signals.

The evaluation supports three conclusions. First, per-primitive traces and closed-loop validation provide a large gain over blind program generation. Second, evolutionary search is especially valuable on residual failures that local repair cannot solve. Third, a library of verified repair patterns produces measurable zero-shot and backward transfer rather than only improving the current episode.

The paper also leaves a clear research agenda: verify skills continuously, rank them by context, retire stale entries, propose new primitives safely, and close the real-world loop around success detection and reset. Those problems matter more as libraries grow, because retrieval quality and maintenance can dominate the value of adding another skill.

For developers building embodied agents, the practical lesson is that execution traces should be designed as a first-class product interface. The trace is not a debugging afterthought; it is the observation space of the repair agent. The skill library is likewise not a vector database of task summaries. It is a set of hypotheses about failure and repair that must remain executable, attributable, and testable.