NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.3 Engineer planning strategies for sequential and multi-step decision-making.

Choose upfront, interleaved, or hierarchical planning

Completed by the knowledge check

Learning objective

Compare plan-then-execute, interleaved, and hierarchical planning.

Core idea

Choose a planning strategy by asking what can be decided before tools return, and who owns the remaining decisions? Plan-then-execute commits to a sequence before collecting its results. Interleaved planning chooses the next action after observing the previous result. Hierarchical planning assigns a goal to a child planner while a parent retains responsibility for the overall outcome.

These choices describe different dimensions. Upfront versus interleaved concerns when decisions happen; hierarchy concerns where they happen. A parent can plan three work packages upfront while each specialist interleaves local actions with observations. Adding specialists does not automatically make an otherwise brittle plan adaptive.

Task decomposition is covered in 5.2.2, and agent topology in 1.5.1. Here, the decision is how much of the future to commit to before receiving information that could change it.

How it works

Commit a stable procedure upfront

Recall from 1.2.3 that NeMo Agent Toolkit’s workflow._type: rewoo_agent separates planning, execution, and solution, using placeholders for dependent results. The agent requires nvidia-nat[langchain]; its tool interface and planner format are covered there.

Here, make the commitment horizon explicit in the proposed plan: which steps remain useful regardless of the preceding values, and which assume one particular outcome? If several branches depend on observations, prewriting every possible branch can become more expensive to review than deferring the decision. The planning artifact should identify those decision points rather than disguise assumptions as ordinary steps.

An upfront plan suits tasks whose procedure is predictable even when values are unknown. Looking up a reporting date and then retrieving that date’s figures has an unknown value but a known dependency. By contrast, discovering that the reporting system excludes an acquired subsidiary might require another source and a different procedure. NVIDIA’s ReWOO documentation identifies limited adaptability to unexpected failures or information as a limitation.

Use additional_planner_instructions to state the task-specific planning requirement while retaining the component’s base planner format. For example, require a source lookup before a calculation that depends on it. That instruction helps the planner express a known prerequisite; it does not establish that the source is appropriate for every observation. Accept an upfront strategy only when representative runs show that the proposed procedure survives the results it receives.

Observe before choosing again

Recall from 1.2.2 that workflow._type: react_agent chooses actions from observations and uses max_tool_calls to bound tool use. Its loop mechanics remain there; the planning question is which decisions actually benefit from another observation.

Place a decision after an observation when the result changes the next useful action. An ambiguous entity can require disambiguation before research; an absent source can require an alternative retrieval path. Do not insert model deliberation between deterministic steps merely to make the workflow appear adaptive. If every valid result leads to the same next tool with a substituted argument, the extra decision adds latency without changing the procedure.

Interleaving also moves uncertainty from the proposed plan into runtime. You can inspect the first action before execution, but later tool choices depend on results that do not yet exist. Evaluate representative trajectories for unnecessary detours and remaining-task coverage, rather than approving only the initial plan. Keep tool_names restricted to the task’s permitted action set while letting observations select within it.

Interleaving does not guarantee progress. If a tool repeatedly returns the same unhelpful result, another reasoning turn can repeat the same choice. Define success checks and an exit budget rather than treating continued activity as useful work; see 5.3.2 and 5.3.3.

Delegate a bounded subplan

Recall from 1.5.1 that NVIDIA exposes agents under functions through a parent’s tool_names; functions.math_agent._type: react_agent is a documented example. For hierarchical planning, the important additional choice is the boundary between a parent goal and a child’s local decisions.

Write each delegated work package as an outcome with required inputs and a returned artifact. The parent decides which packages exist and how they depend on one another. The child chooses a local procedure within its own tool_names. If two children must repeatedly renegotiate a shared assumption, move that assumption’s decision to the parent before dispatching them. Separate planning responsibility where a local result can be checked without reconstructing the child’s entire investigation.

LangGraph’s orchestrator-worker pattern (see 5.2.2) makes the corresponding planning responsibility explicit: an orchestrator generates work, delegates it, and synthesizes returned outputs. Its Python Send API dispatches worker-specific inputs when the number of subtasks is determined during execution. Use this when the scope itself is discovered dynamically, rather than expressing a known fixed list as unnecessary delegation.

Hierarchy costs worker context, additional model calls, and parent synthesis. A child that returns a polished but incomplete result can also conceal a local failure. The parent therefore needs a returned artifact and acceptance condition, not merely a child message saying the work is done. Specialist lifecycle mechanics belong to 1.5.2; the planning consequence is that the parent owns cross-specialist dependencies and final acceptance.

Key distinctions and trade-offs

Compare the strategies by the uncertainty each one can absorb:

Strategy	Deciding condition	Mechanism	Main cost	Mechanism taught in
Plan-then-execute	Tool order is known before results arrive	`rewoo_agent`, planner/executor/solver	Upfront planning and invalidated future steps	1.2.3
Interleaved	Observations determine the next useful action	`react_agent`, bounded `max_tool_calls`	Serial decision latency and repeated context	1.2.2
Hierarchical	Work packages need distinct local plans	Agent functions in `tool_names`; LangGraph `Send` for dynamic workers	Delegation, worker context, and synthesis	1.5.1 / 5.2.2

NVIDIA’s hybrid form uses workflow._type: reasoning_agent to produce a plan and pass it through augmented_fn to an agent such as react_agent (see 1.2.1); it requires nvidia-nat[langchain] and an llm_name model that supports thinking tags. This hands planning guidance to an adaptive executor rather than creating a dependency-checked schedule.

A dependency alone does not require an adaptive agent: substituting a date into a known query is different from choosing an unanticipated data source. Likewise, independent work does not require multiple planners. Fixed parallel calls can be ordinary workflow branches. Select hierarchy when local planning responsibility earns its overhead.

Architecture / decision scenario

A consumer-goods company runs a research assistant that prepares acquisition briefs. Its acceptance target is a complete brief within 90 seconds. In a hypothetical comparison, the team measures 38 seconds for an upfront plan, 61 seconds for an interleaved agent, and 74 seconds for a parent with specialists. These are scenario measurements, not product performance claims.

For routine quarterly updates, the sources and calculation order are fixed. Choose rewoo_agent: the 23-second difference from interleaving buys no necessary discovery. A practitioner proposes using the same plan for acquisition research, but 30 of 100 trial requests reveal a subsidiary or jurisdiction that changes the required sources. Only 4 of 100 routine updates do so. That difference makes the fixed procedure unsuitable for the discovery-heavy requests.

For a single uncertain jurisdiction, choose bounded interleaving. For a brief covering financial filings, product exposure, and jurisdiction-specific obligations, choose a parent with three bounded specialist work packages, allowing local interleaving inside them. The 74-second measured path fits the target, while giving each specialist responsibility for selecting its sources. The parent checks that all three outputs address the same acquisition before synthesis.

The application architect owns this routing decision. The team should reject hierarchy for every routine update: it consumes another 36 seconds in the comparison and adds coordination without a corresponding need for local planning. It should also reject unlimited interleaving as an answer to uncertainty; the 90-second target still applies to every branch.

Common exam traps

An unknown result always requires interleaving. A fixed procedure can substitute results through known dependencies.
Hierarchy and upfront planning are mutually exclusive. A parent can plan upfront and delegate adaptive subplans.
A specialist counts as successful when it returns text. Its output still needs acceptance against the assigned goal.
A faster initial answer proves the strategy is better. Compare accepted task outcomes within the deadline, including failed and abandoned runs.

What to remember

Commit upfront when the procedure is stable, interleave when observations change the procedure, and delegate when a work package needs its own planning responsibility. A hybrid earns its complexity only when the resulting accepted outcomes justify its added latency and token cost.