NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.5 Orchestrate multi-agent workflows and coordination.
Choose who directs specialist agents
Completed by the knowledge check
Learning objective
Compare multi-agent topologies: supervisor, hierarchical, peer-to-peer, and agent-as-tool.
Core idea
A multi-agent topology describes who chooses the next specialist and who owns the final response. For an architect, the useful question is where control returns after a specialist finishes. A supervisor receives results and decides again; a peer handoff transfers control; a hierarchy delegates through multiple management levels.
Agent-as-tool is an invocation relationship, not a mutually exclusive topology. A supervisor can call specialists as tools, and a specialist can itself supervise another group. Count the control decisions and context transfers rather than treating every named role as a separate architecture.
LangChain’s multi-agent documentation lists subagents, handoffs, skills, routers, and custom workflows. Skills keep one agent in control while loading knowledge on demand, so they are an alternative to a multi-agent topology. NVIDIA NeMo Agent Toolkit implements composable agents as functions. These mechanisms let you build the topology; the topology names alone do not specify an executable workflow.
How it works
Centralize decisions with a supervisor
In LangChain’s subagents pattern, the main agent chooses a subagent, supplies its input, receives its result, and combines results for the user. A subagent normally returns to the main agent rather than speaking directly to the user. Its isolated invocation context keeps specialist work from filling the main conversation with every intermediate message.
NVIDIA’s ReAct documentation illustrates this composition with workflow._type: react_agent and tool_names containing math_agent alongside ordinary tools. Its function example defines functions.math_agent with _type: react_agent, tool_names: [calculator], and a description of its purpose. The parent selects a specialist through its tool interface, while the specialist selects from its own narrower tool set. llm_name selects a configured model.
The supervisor therefore controls delegation through the same tool-selection mechanism used for ordinary functions. Separate agent roles do not imply separate services, separate GPUs, or different models. Deployment and inference capacity are independent choices.
Add hierarchy only for another decision scope
A hierarchy repeats the supervisor relationship: a top-level coordinator calls a domain supervisor, which calls its own specialists. NeMo Agent Toolkit implements agents as a special type of function that can orchestrate other functions, supporting this nesting. Each level should decide something that the parent cannot decide economically from its own context.
For example, a domain supervisor might choose among several document-analysis specialists while returning one compact result to the top level. That hides domain detail, but adds another routing decision and result-compression boundary. If the middle level only relays the same request to one fixed child, a direct function reference removes work without removing a useful decision.
A remote specialist exposed through an a2a_client function group is still agent-as-tool from the caller’s side; A2A transport alone does not make the topology peer-to-peer (see 1.3.2). A NeMo Agent Toolkit supervisor using that group must be a per-user workflow, such as per_user_react_agent or one registered with @register_per_user_function; shared react_agent workflows cannot use A2A client function groups directly.
Transfer control between peers
Peer-to-peer coordination lets an active specialist choose another specialist without returning every decision to one central supervisor. LangChain’s handoffs pattern routes by a state field such as active_agent; see 1.5.2 for the transfer itself.
This is useful when the user should continue with the specialist that owns the conversation. It also creates a routing problem: each allowed recipient must be explicit, and the graph must define when work ends. A free-form message saying “ask another expert” does not establish an executable handoff. See 1.5.2 for the state and message requirements at that transition. A supervisor receives each result and decides again, while a peer handoff transfers control to another specialist.
Distinguish NVIDIA’s router agent from a supervisor
NeMo Agent Toolkit’s _type: router_agent takes branches and llm_name, chooses one branch, and returns that branch’s result. Its documentation explicitly limits it to one branch per request, without multi-step routing, branch combination, or inter-branch communication. It is appropriate for classification followed by one execution path, rather than iterative coordination among several specialists. LangChain’s Router pattern can instead direct input to several agents and synthesize their results, so “router” alone does not mean single-branch.
The router and ReAct implementations described here require the nvidia-nat[langchain] plugin. A configuration naming them must have that integration available. See 1.2.2 for ReAct loop controls and 1.6.2 for routing design; this lesson decides where those components sit among agents.
Key distinctions and trade-offs
Choose by the control relationship, rather than by how many agent names appear in a diagram:
| Option | Deciding condition | Mechanism | Main cost |
|---|---|---|---|
| Supervisor | One component must reconcile several specialist results | Main agent invokes subagent tools; NVIDIA example uses react_agent.tool_names | Central routing and synthesis add model work |
| Hierarchical | Domain groups need their own internal delegation | An agent under functions calls further agent functions | More control levels and summaries can lose detail |
| Peer-to-peer | The active specialist should transfer the interaction | LangGraph Command(goto=..., update=..., graph=Command.PARENT) | Distributed routing and termination become harder to inspect |
| Agent-as-tool | A caller needs a bounded specialist result and retains control | Specialist function exposed through tool_names; LangChain tool wraps a subagent invocation | Input and output selection can omit needed context |
Supervisor and agent-as-tool often describe the same system at different levels. Hierarchical and peer designs can also contain ordinary tool calls. Decide separately whether the workflow needs multiple specialists at all; 1.5.3 owns that comparison.
Context isolation improves focus, but the caller must send enough information for the specialist to work. Returning only a final text response reduces transcript growth while risking loss of qualifications or unresolved issues. LangChain’s subagents documentation recommends controlling both inputs and outputs; it notes that a supervisor sees only the output returned through the tool wrapper.
Architecture / decision scenario
An insurance company builds an internal claim-analysis assistant. The case owner needs coverage analysis, repair-cost analysis, and one reconciled response. In the team’s hypothetical benchmark, a flat supervisor meets the 12-second response budget in 10 seconds. A proposed two-level hierarchy takes 14 seconds, and the team has only three specialists maintained by one engineering group.
Choose the flat supervisor with specialists exposed as tools. The application architect owns reconciliation; each specialist receives the relevant claim facts and returns its assessment to the supervisor. The functions entries and the supervisor’s tool_names make this delegation explicit. Agent-as-tool describes those calls, while supervisor describes who owns the overall decision.
Reject hierarchy until a domain group has enough internal choices to justify another control level. Reject unrestricted peer handoffs because the assistant must reconcile all three analyses rather than leave the conversation with whichever specialist answered last. A peer design remains a reasonable alternative for a separate interactive consultation where one specialist should take over.
NeMo Agent Toolkit’s router_agent is also tempting because it is simpler. Its one-branch execution cannot collect all three required analyses. The constraint rules it out even if its routing latency is lower. Keep this topology choice separate from whether the three assessments run concurrently; concurrency and failure handling belong to 1.5.2.
Common exam traps
- Treating supervisor and agent-as-tool as mutually exclusive answers when the former uses the latter.
- Equating multiple agents with multiple processes, models, or GPU allocations.
- Choosing NeMo Agent Toolkit’s single-branch
router_agentfor a request that requires several specialist results. - Calling nested delegation peer-to-peer when each child returns to its parent.
- Giving every specialist the entire transcript and assuming isolation still reduces context cost.
What to remember
Locate the next-step decision and the final-response owner. Use a supervisor for central reconciliation, hierarchy for meaningful nested decisions, peer handoffs for transferred control, and agent-as-tool for caller-controlled delegation. Verify the configured mechanism: a named specialist is useful only when the workflow can invoke it and consume its result.
Knowledge check
A claims team builds a NeMo Agent Toolkit workflow for requests that need a coverage assessment, a repair-cost assessment, and a fraud screen, combined into one reconciled answer by a single coordinating component. Which configuration meets this requirement with the fewest control levels?
router_agent whose branches name the three specialist functionsreact_agent whose tool_names name the three specialist functionsA platform team adds an a2a_client function group for a remote compliance agent to a multi-user NeMo Agent Toolkit workflow whose workflow._type is react_agent. The supervisor should call the remote agent as one of its tools. What must change?
router_agent ’s branchesper_user_react_agentper_user_react_agent or one registered with @register_per_user_function ; a shared react_agent cannot use the group directly. The A2A transport does not change the topology: called through a function, the remote agent is still agent-as-tool, so a peer handoff or an extra level solves a problem the team does not have.In a document-analysis workflow, the top-level agent calls a contracts_supervisor agent, which always passes the same request to its only child, a clause-extraction specialist, and returns that child’s answer unchanged. Profiling shows the middle level adds one model call per request. What should the architect do?
A supervisor delegates a coverage check to a subagent wrapped as a tool and must remain the component that approves or rejects the claim. The subagent finds a policy exclusion while reasoning, but its final message says only “Coverage confirmed”, and the supervisor approves the claim. Which change addresses the cause?
References
- NVIDIA, Agents
- NVIDIA, A2A Client
- NVIDIA, Configure the ReAct Agent
- NVIDIA, Configure the Router Agent
- LangChain, Multi-agent
- LangChain, Subagents
- LangChain, Handoffs