NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.2 Apply reasoning frameworks (chain-of-thought, task decomposition).

Verify inputs before dependent subtasks

Completed by the knowledge check

Learning objective

Decompose complex requests into verifiable, dependent subtasks. Choose task boundaries that let an agent establish useful facts before another operation depends on them.

Core idea

A decomposition is useful when each subtask produces an observable result that another step can consume or a final check can assess. “Research the issue, analyze it, and write a good answer” names activities but hides their inputs, dependencies, and completion criteria.

Instead, identify what the final decision requires, which authoritative operation supplies each fact, and which later steps use it. Separate missing information from a negative finding. If an inventory lookup fails, a dependent recommendation cannot treat that failure as proof that inventory is zero. Typed intermediate-result handling is covered in 1.6.1; the decision here is which intermediate results the task needs in the first place.

How it works

Work backward from the deliverable

Start with a final acceptance condition. For a purchasing assistant, “recommend an eligible replacement with a verified delivery date” implies several different facts: the required specification, eligible replacements, available stock, and supplier delivery commitments. Each has a different source and a different way to fail.

Create a subtask specification for each result. As application-defined fields, record required_inputs, produced_result, verification, and blocked_dependents. These names describe a design artifact; they are not NeMo Agent Toolkit settings. A meaningful specification says, for example, that a stock lookup consumes an identified part and site, produces a timestamped quantity, and is verified against the inventory service’s response for that exact pair.

Choose a boundary where verification changes what may run next. Splitting “write the recommendation” into three differently worded prose prompts adds calls without establishing another fact. Combining eligibility and stock into one free-form answer hides which source rejected a candidate. The useful granularity is a result with a distinct consumer and a distinct acceptance check.

Express dependencies as data references

NeMo Agent Toolkit’s rewoo_agent offers a concrete representation of dependent tool work. Configure the selected model through llm_name and the available functions or function groups through tool_names. The agent requires the nvidia-nat[langchain] plugin.

Its planner produces a JSON array of steps. Each step contains plan and an evidence object with placeholder, tool, and tool_input. A later step can refer to an earlier result using a placeholder such as #E1; execution replaces that reference with the actual tool result before the solver generates the answer. This makes “use the identified part” more precise than copying an assumed identifier into every prompt.

The representation is not a proof that the result is correct. If #E1 contains the wrong product identity, every dependent lookup can faithfully operate on the wrong product. Assign verification to the function that obtains or transforms the result. For custom Toolkit functions, FunctionInfo.from_fn() derives input and output types from annotated callables; use those typed inputs to keep identifiers and units explicit. Then implement the domain check against the authoritative response, as described in 1.6.1.

The distinction is practical: structural validation can establish that quantity is numeric, while the task’s verification must also establish that the quantity belongs to the requested site and part. A successful HTTP call alone establishes neither. Make the verified result, rather than an unexamined paragraph, the input to dependent reasoning.

Classify what can run independently

Two subtasks are independent only when neither needs the other’s result and their outputs remain valid together. Retrieving two supplier offers for an already verified part can be independent. Selecting a part and checking its stock cannot be independent when the stock request needs the selected part’s identifier.

LangGraph’s documented orchestrator-worker pattern illustrates dynamic decomposition: an orchestrator identifies work, workers complete individual assignments, and a synthesizer combines their results. Its Python implementation uses Send for dynamically dispatched worker inputs and shared state for collected results. Use that mechanism only when the request’s work items vary; a fixed set of checks can remain a predefined workflow. See 5.3.2 for representing the execution structure itself.

Choose the decomposition before choosing the amount of concurrency. Parallel calls on guessed inputs can be fast but irrelevant. Passing a complete transcript to every worker also makes each worker repeat interpretation that an earlier, verified result could have settled once.

Stop propagation at the failed dependency

For rewoo_agent, raise_tool_call_error defaults to True: a tool failure raises an exception immediately. With False, the tool error message is included in the tool response and passed to the next tool. That alternative can support recovery, but an error message occupying a result placeholder is not usable business data.

A tool failure either raises an exception immediately or passes its error message to the next tool.

If a tool cannot establish a required fact, stop the dependent work or return an explicit incomplete result. Error classification belongs to 2.4.1; the decomposition-specific consequence is that unaffected results may remain useful while descendants of the failed result lack their required input. Retrying the entire request can repeat successful lookups and still preserve the original mistaken assumption.

ReWOO plans up front and has limited adaptability when tool failures or observations require a different approach. Do not solve that limitation by pretending a missing dependency succeeded. Replanning strategy belongs to 5.3.3; this lesson establishes which result invalidated the original decomposition.

Key distinctions and trade-offs

These task boundaries serve different purposes:

Boundary	Deciding condition	Mechanism	Cost
One deterministic function	One authoritative operation can establish the result	Annotated callable exposed with `FunctionInfo.from_fn()`	Small orchestration cost, less flexibility
Dependent tool subtasks	Later inputs require earlier observations	ReWOO `evidence.placeholder` and `tool_input` references	Up-front planning and propagation risk
Independent worker assignments	Work items vary and each can finish without sibling outputs	LangGraph `Send` and collected worker results	More calls and synthesis work
Final synthesis	Required results have passed their checks	ReWOO `solver_prompt` or a workflow synthesizer	Another generation that still needs a final acceptance check

More subtasks increase opportunities to localize a defect, but also increase model calls, tool traffic, and intermediate data. Fewer subtasks reduce coordination while potentially hiding an unverifiable inference. Split where a result can be checked and reused, rather than at every sentence in a plan.

Architecture / decision scenario

A factory purchasing assistant must propose a replacement valve within a 12-second response target. The business requires the same pressure rating, a verified fit, and delivery within 48 hours. Its service owner measures 1 second for specification lookup, 2 seconds for compatibility lookup, 3 seconds per supplier quote, and 1 second for synthesis; these are scenario assumptions.

A tempting design sends the original request to three supplier agents immediately and asks each for a complete recommendation. That repeats product interpretation and lets each agent choose a different valve before compatibility is established. The owner instead verifies the equipment specification, obtains compatible part identifiers, then dispatches the three quote checks for those identifiers independently. The illustrative critical path is 1 + 2 + 3 + 1 = 7 seconds, whereas serial quote checks take 13 seconds and miss the target.

Each quote must identify the verified part and include its delivery commitment. If compatibility lookup fails, quote-dependent recommendations stop. If one supplier times out, synthesis may compare the two verified offers while declaring the missing offer, provided the business accepts partial supplier coverage. It cannot declare that all suppliers were checked or infer that the failed supplier has no stock. The purchasing service owner defines that completeness rule before the decomposition is deployed.

Common exam traps

Mistaking a list of activities for subtasks with verifiable outputs.
Parallelizing work before its required identifiers are known.
Treating placeholder substitution as semantic validation.
Passing a tool error onward as though it were the required observation.
Decomposing every operation into another agent despite a sufficient deterministic function.
Calling a partially checked supplier set a complete search.

What to remember

Work backward from the final acceptance condition. Give each subtask a required input, an observable result, a verification method, and named dependents. Dependencies determine which work may start and which work must stop when a fact cannot be established.