APPL (Agent Priors-guided Policy Learning), from researchers at the National University of Singapore, doesn't throw away the "design assumptions" used to train a robot skill — it reuses them later, when those skills are composed. Where conventional approaches pass only what a skill does (its name) to the composer, APPL also writes down, in language, where that skill holds up. The core claim is that this single act of reuse lets the system handle unseen situations and unseen combinations better, even with few demonstrations.
A robot working in a home or a warehouse is asked to do far more than it was taught. Collecting demonstrations is expensive, so a robot typically learns from just a handful of demonstrations across a few tasks. But the field throws new goals, new orderings of familiar motions, and objects placed in positions it has never seen.
Two kinds of generalization are needed here at once. One is compositional generalization — the ability to re-stitch learned skills to solve a new task. The other is skill generalization — the ability of each skill to keep working even when objects move, or when it has to start from an unfamiliar state left behind by a preceding skill.
The trouble is that the two are coupled, yet information leaks right at the seam between them. Task-level reasoning worries about "which skill in what order," but has no idea how far each skill actually reaches physically. Conversely, a skill was only learned from a few demonstrations and knows nothing about the structure the higher-level reasoning leans on. In the authors' phrasing, the composer sees skills only through "separate descriptions" — names, instructions, symbolic operators — and those descriptions leave out the structure under which each skill was learned.
Prior approaches have tried to close this gap too. Vision-language-action models (VLAs) fuse task semantics and low-level control into one model, but the paper cites the criticism that the conditions under which they generalize stay implicit, leaving them fragile to changes in layout and object position. Task-and-motion-planning (TAMP) methods bridge the two levels with symbolic preconditions and effects, but that structure has to be hand-specified or learned from data. Agentic approaches call policies like tools and use language as the interface, yet a name or an instruction tells you "what the tool is for" but not "under what physical conditions it works." As a result, the handoff between one skill and the next remains a common failure point.
APPL's premise is simple: reuse the structural prior used to train a skill directly as the interface for the composition stage.
A structural prior spells out "what this behavior depends on." The paper's example is grasping. A grasp can be assumed to depend only on "the gripper's pose relative to the object," not on an absolute position in world coordinates. This assumption is used in two places. First, baked into learning, it shapes where the policy will generalize: a grasp learned in object-relative coordinates still works when the object shows up at a new absolute location. Second, the same assumption, written out in language and handed to the higher-level agent, tells it where that policy applies.
To put it as a cooking analogy: instead of just pinning a "photo of the finished dish" to the recipe card, you also note the conditions it applies under — "this method assumes room-temperature ingredients; not for frozen." The head chef (the composer) no longer picks by dish name alone, but can judge whether this recipe will work given the current state of the ingredients.
Concretely, APPL runs on two agents.
What's clever about this design is that it turns "how to structure the policy" from a fixed design decision into a per-skill hypothesis. The hypothesis is proposed, implemented, validated, and reused at runtime. The information that shaped learning survives to help pick and stitch that same policy later.
The paper also formalizes what makes a good interface. Call the region where a policy actually succeeds its success region (R), and the region where the interface claims "it works here" its applicability region (A). If A is broader than R, the policy gets called where it shouldn't and fails; if A is far narrower than R, usable calls get left on the table. So an interface must be both faithful (A sits inside R) and informative (A covers R broadly).
The experiments target the two roles of priors separately. Note that the figures below come from two different experiments.
The first experiment looks at skill generalization. Across six MetaWorld tasks, agent-designed priors substantially lifted out-of-distribution (OOD) generalization in the few-demonstration regime, compared with a vanilla Diffusion Policy and a fixed relational prior. By the paper's reported numbers, with two demonstrations the OOD success rate was 89.6%, against 37.9% for the fixed relational prior under the same condition.
The second experiment looks at composition on long-horizon tasks. Across five ManiSkill long-horizon tasks with 12 demonstrations each, APPL succeeded 50.0% of the time under changed object placements, where a full-task Diffusion Policy that learned the whole task end-to-end managed only 10.0% under the same condition. On task-level variations that start from a midpoint or request early termination, it scored 92.5%, and it solved 8 of 16 previously unseen skill combinations.
The most important result is a separate one. Leaving the trained policy library intact but hiding only the construction-time interface information from the runtime agent caused success rates to drop significantly. This supports the paper's central hypothesis: the structural assumptions used to make a skill generalize are also useful information for deciding when and how to use that skill. In other words, what boosted performance was not the policies alone but the interface that conveyed "where each policy holds up."
The authors acknowledge limitations in their conclusion too. A few are worth pointing out, staying within the factual scope of the paper.
The compositional-generalization results are still hard to call high in absolute terms. Solving 8 of 16 unseen combinations is half. The 50.0% under changed object placements is five times the baseline (10.0%), but on its own it's half-success. That's evidence this is a hard setting, and also a signal there's distance left to cover.
It's also worth keeping in mind that the testbeds are MetaWorld and ManiSkill. Both are simulated manipulation benchmarks, and whether the same margin of gain reproduces on real robots in real homes lies beyond this paper's factual scope.
And the structure of "proposing several priors and training/validating one policy per prior" carries the cost of building and storing multiple policies per skill. As the library grows, so does the selection problem of the runtime agent picking the right candidate. The requirement that an interface be faithful and informative at once is conceptually clean, but how far an agent-authored applicability description diverges from the true success region will vary from task to task.
Lay this research over one scene of AI project management and the implication sharpens: the moment a tool (skill) is delegated.
When ONTLE's AI PM receives a customer request, it parcels the work out to various execution tools and sub-agents. As in most agentic systems today, the way the PM knows a tool is through its "name and description" — for instance, "Excel table preview tool," or "subdomain publishing tool." The very problem APPL flagged in robotics recurs here. The PM knows what the tool does, but not under what conditions it works reliably. That the table-preview tool only reads the top 200 rows and 30 columns, or that a certain integration requires a project-dedicated DB to be created first — those "applicability regions" aren't captured in the tool's name.
Transposing APPL's prescription: when you register each execution tool, write down not just its name but also "what this tool depends on / what input state it presumes / what state the preceding step must leave for it to take over (handoff conditions) / in what range its success has been validated in the past" — all as a machine-readable interface. Then, when the PM decomposes work and delegates, it can call a tool only "where it works," and "where it doesn't" either pick a different implementation or slot in a prerequisite step first. The transition point in particular — where one tool's output violates the next tool's input presumption — is a common failure site in pipelines like ONTLE's too, and the idea of spelling out handoff conditions in the interface aims squarely at it.
There's a trap visible here as well. The APPL result that hiding interface information degraded performance means, in reverse, that a flimsy interface collapses composition no matter how good your tools are. It's an experimental demonstration of why the common practice of managing a tool catalog as "name + one-line description" is risky. For ONTLE, the near-term task isn't to mimic robot policies but to promote the "applicability and handoff conditions" of tools, integrations, and sub-agents into description metadata. That's the most direct path for carrying the gain this paper showed on a robot arm over to the delegation reasoning of software agents.
It's an assumption that spells out what a behavior depends on. The paper's example is a statement like "grasping depends only on the gripper's pose relative to the object." Baked into learning, it determines where the policy will generalize; written out in language, it tells the higher-level agent where that policy applies.
Because the construction agent, rather than nailing each skill to a single abstraction, proposes several priors and trains one Diffusion Policy per prior. Implementations with different inductive biases coexist in the library, so the runtime agent can pick the one that fits the situation.
No. 89.6% is the OOD skill-generalization success rate on six MetaWorld tasks in the two-demonstration condition (vs. 37.9% for the fixed relational prior), while 50.0% is the compositional success rate on five ManiSkill long-horizon tasks under changed object placements (vs. 10.0% for the full-task Diffusion Policy). They are figures from different experiments and conditions, so they shouldn't be merged into one.
This paper's experiments were run on MetaWorld and ManiSkill, which are simulated manipulation benchmarks. Whether the same margin of gain reproduces on real robots in real environments is an open question beyond the factual scope presented in the text.