NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.2 Implement reasoning and action frameworks (e.g., ReAct).
Choose ReAct, tool calling, or ReWOO
Completed by the knowledge check
Learning objective
Compare ReAct with native tool-calling and plan-then-execute (ReWOO) agents.
Core idea
Two independent questions drive this comparison: how does the model express a tool invocation, and when does it decide the next step? Native tool calling concerns a structured model interface. ReAct concerns an iterative reasoning-and-action pattern, implemented by NeMo Agent Toolkit with a text protocol. ReWOO moves planning before tool execution and uses gathered results in a later solution phase.
Select from the task’s uncertainty and the model’s supported interface. A structured call can still select the wrong tool. An explicit plan can still assume the wrong sequence. An iterative loop can still spend its entire budget reconsidering a bad premise.
How it works
Use ReAct when observations change the path
Recall from 1.2.2 that workflow._type: react_agent uses Thought, Action, Action Input, and tool-supplied Observation before producing Final Answer. The defining benefit is the opportunity to reconsider the next action after each result. This suits research where a lookup can reveal that the initial entity was ambiguous or that a different source is necessary.
The implementation also carries a text-parser boundary. A model that produces a plausible answer in the wrong format can fail before any tool executes. Its documented limitations include prompt sensitivity, repeated LLM calls, and sequential execution. Those costs matter when independent lookups dominate the workload: additional reasoning between them may add latency without changing their selection.
Use the loop controls taught in 1.2.2 to bound that behavior. Choosing ReAct is a decision to pay for adaptation, not permission to leave execution open-ended. If evaluation shows that the same sequence is selected regardless of observations, consider whether the loop is solving any actual uncertainty.
Use native tool calling for structured selection
NeMo Agent Toolkit selects its tool-calling implementation with _type: tool_calling_agent. Its tool_names exposes configured functions or function groups, while llm_name selects the configured model. The implementation requires nvidia-nat[langchain] and a model that supports tool or function calling.
The model uses a tool’s name, description, and input parameter schema to select an invocation. This removes the need for the specific textual ReAct action format. It does not remove the need to choose meaningful names and parameters. A schema may accept a location string while the model supplies the wrong city; interface structure does not settle semantic correctness.
The toolkit documents handle_tool_errors, defaulting to True, which catches tool errors and returns an error ToolMessage so the agent can retry. Its max_iterations defaults to 15 and is described as the maximum number of tool calls. In the v1.8.0 single-response path, call-budget exhaustion returns fixed error text, whereas ReAct raises GraphRecursionError; callers must recognize both failure representations. These identifiers differ from the ReAct options; copying max_tool_calls into a tool-calling configuration is not a translation of the documented interface.
NVIDIA describes this component as appropriate for structured tasks without complex reasoning between tool calls. Treat that as the scope of the component being compared, rather than a universal claim that every model using native tool calling cannot reason. The tool interface and the application’s control strategy remain separate design choices.
Use ReWOO when the plan survives execution
With _type: rewoo_agent, the toolkit separates planning, execution, and solution. This implementation also requires nvidia-nat[langchain]. The planner produces a JSON array of steps. Each step contains plan and evidence; the latter identifies placeholder, tool, and tool_input. Later steps can refer to results through placeholders such as #E1.
Execution substitutes actual results into those dependencies. A solver then uses the plan and gathered results to answer. Dependency does not require replanning: knowing that a later lookup needs an identifier from an earlier lookup is compatible with planning both operations upfront. The uncertain value can occupy a placeholder while the sequence stays fixed.
Configure planner_prompt when the planner format or instructions need adjustment, and solver_prompt when answer synthesis needs adjustment. The planner prompt must include tools and instruct the required planner format; the solver prompt must include plan and task variables. These are different responsibilities. A fluent solver cannot repair a missing source that the planner never requested.
The documented execution phase is sequential. Do not select this implementation on an assumption that an upfront plan automatically dispatches independent operations in parallel. Its efficiency comes from decoupling planning from observations and avoiding full tool outputs in each reasoning step, rather than a universal reduction in elapsed time.
Failure handling is also explicit. tool_call_max_retries defaults to 3. raise_tool_call_error defaults to True; when set to False, the error is included in the tool response and passed to the next tool. That is error propagation, not evidence that the agent constructs a replacement plan. NVIDIA identifies limited adaptability to unexpected failures or information as a limitation.
Key distinctions and trade-offs
Use these distinctions when evaluating candidate implementations:
| Criterion | ReAct | Native tool-calling component | ReWOO |
|---|---|---|---|
| Invocation representation | Parsed textual action | Structured function definitions | Planned tool inputs and placeholders |
| Next-step selection | Reconsider after observations | Select tools from schemas | Establish sequence before execution |
| Main advantage | Adapt to discovered information | Direct structured invocation | Avoid repeated planning over full results |
| Main cost | Repeated inference and parsing | Requires model support and precise schemas | Upfront planning and limited adaptation |
| Failure to investigate | Malformed action or unproductive loop | Wrong tool or arguments | Invalid plan or failed dependency |
All three configurations refer to configured tools and models; they are not substitutes for implementing those components. Keep the model endpoint and available tools comparable during evaluation, or a faster model can be mistaken for a better execution pattern.
Separate successful-task cost from attempted-task cost. ReWOO may reduce repeated reasoning while producing more incomplete results on volatile sources. ReAct may use more tokens per completed investigation but resolve cases a fixed plan cannot. The deciding measure is useful completion within the workload’s budget, not the number of visibly labeled reasoning steps.
Architecture / decision scenario
A professional-services firm builds a research assistant with three hypothetical workloads. Staff-directory lookups have a 2-second target and need one known function. Weekly client briefs require four predictable source lookups and permit 20 seconds. Open-ended discrepancy investigations allow 30 seconds because each result may change which source is relevant.
In a controlled pilot using the same tools and endpoint, assume ReAct takes 11 seconds and ReWOO takes 7 seconds for a stable brief. For investigations, ReWOO completes 60 of 100 tasks within budget, while ReAct completes 85. These are workload measurements for the scenario, not NVIDIA benchmarks.
The tempting proposal is to standardize everything on ReWOO because it wins the brief’s latency comparison. The assistant architect rejects that generalization. Directory lookups use tool_calling_agent with a tool-capable model and a narrow tool_names list: planning a one-function request adds no useful dependency discovery. Stable briefs use rewoo_agent, with the source sequence represented in the planner’s steps and checked during pilot evaluation.
Investigations use react_agent because the 25 additional completions justify the measured iterative cost within the 30-second allowance. The workflow owner keeps the call and time controls from 1.2.2. For briefs, the owner retains raise_tool_call_error: true so a failed required lookup surfaces rather than allowing dependent steps to consume an error string. If a brief begins requiring frequent replanning, the team revisits the execution choice instead of assuming that tuning solver_prompt can fix an invalid plan.
Common exam traps
- Treating native tool calling as proof that the chosen tool or argument is correct.
- Assuming ReAct always requires a model-native function-calling interface.
- Assuming a placeholder dependency means ReWOO replans after every observation.
- Equating upfront planning with parallel tool dispatch.
- Copying retry and call-limit keys unchanged between agent types.
- Comparing latency without comparing completed-task rates on the same workload.
What to remember
Choose structured tool selection for a known operation, ReAct for observation-dependent adaptation, and ReWOO for a useful plan whose structure survives execution. Compare the documented implementations, their model requirements, and their failure paths. A cheaper attempted run is not necessarily a cheaper completed task.
Knowledge check
A weekly client brief needs four lookups in the same order every week; the third needs a client ID that the first returns. The architect wants the whole sequence in an inspectable plan before any lookup runs, without the model reasoning over full tool outputs between lookups. Which NeMo Agent Toolkit agent fits?
react_agent , resolving the client-ID dependency by reasoning after each observationrewoo_agent , carrying the client ID through an evidence placeholdertool_calling_agent , selecting each invocation from the four exposed tool schemas#E1 carries the earlier result into the later step when execution substitutes actual results. ReAct reconsiders actions after observations, while the tool-calling component selects invocations from schemas; neither configuration shown supplies the complete upfront plan required here.A team chooses rewoo_agent for four independent lookups that each take exactly 3 seconds in this scenario, expecting the run to finish in roughly 3 seconds because every step is planned upfront. Which statement describes the toolkit’s documented behaviour?
A team must run on a model endpoint that does not support tool or function calling. In its investigations, which lookup to run next depends on what the previous lookup revealed. Which NeMo Agent Toolkit agent fits?
tool_calling_agent , selecting each lookup from its input schemarewoo_agent , planning every lookup before the first one runsreact_agent , emitting each action through its text protocolAction and Action Input text and reconsiders the next action after every observation, so it needs no model-native function calling. The tool-calling agent requires a model with tool-calling support; ReWOO fixes the sequence before observations arrive.A rewoo_agent brief is configured with raise_tool_call_error: false. When a required source returns a permanent “client not found” error, dependent steps run on the error string and the solver writes a fluent but unsupported brief. The owner wants the failed lookup to surface instead. Which change does that?
raise_tool_call_error to true for the ReWOO agenthandle_tool_errors to false for the ReWOO agenttool_call_max_retries to 10 for the ReWOO agentsolver_prompt to ignore error strings in the evidenceraise_tool_call_error set to true , the default, a failed tool call raises an exception; set to false , the error text is passed on to the next tool, which is propagation rather than replanning. handle_tool_errors belongs to the tool-calling agent, more retries cannot fix a permanent error, and a solver prompt cannot repair evidence the failed lookup never returned.