NVIDIANVIDIA-Certified Professional: Agentic AI2026-107.3 Optimize workflows with the NVIDIA NeMo Agent Toolkit.
Bring framework agents under toolkit configuration
Completed by the knowledge check
Learning objective
Integrate agents from other frameworks into the toolkit.
Core idea
Integrating an existing agent has several depths. You can execute its graph through a wrapper, replace its hardcoded component construction with toolkit lookups, or expose its callable interface as a registered toolkit function. Choose the smallest change that provides the control your deployment requires. For an agent running as a separate service, use the toolkit’s remote-agent a2a_client integration over A2A (see 1.3.2 and 1.3.3) instead of an in-process wrapper.
NeMo Agent Toolkit documents framework integrations with different capabilities. Framework support is not a promise that every provider, retriever, state representation, and tool interface is interchangeable. A successful top-level response proves execution; it does not prove that YAML controls an embedded model or that every internal operation is visible in a trace.
How it works
Wrap a compatible LangGraph graph
The langgraph_wrapper workflow type loads an existing graph. Install its documented package, nvidia-nat-langchain, in the execution environment. Its graph setting identifies the graph as module_path:variable_name; dependencies supplies directories added to the Python path before loading, and env supplies environment variables before graph initialization.
This short configuration illustrates the boundary:
workflow:
_type: langgraph_wrapper
dependencies: [AGENT_PACKAGE_DIR]
graph: AGENT_MODULE_PATH:agent
env: .envReplace AGENT_PACKAGE_DIR with the agent package directory and AGENT_MODULE_PATH with the module path that exports agent. The graph value must resolve to a CompiledStateGraph instance or a callable returning one when invoked with a RunnableConfig. The documentation warns that other graph types may not be supported.
The wrapper accepts simple agents with hardcoded model configurations without code changes. That is useful when the first requirement is to run an established implementation under toolkit evaluation and serving. It also defines the limit: adding an llms section does not, by itself, replace a model the graph constructs internally.
If graph loading fails, check the exported object, import paths, and required environment values before changing prompts. dependencies adds paths; it does not express a replacement for installing the packages your agent imports. The environment that ran the original graph and the one running the wrapper must both be accounted for.
Make component construction configurable
When you need to change a model through YAML, modify the graph’s construction code to obtain the client from the toolkit builder. NVIDIA’s LangGraph example uses SyncBuilder.current().get_llm("agent", wrapper_type=LLMFrameworkEnum.LANGCHAIN). Here, agent is the name under llms, and LANGCHAIN requests the framework-compatible client.
A graph with a hardcoded model constructs it internally, while modified construction code obtains the client from the toolkit builder.
The same page demonstrates get_tools(..., wrapper_type=LLMFrameworkEnum.LANGCHAIN) for tools and get_embedder(...) for embeddings. Each replacement moves a particular component under toolkit configuration. Replacing the model lookup while leaving a tool hardcoded gives you model configurability, not complete graph configurability.
See 7.3.1 for instance wiring. The integration-specific responsibility is locating construction sites inside the foreign framework and selecting the correct wrapper type. The agent owner preserves graph behavior; the platform owner controls the registered component instances. Review changes to both together when a deployment switches providers.
Expose an agent as a reusable function
For an agent without this graph-loading path, use the toolkit’s function abstraction to expose the operation you need. Define a configuration derived from FunctionBaseConfig, register its builder with @register_function(config_type=...), and yield FunctionInfo.from_fn(...) around the callable. This is the documented custom-function mechanism, applied to an agent entry point.
The adapter must define the input and output it exposes. An agent returning a framework-specific message collection needs an intentional conversion if its caller expects a single typed result. Toolkit functions can offer single and streaming output separately; the existence of one mode does not establish that the other has an implementation.
A coarse adapter is a useful first integration because it limits changes to the existing agent. Finer integration exposes individual tools and model construction when those operations must be configured or measured independently. The adapter owner should keep framework-specific message and result conversion here, rather than making every caller understand the foreign agent’s internal representation.
Verify capability and instrumentation separately
The framework capability matrix distinguishes LLM, embedder, retriever, tool-calling, and profiling support. For example, its LangChain row supports all five dimensions; LlamaIndex supports embedding integration but not the retriever-provider dimension. Agno and Semantic Kernel have limited LLM-provider support. Inspect the required dimension before choosing a framework integration for a deployment.
The nvidia-nat[langchain] extra supplies the nvidia-nat-langchain plugin named in the LangGraph prerequisites; these are alternative installation forms for that integration. Install the matching integration extra rather than assuming the core package supplies every framework: documented examples include nvidia-nat[langchain], nvidia-nat[crewai], and nvidia-nat[llama-index]. A framework’s native retriever can still exist inside its agent; absence of a toolkit retriever integration is a narrower statement than absence of retrieval in that framework.
For custom registered functions, framework_wrappers on @register_function declares the frameworks used inside the workflow. The profiler documentation recommends setting it explicitly; otherwise the toolkit inspects code to infer frameworks. Check the resulting model and tool events before accepting cost attribution. See 3.5.2 for interpreting those profiles and 7.3.3 for promoting a measured workflow to serving.
Key distinctions and trade-offs
Choose the integration depth by the control you need:
| Integration path | Deciding condition | Mechanism | Cost or limitation |
|---|---|---|---|
| Graph wrapper | Preserve an existing compatible LangGraph graph | langgraph_wrapper, graph, dependencies, env | Hardcoded components remain hardcoded |
| Configurable graph | Switch selected embedded components through YAML | SyncBuilder.current().get_llm() and framework wrapper type | Requires changes at component construction sites |
| Callable adapter | Reuse another agent through a toolkit function | @register_function, FunctionInfo.from_fn() | You own schema, message, and streaming conversion |
None of these choices makes complex state portable automatically. NVIDIA warns that complex LangGraph state patterns may require configuration or code changes. Test the actual interaction pattern, including subsequent turns, instead of accepting a one-turn example as proof of state compatibility.
Architecture / decision scenario
An insurance research team has a tested LangGraph assistant and ten working days to add toolkit evaluation. Its four-turn case review must retain the same graph behavior, while a second processing region requires a different approved model endpoint.
The tempting proposal is to wrap the graph and add two YAML model configurations, expecting both deployments to switch automatically. The agent constructs its model internally, so the platform owner rejects that assumption. The team first uses langgraph_wrapper to preserve execution, then replaces the model construction with SyncBuilder.current().get_llm() using LLMFrameworkEnum.LANGCHAIN.
The agent owner tests all four turns and the actual state shape, while the platform owner checks that changing the named LLM configuration changes the invoked client. Rewriting the graph as a toolkit-native agent would consume the migration window without being required by either constraint. A later adapter for a separate specialist agent uses a registered function with an explicit result schema, keeping its message representation local to that adapter.
Common exam traps
- Assuming
langgraph_wrapperchanges hardcoded clients because anllmssection exists. - Treating a Python import path as proof that dependencies are installed.
- Equating framework support with identical provider and retriever capabilities.
- Passing arbitrary graph types where the wrapper expects a
CompiledStateGraph. - Accepting a single response as proof of multi-turn state and trace compatibility.
What to remember
Choose execution wrapping, component lookup, or a callable adapter according to the control required. Preserve the existing framework’s behavior deliberately, verify its supported integration dimensions, and inspect both result schemas and internal traces before treating the agent as an operable toolkit component.
Knowledge check
A tested LangGraph assistant runs under NeMo Agent Toolkit through langgraph_wrapper. Its graph constructs its chat model internally with a fixed model name and endpoint written in the code. A second region needs a different model endpoint, selected through YAML, and the team must keep the graph’s behavior with the smallest code change. What should the team do?
llms entry for the new regionenv setting at a per-region file of model variablesget_llm lookupllms entriesllms declares. Obtaining the client through SyncBuilder.current().get_llm() with the LangChain wrapper type moves that one component under YAML control; environment variables only matter if the code reads them, and a full rewrite exceeds what the requirement needs.A workflow loads an existing graph through langgraph_wrapper. Loading fails with ModuleNotFoundError: No module named 'langchain_openai'. The workflow’s dependencies already lists the agent’s package directory, and the graph ran correctly in the agent team’s own Python environment. What should the platform owner do first?
dependencies listenv fileCompiledStateGraphdependencies adds directories to the Python path so the agent’s own modules can be found; it does not install the third-party packages those modules import. The missing module is such a package, so the environment running the wrapper must have it installed, just as the agent team’s environment did. Environment variables and the graph’s export form do not supply a missing package.An existing LlamaIndex agent retrieves documents with LlamaIndex’s own native retrievers, which the team wants to keep unchanged. The team needs NeMo Agent Toolkit to configure the agent’s LLM provider and to profile its calls; nobody needs to configure retrieval through the toolkit. The framework capability matrix lists LlamaIndex with LLM-provider and profiling support but no retriever-provider support. Which plan meets the requirements with the least change?
A fraud-scoring agent built by another team runs as a separately deployed service and exposes the A2A protocol. Your NeMo Agent Toolkit workflow must call it, and you cannot change its code or run it inside your process. Which integration fits?
langgraph_wrappera2a_clienta2a_client is the toolkit integration for a remote A2A agent. Loading the graph, running the entry point locally, or changing its model construction requires access to the agent’s implementation that this deployment rules out.References
- NVIDIA, Running Existing LangGraph Agents in NVIDIA NeMo Agent Toolkit
- NVIDIA, Framework Integrations
- NVIDIA, Writing Custom Functions
- NVIDIA, Profiling and Performance Monitoring of NVIDIA NeMo Agent Toolkit Workflows
- NVIDIA, NVIDIA NeMo Agent Toolkit Workflow as an A2A Client
- NVIDIA, NeMo Agent Toolkit package configuration, v1.8.0