Skip to lesson

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.

A supervisor receives each result and decides again, while a peer handoff transfers controlTwo lanes. In the supervisor lane, the main agent chooses a subagent and the subagent returns its result to the main agent, which decides again. In the peer handoff lane, the active specialist transfers control to another specialist without returning the decision to a central supervisor. Control comes back to the supervisor in the first lane and moves on in the second.Peer handoffSupervisorreturns its resulttransfers controlactive specialistanother specialistmain agentsubagent

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:

OptionDeciding conditionMechanismMain cost
SupervisorOne component must reconcile several specialist resultsMain agent invokes subagent tools; NVIDIA example uses react_agent.tool_namesCentral routing and synthesis add model work
HierarchicalDomain groups need their own internal delegationAn agent under functions calls further agent functionsMore control levels and summaries can lose detail
Peer-to-peerThe active specialist should transfer the interactionLangGraph Command(goto=..., update=..., graph=Command.PARENT)Distributed routing and termination become harder to inspect
Agent-as-toolA caller needs a bounded specialist result and retains controlSpecialist function exposed through tool_names; LangChain tool wraps a subagent invocationInput 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_agent for 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

References