Temporal Abstraction

Humans solve complex tasks in chunks: "make coffee," "get ready for work," or "drive to the airport." Each chunk hides dozens or hundreds of primitive actions. Standard RL agents usually see only primitive actions such as move forward, turn left, pick up object, or open door. That works for simple tasks, but long-horizon problems quickly become painful: the agent can get lost, reward is too delayed, credit assignment explodes, and exploration becomes inefficient.

Hierarchy changes the scale of decision-making. You do not plan "rotate wrist, step forward, adjust grip" when you want the fridge open. You select the macro-action "open the fridge." If an RL agent can choose multi-step behaviors, exploration becomes more structured, decisions happen less frequently, rewards can become more predictable, and credit assignment spans fewer high-level steps.

Temporal abstraction

Tune the size of an action

Move the dial from primitive motor commands to long reusable routines. Watch the same warehouse task become simpler or less flexible.

PrimitiveShort skillsTask chunksWhole routine

Steps per choice

4

High-level choices

12

Recovery flexibility

82%

Behavior trace

align to shelfinch forwardgrip toteback out
Credit assignment clarity56%
Flexibility after surprise82%

A useful middle ground: skills are long enough to simplify search but short enough to recover.

Temporal abstraction is a trade: fewer high-level decisions, but each decision hides more low-level behavior.

Hierarchy is not automatically better. If the abstraction is too fine, the agent still faces the original long-horizon problem. Credit assignment is difficult because reward at the end of the episode must be traced through many small actions. Exploration is also inefficient: the agent may spend most of its time rediscovering basic behaviors instead of composing them.

If the abstraction is too coarse, the high-level policy loses flexibility. A long routine like "complete the whole order" may work in familiar conditions, but it can fail badly when an aisle is blocked, a sensor glitches, or a human steps into the workspace. Good temporal abstractions sit between these extremes: long enough to simplify planning, short enough to adapt.

One way to write the hierarchy is:

ot∼μ(o∣st),at+i∼πo(a∣st+i) until βo(st+i)=1o_t \sim \mu(o\mid s_t), \qquad a_{t+i}\sim\pi_o(a\mid s_{t+i}) \text{ until } \beta_o(s_{t+i})=1

The manager policy μ\mu selects an option or skill oo. The option's internal policy πo\pi_o chooses primitive actions. The termination rule βo\beta_o decides when control returns to the manager. The duration is variable: one option might end after two steps, another after fifty.

Equation walkthrough

Executing an option over time

Click each piece to see how an option observes, acts, repeats, and eventually hands control back to the manager policy.

,

Intra-option action

actions while option o is active

After option oo has been chosen, its own policy πo\pi_o selects primitive actions. The index t+it+i means this keeps happening across later steps, not just at the start.

1. Start from state

The option begins at sts_t if it is allowed by its initiation set.

2. Run primitive actions

πo\pi_o controls the low-level action stream for steps t,t+1,…,t+it,t+1,\ldots,t+i.

3. Stop on termination

When βo\beta_o fires, the high-level policy chooses again.

The key idea is temporal abstraction: one high-level choice can trigger many lower-level actions before termination.
ℹ

Deployment Decision

When deploying a hierarchical agent, teams must decide what level of behavior the high-level policy is allowed to command. In robotics, this might mean choosing between joint torques, motion primitives, object-level skills, or whole task routines. In digital systems, it might mean choosing between single API calls, workflows, or multi-step user journeys.

Checkpoint

What is the main benefit of temporal abstraction in hierarchical RL?