NVIDIANVIDIA-Certified Professional: Agentic AI2026-107.3 Optimize workflows with the NVIDIA NeMo Agent Toolkit.
Wire named components into runnable workflows
Completed by the knowledge check
Learning objective
Define workflows, functions, and LLMs in NeMo Agent Toolkit configuration.
Core idea
A NeMo Agent Toolkit configuration selects implementations and connects named instances. The functions section defines callable components, llms defines model clients, and workflow selects the entry point. The _type field identifies a registered implementation; the surrounding YAML key identifies one configured instance of it.
See 1.8.1 for the architectural reasons to separate component interfaces. Here, your task is to make that separation executable: a reviewer should be able to follow the entry point to each tool and model, explain which settings change its behavior, and identify missing dependencies before serving traffic.
How it works
Assemble the configuration under review
See 1.8.1 for instance names versus _type and the llm_name/tool_names connections. Here, use those connections to assemble one file whose components you can discover and validate in the serving environment.
The following illustrative configuration uses environment variables for deployment-specific model settings and a documented function type:
functions:
clock:
_type: current_datetime
llms:
response_model:
_type: nim
model_name: ${MODEL_NAME}
base_url: ${NIM_BASE_URL}
workflow:
_type: react_agent
tool_names: [clock]
llm_name: response_modelSet MODEL_NAME to a model available at the endpoint and NIM_BASE_URL to its API base URL. The NIM provider documents NVIDIA_API_KEY for access credentials. The example illustrates wiring; react_agent requires the nvidia-nat[langchain] plugin, which you must install in the serving environment alongside the function implementation.
Let configuration schemas express dependencies
Toolkit configuration objects derive from Pydantic models. A function’s configuration inherits from FunctionBaseConfig; the configuration schema defines its fields, their types, and any defaults. A field without a default must be supplied. Use nat validate --config_file CONFIG_PATH to check the configuration settings, components, and parameters; replace CONFIG_PATH with the file you intend to run. YAML parsing alone does not perform that toolkit check.
For custom components, declare references using the corresponding component-reference type. FunctionRef names a configured function; LLMRef names an LLM. The builder uses typed references to discover dependencies and initialize components in dependency order. Other documented reference types cover embedders, retrievers, and memory.
A plain string that happens to contain another component’s name does not communicate the same typed dependency. When a custom workflow fails during construction, inspect the configuration object’s reference types as well as the YAML spelling. The component author owns that schema; the deployment owner supplies the instance values.
Functions are the common callable abstraction for tools and agents. They support schema-based input and output validation, and can expose single output, streaming output, or both. Their invocation interfaces are ainvoke() and astream(). Choosing an agent as the workflow entry point therefore does not create a separate configuration universe: an agent can also be a function used by another agent.
Separate deployment values from behavior
Environment interpolation uses braces: ${VAR} reads a variable and produces an empty string when it is unset; ${VAR:-default} supplies a default. Bare $VAR is unsupported. An omitted credential or endpoint can consequently become an empty value rather than the intended deployment setting. Populate required deployment variables before running nat validate --config_file CONFIG_PATH; configuration validation does not by itself demonstrate that the selected endpoint is reachable.
Use base to inherit a configuration and override selected values in a variant. This supports a shared workflow definition with environment-specific model settings. Review both the base and overrides when explaining the deployed behavior: an override file alone is an incomplete description.
Discover components and compare overrides
Run nat info components in the intended environment before relying on an implementation. Its output identifies package and version, component_type, and component_name, the value you use for _type. The description column documents configuration parameters and defaults. If a type is absent, inspect the installed plugin rather than repeatedly changing the YAML spelling. See 1.8.1 for model-gated settings when selecting parameters.
Use discovery and validation together: discovery tells you which registered components and settings are available locally; nat validate --config_file CONFIG_PATH checks the assembled configuration against the toolkit’s requirements. Neither a component listing nor syntactically valid YAML substitutes for validating the file you plan to serve. Keep the component package versions with the reviewed configuration so another environment can reproduce the same discovery result.
A deployment can also change a value at launch. nat run and nat serve accept --override KEY_PATH VALUE, where KEY_PATH uses dot notation. For example, --override llms.response_model.base_url ENDPOINT_URL changes the illustrated client’s endpoint; replace ENDPOINT_URL with the approved API base URL. This makes a command-line override another part of the effective deployment configuration.
Choose base plus a variant file when reviewers need to compare environment differences as a file. Choose a launch override when the deployment system records and reviews the command arguments. In either case, preserve the actual values supplied: validating a file and then applying an unreviewed endpoint override changes what was accepted. Before serving, validate the deployment variant and inspect any additional launch overrides explicitly.
Key distinctions and trade-offs
The three configuration roles answer different operational questions:
| Role | Deciding question | Mechanism | Cost or risk |
|---|---|---|---|
| Workflow | Which entry point coordinates this request? | workflow._type and its references | A topology change can alter calls and latency |
| Function | Which reusable operation is available? | Named functions instance and registered _type | Each invoked operation adds its own work and failure path |
| LLM | Which model client handles generation? | Named llms instance, provider _type, model_name | Model and generation settings affect token cost and response behavior |
Instance reuse reduces duplicated configuration. Separate instances make different endpoints or budgets explicit. Choose based on the behavior you need to vary, and avoid duplicating an entire workflow merely to change one model setting. Conversely, two differently named model instances with identical settings do not establish capacity isolation by themselves.
Architecture / decision scenario
A manufacturing employee assistant has two factory deployments. Factory A permits its approved inference endpoint; factory B requires a different on-premises endpoint. Both need the same workflow and tool implementations, and release review requires the deployment diff to contain at most three changed leaf settings in a checked-in file. The factory differences are exactly two settings: endpoint and model.
One proposal copies the whole YAML file for each factory; another supplies both settings through nat serve --override arguments. The latter cannot satisfy the requirement for a checked-in configuration diff unless those launch arguments become a separately reviewed artifact. The platform owner instead keeps shared functions and workflow definitions in a base file and supplies deployment-specific llms overrides through base. The workflow’s llm_name remains the same instance name, while endpoint and model values differ explicitly.
Another proposal changes only model_name, leaving base_url pointed at factory A. Review rejects it because model selection does not satisfy the location constraint. Before acceptance, the deployment owner supplies the required environment values. The component owner uses nat info components to inspect registered types and settings, then runs nat validate --config_file FACTORY_CONFIG_PATH on each factory variant, replacing FACTORY_CONFIG_PATH with that variant’s path. The deployment owner exercises the selected endpoint before admitting traffic. This preserves a small review surface without hiding the three separate configuration decisions.
Common exam traps
- Assuming every declared function is automatically exposed to every agent.
- Substituting a YAML parser or component listing for
nat validate --config_file. - Using
$VARinstead of${VAR}or overlooking an unset variable’s empty value.
What to remember
Read configuration from the workflow entry point through named function and LLM references. _type selects an implementation; instance names connect components. Typed references, nat info components, and nat validate --config_file make configuration review concrete; preserve deployment values and launch overrides alongside the file.
Knowledge check
A staging configuration for NeMo Agent Toolkit sets base_url: ${NIM_BASE_URL} on its llms entry. Some launch pipelines do not export NIM_BASE_URL. When the variable is set, its value must still be used; when it is unset, the client must fall back to the approved staging endpoint, written here as STAGING_URL. Which change meets both requirements?
$NIM_BASE_URL${NIM_BASE_URL:-STAGING_URL}${NIM_BASE_URL} and rely on an unset variable failing the run--override llms.response_model.base_url STAGING_URL at every launch${VAR:-default} reads the variable when it is set and supplies the default when it is not. Plain ${VAR} becomes an empty string when the variable is unset, so the client gets an empty endpoint rather than the staging one; bare $VAR is unsupported; and a launch override replaces the value even when the variable is set.A team will serve factory-b.yml, a variant that inherits shared definitions through base. In the serving environment, a YAML linter accepts the file, nat info components lists every _type it uses, and the required environment variables are populated. Release review asks for evidence that the assembled configuration meets the toolkit’s own requirements for components, settings and parameters. Which check provides that evidence?
_type against the component_name column of the component listingnat validate --config_file on the shared base filenat validate --config_file on factory-b.ymlnat validate checks the assembled configuration’s components, settings and parameters against the toolkit, and it must run on the file that will actually be served. A component listing shows only what is registered locally, YAML parsing does not perform the toolkit check, and validating the base file alone omits the variant’s overrides.Two regional deployments of an assistant share the same workflow and tool implementations and differ only in their model endpoint and model name. Release review requires the shared workflow and tool definitions to live in one file that both regions use, each region’s difference to appear as a small diff in a checked-in configuration file, and both regions to use their own endpoint. Which approach meets these requirements?
llms in a regional variantnat serve --override argumentsmodel_name per region while both regions keep one shared base_urlbase keeps functions and workflow in one place and records only the changed llms values in a checked-in file. Launch overrides are real configuration but live in command arguments, not in the reviewed file; a full copy duplicates the shared definitions in every region’s file; and changing only the model leaves both regions on one endpoint.A custom workflow’s configuration class declares a field summarizer: str that holds the instance name of another configured function. The YAML spells that instance name exactly, but the builder does not treat the field as a dependency to initialize first. Which change lets the builder discover the dependency?
_typeworkflow section in the fileFunctionRef in the configuration classFunctionRef field holds the same string, but it tells the builder that the value names another function, so the builder makes sure that function is set up before it is used. A plain string carries no such meaning, whatever its value or default, and _type names an implementation rather than a configured instance.References
- NVIDIA, Workflow Configuration
- NVIDIA, Functions
- NVIDIA, LLMs
- NVIDIA, Command Line Interface
- NVIDIA, Configure the ReAct Agent