NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.2 Implement reasoning and action frameworks (e.g., ReAct).
Choose reactive, deliberative, or hybrid control
Completed by the knowledge check
Learning objective
Compare reactive, deliberative, and hybrid agent architectures.
Core idea
Recall from 0.4 that agents select operations dynamically while predetermined workflows follow application-defined paths. Here, compare the planning horizon: reactive control selects an immediate response to an observation, deliberative control constructs a plan before execution, and hybrid control combines upfront planning with an executor that can respond to observations.
These are architectural descriptions, not three NVIDIA configuration values. A system can produce an explanation that is not an executable plan. Ask whether it selects one branch, represents a sequence before acting, or combines that sequence with observation-driven execution. Each choice spends inference differently and fails at a different point.
How it works
React to the observation
A reactive design maps an event or observation to an immediate action without first constructing a multi-step plan. This can be a fixed rule or model-based selection. The distinction matters: a model selecting one branch is reactive, but its choice is not deterministic business logic.
NeMo Agent Toolkit provides single-step model selection through _type: router_agent. It requires nvidia-nat[langchain]. Configure branches with the available functions or agents and llm_name with the configured routing model. The router analyzes the request using branch descriptions, invokes one selected branch with the original input, and returns its result. The selected branch may itself be complex; the router’s own horizon is one selection.
This fits a request such as choosing shipment status versus carrier investigation. It avoids generating a multi-step plan just to select a service. The router still pays for model inference, and routing quality depends on branch descriptions and the model’s understanding of intent. If delivery enquiries repeatedly reach a billing branch, improve those descriptions and evaluate routing accuracy rather than adding a planner to every request.
The documented limitations are consequential: one branch per request, no multi-step routing or branch combination, and no communication between branches within a request. Selecting two independent services and merging their findings therefore requires a different composition. For an already known fixed sequence, use sequential_executor; see 0.4 rather than treating fixed execution as deliberation.
Deliberate over a sequence
A deliberative design represents steps and dependencies before executing them. It is useful when the requested outcome implies several operations whose ordering must be discovered. Its initial inference cost buys a task-specific sequence rather than merely choosing one handler.
The toolkit’s _type: reasoning_agent reasons about the input and the underlying function, then passes a plan to that function through augmented_fn. llm_name selects the planning model, which the documentation requires to support thinking tags such as <think></think>. The implementation requires nvidia-nat[langchain]. Its upfront planning does not revisit the strategy during execution.
An explicit plan makes the intended sequence inspectable, but it also predicts what information the tools will return. An ambiguous entity or empty retrieval can invalidate later steps. When observations often invalidate the plan, cheaper planning buys more runs that finish but cannot be used. The owner must evaluate useful completed tasks, not only the time needed to generate a plausible plan.
ReWOO is another toolkit implementation of upfront planning, selected with _type: rewoo_agent. See 1.2.3 for its planner, executor, solver, and placeholder interface. Here its architectural relevance is the same: choose a planned sequence when its structure remains useful after actual observations arrive. Do not infer adaptability from the mere presence of multiple planned steps.
Combine planning with reactive execution
A hybrid design gives deliberation and observation-driven execution distinct jobs. The planner proposes how to approach the goal; the executor uses actual tool results while pursuing it. This can preserve a useful initial strategy without forcing every later action to follow assumptions made before the first lookup.
The reasoning-agent documentation shows this composition with augmented_fn: react_agent. The named function must be defined in the YAML configuration. Configure that function under functions with _type: react_agent, its own llm_name, and a narrow tool_names list. The reasoning wrapper supplies the plan to the ReAct executor. See 1.2.2 for the executor’s loop and termination controls.
The wrapper does not become a continuously replanning supervisor. Its own reasoning occurs upfront; adaptation during execution belongs to the underlying ReAct agent. A plan supplied as guidance also does not enforce which tools the executor may call. The executor’s tool_names defines that selection boundary.
This composition pays for both initial planning and iterative inference. Use it when a task benefits from an initial strategy and later observations can change the useful next operation. For a single known lookup, those extra decisions add cost without resolving uncertainty. For an investigation, they may prevent a plan from continuing through irrelevant or missing results.
Key distinctions and trade-offs
Compare the designs by their planning horizon and failure mode:
| Dimension | Reactive | Deliberative | Hybrid |
|---|---|---|---|
| Horizon | Select an immediate response | Represent a sequence before acting | Plan first, adapt during execution |
| Toolkit example | router_agent | Upfront reasoning_agent or rewoo_agent | reasoning_agent wrapping react_agent |
| Main cost | Routing inference and branch maintenance | Plan generation and invalid assumptions | Planning plus iterative execution |
| Main failure | Wrong or insufficient branch | Observations invalidate the sequence | Poor guidance or unproductive execution |
Reactivity is not a synonym for ReAct. ReAct alternates reasoning and action across observations; see 1.2.2. Likewise, routing into a planning branch does not make the router itself deliberative. Classify the component at the level whose decisions you are comparing.
A hybrid is not automatically the cheapest choice. Its owner must distinguish whether failures originate in branch selection, initial planning, or execution. A useful plan cannot repair an incorrect route, and a correct route cannot make an unavailable tool return information. Assign each improvement to the component that owns the failed decision.
Architecture / decision scenario
A distributor builds an employee assistant for 8,000 daily delivery enquiries. In this hypothetical workload, 90% are shipment lookups with a 2-second target; 10% require investigation within 12 seconds. The two-engineer operations team cannot enumerate every combination of carrier notes.
A controlled pilot measures routing at 0.3 seconds and one lookup at 0.5 seconds. Upfront planning adds 1.8 seconds. The tempting proposal is one deliberative workflow for everything, but planning plus a lookup already costs 2.3 seconds before other overhead. The architect uses router_agent with branches for a lookup function and an investigation agent. A routed lookup takes about 0.8 seconds under these assumptions. Descriptions must distinguish status requests from causal investigations.
For investigations, single-branch selection alone cannot discover and execute a sequence across carrier records. A planned sequence is more promising: in 100 pilot investigations, an upfront-only approach completes 60 usefully in a median 4 seconds. The reasoning-plus-ReAct composition completes 85 in a median 7 seconds because execution can react to missing or contradictory records. These are illustrative pilot figures, not product benchmarks.
The architect chooses the hybrid investigation branch: reasoning_agent passes guidance through augmented_fn to the configured ReAct specialist, whose tool_names contains only investigation tools. Its extra 3 seconds fits the 12-second target and buys 25 more useful completions per 100 attempts. The workflow owner evaluates routing accuracy separately from investigation completion and keeps the executor’s call and time controls from 1.2.2.
Common exam traps
- Treating a model-routed reactive choice as deterministic business logic.
- Expecting
router_agentto combine branches or route repeatedly within one request. - Equating reactive control with the ReAct implementation.
- Assuming the reasoning wrapper revises its own plan during execution.
- Paying for planning on a known lookup without identifying useful uncertainty.
What to remember
Choose reactive selection for an immediate response, deliberation for a useful upfront sequence, and hybrid control when execution must adapt after planning. Locate the cost and failure at the responsible component. In the toolkit’s documented hybrid, reasoning_agent supplies the plan and the augmented ReAct function owns observation-driven execution.
Knowledge check
A distributor’s assistant uses router_agent with two branches: a carrier-delay service and a billing-dispute service. Each branch answers correctly when a request concerns only its own topic. Requests such as “compare the carrier’s delay report with the billing dispute on order 4471” return an answer that covers only one of the two. What explains this?
router_agent selects one branch per request, with no multi-step routing, no branch combination and no communication between branches. A request that needs two services and a merged finding needs a different composition. Better descriptions would improve which single branch is chosen, but the problem here is that one branch is all the router can choose; the selected branch already receives the original input.An investigation workflow wraps a react_agent executor in reasoning_agent through augmented_fn. The executor’s tool_names lists the shipment lookups and also a refund-issuing function that exists elsewhere in the application. A review requires that investigations never issue refunds. Which change to the agent configuration addresses this?
tool_names listllm_name at a model that follows instructions betterrewoo_agent and a fixed upfront plantool_names defines that selection boundary. Removing the function narrows what the agent layer can call, while the refund service still owns its own authorization rules. Prompt wording and a stronger planning model only make a refund call less likely, and a ReWOO plan can still include any tool it is given.A pilot runs carrier investigations with an upfront plan that is executed as written. When the first lookup returns no record or an ambiguous carrier, later steps continue on the wrong assumption, and many runs finish without a usable result. The investigation budget leaves room for more inference per run. Which change targets this failure?
router_agent so that one investigation tool is selected per requestreasoning_agent so that the plan is reasoned more carefullyreact_agent executor in reasoning_agent so that execution adapts to each lookup’s resultreasoning_agent plans upfront and the augmented ReAct agent owns observation-driven execution; the reasoning wrapper on its own does not revisit its plan. A cheaper planner only buys more runs that finish unusable, and a router makes one selection where the task needs a discovered sequence.In a router_agent deployment with a tight latency target, evaluation shows that many delivery-status enquiries reach the billing branch. Branch latency is within budget once the right branch is chosen. What should the team change first?
reasoning_agent that plans each request before the router selects a branchsequential_executor that runs the lookup and billing stepsReferences
NVIDIA, Configure the Router Agent
NVIDIA, Configure a Reasoning Agent
NVIDIA, Configure the ReAct Agent
NVIDIA, Configure the ReWOO Agent