NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.6 Apply logic trees, prompt chains, and stateful orchestration for multi-step reasoning.
Validate results before advancing prompt chains
Completed by the knowledge check
Learning objective
Build prompt chains that pass validated, typed intermediate results
Core idea
A prompt chain divides a task into stages whose outputs become the next stages’ inputs. The useful boundary is a validated result, not a paragraph that another model must reinterpret. Define what each stage produces, check it, and advance only when the next stage can consume it.
In NVIDIA NeMo Agent Toolkit, workflow._type: sequential_executor supplies the fixed execution order. Functions supply typed interfaces and Pydantic schemas. These mechanisms answer different questions: can adjacent interfaces compose, and does this particular result satisfy its schema? Neither proves that an extracted fact is true.
How it works
Define the result before the next prompt
Suppose an analytics assistant extracts an invoice, calculates totals, and explains discrepancies. Give extraction a result type containing invoice identity, currency, line items, and source references. Give calculation that same input type rather than an unstructured extraction transcript. The explanation stage receives calculated results, not instructions to recover numbers from prose. Constrain the extraction call’s output to the intermediate schema (see 0.6), then validate it at the function boundary.
In NeMo Agent Toolkit, functions wrap operations with type validation, conversion, and schemas. Their input schema and supported single-output or streaming-output schemas are Pydantic BaseModel classes. Annotate the callable’s parameters and return type when registering it with FunctionInfo.from_fn(). The custom-function interface also permits an explicit input_schema when callable annotations cannot express the required validation.
Put required fields and allowed values in the intermediate schema. Put cross-field business checks in the appropriate validation function: for example, whether every extracted line belongs to the same invoice and whether the calculated total agrees with the source. A structurally valid currency string does not establish that it matches the document. Return a validated application result after those checks, rather than letting the next prompt decide whether the previous stage succeeded.
Keep the intermediate object focused on downstream dependencies. Passing every preceding prompt and response increases the tokens the next model reads and makes it harder to distinguish extracted data from instructions. Include source references when the downstream task needs attribution; do not substitute the extractor’s narrative for the source identity.
Check adjacent interfaces before execution
Configure the executor’s tool_list in dependency order. Each function’s output becomes the next function’s input. A short configuration illustrates the boundary; the named functions must be registered and configured separately:
workflow:
_type: sequential_executor
tool_list: [extract_invoice, validate_invoice, explain_invoice]
raise_type_incompatibility: true
return_error_on_exception: falseraise_type_incompatibility controls a check based on function type annotations before the tool list executes. Its documented default is False: an incompatibility produces warnings and execution continues. Setting it to True turns an incompatible chain into an exception before stage execution. For a pipeline whose stages share explicit result types, this prevents spending model calls on a composition already known to be invalid.
A compatibility check does not inspect an invoice that has not been extracted yet. Runtime schema validation must still reject malformed stage data. Conversely, a compatible str-to-str pipeline can pass its annotation check while carrying an unusable answer. Broad types make composition permissive; they do not make outputs reliable.
Make conversions explicit
NeMo Agent Toolkit supports custom converters supplied through FunctionInfo.from_fn(..., converters=[...]) or FunctionInfo.create(). A converter is annotated with its source and target types and belongs to the function receiving that conversion behavior. Use one when a deliberate representation change is necessary, such as adapting an external record into the chain’s intermediate type.
The sequential-executor documentation advises disabling the compatibility exception when custom converters make a chain executable despite an annotation mismatch. That is a specific trade-off: the pre-execution checker can reject a combination that runtime conversion supports. If you choose raise_type_incompatibility: false for that reason, exercise the converter with representative valid and invalid records. A warning is not proof that conversion succeeds.
Avoid a converter that turns every error into a string accepted by the next stage. It preserves nominal composability while losing the distinction between a result and a failure. Validate the converted object before it becomes the next prompt’s data.
Stop failed chains deliberately
return_error_on_exception: false, the documented default, re-raises an exception from a failed tool. With True, the executor exits early and returns an error message as workflow output. It does not repair the failed result and continue through the remaining functions. Choose the setting according to whether the calling application handles exceptions or expects an error response.
For intentional early termination, the documented SequentialExecutorExit exception lets a tool return a custom workflow message. Keep intentional rejection distinct from an unexpected exception so callers can explain whether the input failed a business check or the implementation failed.
raise_type_incompatibility decides whether an incompatible chain reaches stage execution, and return_error_on_exception decides how a failed tool ends it.
Output mode matters too. Functions expose ainvoke() for single outputs and astream() for streaming outputs; the executor’s tool_execution_config.<tool>.use_streaming selects streaming behavior. Its type-compatibility validation considers output mode. Prefer a complete validated intermediate result when a downstream calculation needs the whole record. A fragment arriving earlier is not yet a complete invoice. LangChain’s prompt-chaining example places a programmatic check_punchline function on add_conditional_edges() between model calls, illustrating how a graph selects the next stage from a validation result.
Key distinctions and trade-offs
The following choices separate chain composition from result acceptance:
| Check | Deciding question | Mechanism | Cost or limitation |
|---|---|---|---|
| Interface compatibility | Can adjacent stages compose? | raise_type_incompatibility and annotations | Runs before execution; does not inspect generated facts |
| Runtime structure | Does this value fit the intermediate type? | Function Pydantic schemas | Validation and possible coercion; structure is not truth |
| Representation conversion | Can an accepted representation become the required type? | Function-local converters | Additional adapter behavior to verify |
| Business correctness | Do the fields satisfy the task’s rules? | An explicit validation function in tool_list | Requires source data or business rules |
Fixed chains make dependencies visible but serialize their latency. The sequential executor neither dynamically chooses steps nor executes them in parallel. If a result changes which step should run, use the routing mechanism in 1.6.2 rather than hiding a growing decision tree inside prompts.
Architecture / decision scenario
A wholesale distributor’s invoice assistant processes 6,000 documents nightly and must finish each document within a 12-second per-document budget. Extraction takes 4 seconds, deterministic validation 0.1 seconds, and explanation 3 seconds in the team’s measurements. The finance engineering owner must choose between a text-only two-prompt pipeline and a typed extraction–validation–explanation chain.
In a 500-document trial, 30 extractions omit currency. The text-only proposal sends all 500 to explanation, where plausible wording hides missing data. The extraction schema represents unresolved currency explicitly; validate_invoice requires a resolved currency before explanation. The typed proposal sends those 30 to manual review and explains the 470 accepted records. For the accepted path, the measured stage times total 7.1 seconds. At the trial’s 6% rejection rate, about 360 nightly documents need manual handling; at two minutes per document, that requires 12 staff-hours. Finance agrees to fund that work rather than send unverified invoices onward.
The owner selects registered typed functions, raise_type_incompatibility: true, and return_error_on_exception: false, with no custom converter in this chain. For the 30 business rejections, validate_invoice raises SequentialExecutorExit with a manual-review message; it uses the same intentional exit for totals inconsistent with source lines. Unexpected implementation exceptions are re-raised, and the application maps them to a failed-document outcome. This keeps planned rejection separate from implementation failure.
Common exam traps
- Treating a pre-execution annotation check as validation of generated values.
- Assuming the default compatibility setting stops an incompatible chain.
- Passing an error message as successful intermediate data.
- Equating schema conformity with source correctness.
- Expecting a sequential executor to select a different next step from intermediate results.
Where the exam guide differs
The study guide says “prompt chains”. NeMo Agent Toolkit implements fixed chains with sequential_executor over functions, which can include model calls. It cannot choose a different next step from an intermediate result or send a failed result back for repair. A validation decision that retries an earlier stage needs a graph conditional edge (see 1.6.3), rather than a sequential-executor setting.
What to remember
Define each intermediate result, validate its structure and business meaning, and pass only accepted data to the next stage. Use tool_list for order, raise_type_incompatibility for pre-execution composition checks, and function schemas for runtime validation. Explicit converters and failure outcomes preserve the meaning of the chain’s boundaries.
Knowledge check
A NeMo Agent Toolkit sequential_executor chains extract_invoice, validate_invoice, and explain_invoice, with no custom converters. A refactor changed validate_invoice’s input annotation so it no longer matches extract_invoice’s output; the workflow still started, spent extraction calls, and failed later. Which change stops such a chain before any stage runs?
raise_type_incompatibility: true on the executorreturn_error_on_exception: true on the executorinput_schema on validate_invoicevalidate_invoice functionFalse , only warns and lets execution continue, which is what happened here. return_error_on_exception and a runtime schema both act after a stage has run, so the extraction calls would already be spent, and a converter is a deliberate representation change rather than a check.An extraction stage and an explanation stage both take and return str, and the chain passes its type-compatibility check with raise_type_incompatibility: true. In a trial, 6% of extractions omit the currency, and the explanation stage still writes plausible summaries for them. Which change stops those records before explanation?
return_error_on_exception: true on the executorstr -to- str chain is compatible by annotation while carrying unusable data, because the pre-execution check never inspects generated values. A typed intermediate result plus an explicit validation function in tool_list rejects the incomplete record instead of letting the next prompt decide whether the previous stage succeeded; return_error_on_exception changes only how an exception ends the chain, and here nothing raises.A chain adapts an external supplier record into its invoice type with a custom converter on the receiving function. With raise_type_incompatibility: true, the executor refuses to start, although a manual test shows the conversion works. The chain must keep its typed invoice result. What should the team do?
strreturn_error_on_exception: true to let the chain startraise_type_incompatibility: false and test the conversionraise_type_incompatibility to False when functions in the tool list include custom converters, because the annotation-based check can fail although the executor can run the chain. Once the check only warns, nothing proves the conversion succeeds, so representative valid and invalid records must exercise it; widening the types to str hides the mismatch instead of resolving it.In a sequential invoice chain with return_error_on_exception: false, validate_invoice finds totals that disagree with the source lines. The calling application must show a manual-review message for such invoices and treat unexpected exceptions as failed documents. How should validate_invoice end the chain for this business rejection?
SequentialExecutorExit with the manual-review messageValueError and set return_error_on_exception: trueSequentialExecutorExit is the documented way for a tool to end the chain intentionally and return a custom message, distinct from return_error_on_exception , which handles unexpected errors. Turning every exception into an error message would erase the difference the application needs, and returning the message or an empty invoice as ordinary output passes a failure to the next stage as if it were data.References
- NVIDIA, Configure With the Sequential Executor
- NVIDIA, Functions
- NVIDIA, Writing Custom Functions
- LangChain, Workflows and agents
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide