Is a high-level action the same as a macro?

A fixed macro is one possible form, but a high-level action can permit multiple alternative refinements.

Can it be evaluated without full refinement?

Sometimes, if the system has sound outcome or cost descriptions. Otherwise, more detail may be needed before feasibility or quality can be established.

Does primitive mean physically simple?

No. It means directly executable at the planner's chosen modeling level; another layer may implement substantial detail beneath it.

AI Glossary / Graphs and symbolic AI / Intermediate

High-level action

Definition

A high-level action is an abstract action that represents a more detailed procedure or a family of possible procedures. In hierarchical planning, it can be refined into lower-level actions until an executable sequence is obtained. It lets a planner reason about meaningful activities before deciding every primitive step needed to carry them out.

What it means

An action such as move the parcel to the loading area summarizes work that may involve navigation, picking up the parcel, carrying it, and placing it down. The summary gives the planner a useful unit of choice without exposing every detail at once.
High-level is relative to the model. An action treated as primitive by one planner may itself be implemented by a complicated controller. A high-level action can also have several refinements rather than one fixed macro. Its name alone does not establish what it achieves, when it applies, or whether a valid implementation exists from the current state.

How it works

Define the abstract action and its permitted refinements. Each refinement replaces it with a sequence or structure of lower-level tasks and actions, subject to the planning formalism's conditions. The planner can choose among alternatives, refine further, and verify that the eventual primitive actions are applicable.
Some systems provide descriptions of a high-level action's possible outcomes or cost bounds. Those summaries can support reasoning before complete refinement, but their semantics must be explicit. In particular, an outcome reachable by some refinement should not be mistaken for an outcome produced by every refinement. Cost and feasibility can depend on the initial state and chosen implementation.

Three practical examples

A route-planning hierarchy uses ReachStation as a unit that can be refined into several possible street routes.
A workflow model represents PrepareReport as lower-level tasks for gathering data, checking it, and producing a document.
A robotics simulation uses PickAndPlace as an abstract action while a lower-level planner determines approach, grasp, transport, and release motions.

Think of it this way

Think of the instruction make tea. It identifies a recognizable activity while leaving choices such as equipment and detailed movements unresolved. The analogy is limited because a formal planner cannot rely on everyday understanding alone; it needs explicit refinements, relevant conditions, and an account of how the abstract action relates to its concrete execution.

Worked example

Define a toy high-level action ReachB starting at location A. It has two permitted refinements. The direct method is [MoveAtoB] with cost 7. The corridor method is [MoveAtoC, MoveCtoB] with costs 2 and 3, totaling 5. Both end at B when their preconditions are satisfied.
If the corridor is open, ReachB has a feasible cost-5 refinement and a feasible cost-7 refinement. The abstract action therefore does not have one implementation-independent execution cost unless the model explicitly defines a value such as the minimum over valid refinements.
If the corridor becomes closed, the two-step method may no longer apply while the direct method remains valid. The least cost among these permitted refinements rises to 7. If the direct path also becomes unavailable, the action's familiar name does not make it executable. The planner must report failure within this refinement set or seek another permitted method. This example separates the abstract label, its alternative implementations, and the state-dependent facts that make an implementation possible.

Illustrative case study

In a fictional simulation, Brook Planner presents ReachB as one box in its user interface. Early reports assign that box a fixed cost of 5, even when the corridor used by the cheapest method is unavailable.
The team changes the display to show the currently selected refinement and its checked cost. When no refinement is established, the interface marks the abstract action as unresolved instead of presenting it as completed planning work. The invented case illustrates clearer communication between abstract planning and executable detail, without claiming a measured operational benefit.

Common misconceptions and mistakes

A high-level action is not necessarily a single indivisible event, a fixed sequence, or an action with constant duration. Its implementation can vary with conditions and choices. A hierarchy with one refinement per task is only a particular case.
Do not assume an optimistic outcome description is a guarantee that every execution achieves that outcome. Similarly, a cost lower bound is not an executable plan at that cost. High-level actions also do not automatically preserve all globally optimal solutions: restricting available refinements can rule out useful sequences even when the remaining methods are valid.

Business use

High-level actions help organize reusable planning knowledge around activities that people recognize. They can make plans easier to explain and reduce the need to reason from primitive actions at every decision point. Their usefulness depends on how well the abstraction matches the tasks and conditions the system encounters.
For a project, record each action's intended meaning, applicability, refinements, and failure conditions. Specify whether cost information is an estimate, a bound, or the cost of a known implementation. Check the boundary between the abstract planner and the executing component so that an unresolved label is not mistaken for an operationally ready instruction.

Check your understanding

Why can ReachB cost 5 in one state and 7 in another?

Answer: The cheaper corridor refinement is available only when its conditions hold. If it is unavailable but the direct refinement remains valid, the least permitted cost becomes 7.

Related terms

Abstraction
Task decomposition
hierarchical planning
refinement
primitive action
planning method
macro action
hierarchical optimality

Learn next

Write two refinements for one abstract task and list their distinct preconditions. Then compare a possible-outcome description with a guaranteed-outcome description. This makes clear which claims can be made before choosing and checking a concrete implementation.

Sources

Sources: Marthi, Russell, and Wolfe, Angelic Hierarchical Planning: Optimal and Online Algorithms: https://aima.cs.berkeley.edu/~russell/papers/icaps08-hla.pdf University of Maryland SHOP project, task decomposition: https://www.cs.umd.edu/projects/shop/description.html

Previous: High frequency data Next: High-pass filter