Section 26.5: Skill libraries for embodied agents

"A skill you can retrieve is worth ten you have to relearn. The library is not overhead; it is the whole point."

A Frugal Planner

Why Hierarchy Matters

Hierarchy separates two timescales. An impedance controller runs a 1 kHz torque loop on a Franka arm, while a behavior tree in BehaviorTree.CPP makes a 1 Hz sequencing decision. That split lets the planner pick grasp_upright_object without modeling joint-level contact dynamics, and it lets the low-level policy absorb friction and perception noise without renegotiating the mission. Collapse those two timescales into one monolithic policy and an Open X-Embodiment-trained network can no longer report which subtask failed when a mug slips.

A skill library is an engineering asset: a catalog of reusable controllers, learned policies, task graph nodes, verification tests, and metadata. It lets a drone, autonomous vehicle, or humanoid reuse action knowledge while still respecting embodiment-specific limits. Without a library, adding a tenth task to a warehouse robot may require retraining from scratch on thousands of new demonstrations; with one, the same task composes from existing skills in a single planning pass (in practice, the difference is typically on the order of 40,000 demonstrations to learn a new monolithic policy versus 200 to fine-tune one new skill that slots into an existing library, though the exact ratio depends on task similarity to the existing catalog). This is the reuse dividend of explicit skill contracts, and it compounds with every task added to the library, exactly the pattern the Boston Dynamics Spot example later in this section shows operating in a shipped product. Skill discovery methods can populate this catalog automatically when hand-specification is impractical.

Formal Contract

That reuse dividend only holds if every skill in the catalog exposes the same inspectable interface, so the next step is to pin down exactly which fields that interface must carry.

Use the option tuple as an audit checklist: initiation states, internal policy, termination probability, and verifier must match the robot task.

The library as a constrained selection rule

The equation below states the library contract compactly: the library \(\mathcal{L}\) is a set of \(n\) skills, each a tuple of an option \(\omega_i\), a precondition \(\mathrm{pre}_i\), a postcondition \(\mathrm{post}_i\), a risk score \(\mathrm{risk}_i\), and a cost \(\mathrm{cost}_i\); the selected skill \(\omega^*\) is the cheapest one whose precondition is satisfied in the current state \(s\).

$$\mathcal{L}=\{(\omega_i,\mathrm{pre}_i,\mathrm{post}_i,\mathrm{risk}_i,\mathrm{cost}_i)\}_{i=1}^{n},\quad \omega^*=\arg\min_i \mathrm{cost}_i \;\mathrm{s.t.}\; \mathrm{pre}_i(s)=1.$$

Map the option fields onto behavior trees, task graphs, finite-state machines, or task-and-motion planning nodes so start, act, stop, and verify remain inspectable. Figure 26.5.B shows this layering concretely: a mission goal flows into a task graph, which dispatches to navigate, manipulate, and recover skills, each gated by a shared verifier whose failure signal (dashed red arrow) routes control back to the task graph, which then re-dispatches a recovery skill.

Worked Implementation

Code Fragment 1 for Skill libraries for embodied agents should expose initiation, progress, termination, verification, and failure reporting before connecting the skill to ROS 2, BehaviorTree.CPP, Drake, or a learned policy.

# Skill library with precondition/postcondition contracts and cost-optimal selection
import numpy as np
from dataclasses import dataclass, field
from typing import Callable, Dict, List, Optional

@dataclass
class Skill:
    name: str
    precondition: Callable[[Dict], bool]
    postcondition: Callable[[Dict], bool]
    cost: float          # seconds of execution time
    risk: float          # probability of unsafe outcome in [0, 1]
    execute: Callable[[Dict], Dict]  # returns updated state

def build_library() -> List[Skill]:
    return [
        Skill(
            name="navigate_to_station",
            precondition=lambda s: s["path_clear"] and s["arm_tucked"],
            postcondition=lambda s: s["at_station"],
            cost=3.6, risk=0.05,
            execute=lambda s: {**s, "at_station": True},
        ),
        Skill(
            name="grasp_upright_object",
            precondition=lambda s: s["at_station"] and s["object_within_reach"],
            postcondition=lambda s: s["gripper_loaded"],
            cost=2.1, risk=0.12,
            execute=lambda s: {**s, "gripper_loaded": True},
        ),
        Skill(
            name="change_lane",          # high-risk alternative path
            precondition=lambda s: s["path_clear"],
            postcondition=lambda s: s["at_station"],
            cost=1.0, risk=0.45,
            execute=lambda s: {**s, "at_station": True},
        ),
    ]

def select_skill(state: Dict, library: List[Skill],
                 risk_budget: float = 0.20) -> Optional[Skill]:
    """Return cheapest feasible skill within the risk budget."""
    candidates = [
        sk for sk in library
        if sk.precondition(state) and sk.risk <= risk_budget
    ]
    return min(candidates, key=lambda sk: sk.cost) if candidates else None

if __name__ == "__main__":
    state = {"path_clear": True, "arm_tucked": True,
             "at_station": False, "object_within_reach": True,
             "gripper_loaded": False}
    library = build_library()
    chosen = select_skill(state, library, risk_budget=0.20)
    print(f"Selected: {chosen.name}  cost={chosen.cost}s  risk={chosen.risk}")
    state = chosen.execute(state)
    ok = chosen.postcondition(state)
    print(f"Postcondition verified: {ok}  state={state}")

Selected: navigate_to_station  cost=3.6s  risk=0.05
Postcondition verified: True  state={'path_clear': True, 'arm_tucked': True, 'at_station': True, 'object_within_reach': True, 'gripper_loaded': False}

The expected returned dictionary shows the selector is optimizing inside a safety-feasible subset, not across the whole library. Read the decision as "minimum cost subject to risk budget and satisfied preconditions," which is the right interpretation for hierarchical skill routing.

The risk budget matters because physical robots cannot undo actions. A skill that passes every unit test but ships without a budget is not safe; it is safe-looking, waiting for the wrong state. A 45% failure-probability skill costs a simulated agent one training episode, but it can make a real robot drop a patient, damage a joint, or hit a human. The budget is therefore a hard constraint: any skill whose risk exceeds the threshold is excluded before cost minimization begins, however cheap it is.

The risk score is computed offline from logged execution data: run each skill across a held-out set of initial states, measure the fraction of executions that violate a safety guard (force threshold, workspace limit, or postcondition failure), and store that fraction as the skill's risk field. At runtime the selector reads the precomputed value; no online estimation occurs. This makes selection deterministic and auditable, at the cost of requiring a representative evaluation set for each skill before deployment.

Practical Recipe

With the contract formalized and the selector implemented, the remaining question is how to author skills so the library stays inspectable as it grows; the following recipe distills that authoring discipline into concrete steps.

1. Name each skill with a verb and object: navigate_to_station, grasp_handle, dock_drone, or change_lane.
2. Write preconditions, postconditions, safety guards, timeout, and recovery behavior before training a policy.
3. Represent sequencing as a finite-state graph, behavior tree, or task-and-motion plan so failures have explicit routes.
4. Use language as a planner only after commands are grounded into a typed skill library with affordance checks.
5. Evaluate composition, not only individual success. Many failures occur when two correct skills meet at a bad boundary.

What happens when two individually correct skills meet at the wrong boundary? The answer is usually not a dramatic crash but a quiet refusal: the second skill's precondition check fails by a margin of centimeters, the planner stalls, and no fault is ever clearly assigned. That boundary problem motivates the following worked example.

Consider a specific case: a mobile manipulator must deliver a mug from a counter to a table 3 meters away. The skill library contains three entries: navigate_to_pose (precondition: path clear, arm tucked; cost: 1.2 s/m), grasp_upright_object (precondition: object detected within 0.4 m, gripper open; cost: 2.1 s), and place_on_surface (precondition: gripper loaded, surface detected within 0.3 m; cost: 1.8 s). The planner selects the minimum-cost sequence that satisfies each precondition in order. That sequence runs navigate (3.6 s), grasp (2.1 s), navigate again (0.6 s), then place (1.8 s). The grasp verifier then reports that the mug tipped 15 degrees beyond the acceptable roll threshold. The skill returns "retry," and the planner re-calls grasp_upright_object from a pose 5 cm to the left, without replanning the entire mission. This is the compounding benefit of explicit postconditions: local recovery without global replan.