NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.3 Configure agent-to-agent communication protocols for collaboration.
Delegate work through discoverable agent cards
Completed by the knowledge check
Learning objective
Configure A2A agent cards, discovery, task delegation, and result exchange.
Core idea
A2A discovery tells a client what an agent offers and how to reach it. Delegation then creates an interaction with its own message and task identifiers. Result exchange must preserve that identity through progress, clarification, and output consumption. Finding a card and receiving an HTTP success response do not establish that the delegated work has completed.
See 1.3.1 for choosing A2A rather than MCP. Here the architectural decision is how much of the task lifecycle the calling application must retain instead of flattening every interaction into one string.
How it works
Publish an endpoint clients can actually use
A2A’s well-known discovery path is /.well-known/agent-card.json; the specification also permits registries and direct configuration. In A2A v1.0.0, an AgentCard contains name, description, version, supportedInterfaces, capabilities, defaultInputModes, defaultOutputModes, and skills. version describes the agent, while interface declarations identify protocol support. Do not treat an agent release number as its protocol revision.
The ordered supportedInterfaces list expresses preference. A client selects an interface it supports rather than assuming that a URL alone establishes a compatible transport. capabilities.streaming and capabilities.pushNotifications describe optional delivery mechanisms. Skills help the client select an agent; media types tell it whether the requested input and desired output fit that agent.
NeMo Agent Toolkit publishes a workflow through general.front_end with _type: a2a. The server documentation says the entire workflow becomes one agent, functions become skills, and the Agent Card is generated from the workflow configuration. name, description, and version provide the public agent metadata.
When an ingress address differs from the bind address, set public_base_url to the externally reachable address. Binding to 0.0.0.0 does not give clients a usable advertised destination. An internal hostname in a generated card can let discovery succeed while subsequent invocation fails. Correct the advertised URL rather than increasing the task timeout.
Connect discovery to the calling workflow
On the client, configure a function_groups entry with _type: a2a_client, url, and, if necessary, agent_card_path. The documented default path is /.well-known/agent-card.json. include_skills_in_description controls whether discovered skills enter the function description; the documented default is true. That description can help selection, but more descriptive text also increases the material presented to the calling model.
A configuration fragment for an existing workflow is:
function_groups:
research_agent:
_type: a2a_client
url: https://agents.example.com/research
agent_card_path: /.well-known/agent-card.json
include_skills_in_description: true
task_timeout: 60The URL is illustrative; replace it with the deployed agent’s address. The NVIDIA integration requires nvidia-nat[a2a] and a per-user workflow, such as per_user_react_agent, that selects the function group through tool_names. Inspect the installed configuration schema with nat info components -t function_group -q a2a_client before applying a configuration copied from another release.
The high-level research_agent.call(query) returns a string and fits simple natural-language delegation. Helpers include get_skills(), get_info(), get_task(), and cancel_task(). Use low-level send_message() or send_message_streaming() when the application must retain task/context identifiers or interpret individual events. A convenient string interface is a choice about what the caller consumes, not a replacement for the underlying task model.
Preserve identity through results and interruptions
In A2A v1.0.0, a Message has messageId, role, and parts, with optional taskId and contextId. The message creator supplies messageId. A returned Task.id identifies delegated work; contextId groups related tasks and messages. To supply missing input for an existing task, preserve its taskId. Starting an unrelated message does not necessarily resume that task.
SendMessageConfiguration.returnImmediately: true requests an early task response; its default is false, which waits for a terminal or interrupted state. An early response transfers responsibility for observing completion to the client through GetTask, subscription, or configured push delivery. In a JSON-RPC v1.0 exchange, the method names include SendMessage and GetTask.
A TaskStatusUpdateEvent reports status; a TaskArtifactUpdateEvent carries output updates. An Artifact has an artifactId and parts, whose content can be text, structured data, a url, or raw bytes. In v1.0 a part contains exactly one content variant. Use the output media type and the consumer’s validation rules when deciding whether the artifact is usable.
A2A distinguishes task outputs from conversational messages. The specification recommends artifacts for task results and warns that transient messages need not be persisted in task history. If a stream disconnects, retrieve task state with GetTask instead of assuming every status message can be replayed. Preserve artifacts as outputs; do not reconstruct the final deliverable by concatenating progress text.
One delegation therefore runs from the card, through a returned Task and its update events, to GetTask after the stream disconnects.
Key distinctions and trade-offs
Discovery versus delegation: A card advertises the interface. A message initiates or continues an interaction. Neither skill discovery nor advertised streaming implies that work has started.
Context versus task: A context groups interactions. A task identifies one unit of work. Two tasks in one context can have different outcomes, and a context identifier is not authorization to read either task.
Direct reply versus tracked work: A direct Message is suitable for an interaction that needs no task tracking. A Task supports status and output retrieval. TASK_STATE_INPUT_REQUIRED is interrupted work requiring input, whereas TASK_STATE_COMPLETED is successful terminal work.
Polling adds repeated reads but simplifies a client that cannot maintain a stream. Streaming reduces the wait for visible updates but requires event handling and reconnection logic. A card’s capabilities and the deployed client’s transport support constrain the choice; protocol specification support is not proof of NVIDIA integration support.
Architecture / decision scenario
An insurer’s employee research assistant delegates policy comparisons to a specialist agent owned by another team. Research takes 45 seconds at the measured 95th percentile; the UI must acknowledge requests within 3 seconds and accept a user reconnect after 2 minutes. The output is a structured comparison, not a sequence of chat updates.
A tempting implementation uses only the high-level string call and keeps the HTTP request open. That misses the acknowledgement target and gives the reconnecting UI no task identifier. The application team uses the documented send_message_streaming() interface. For task-backed work, the stream begins with a Task; the caller records its Task.id and acknowledges that task to the UI without waiting for the comparison. After a reconnect, it retrieves state through get_task(task_id). The team verifies that the first task event arrives within the 3-second target; streaming itself provides no latency guarantee. It consumes the comparison from artifacts and treats missing-policy clarification as interrupted work.
The specialist team sets public_base_url to its ingress address and checks that card media types match the comparison output. Before rollout, both teams verify the actual protocol version and transport together. The NeMo Agent Toolkit 1.8 client page does not document a returnImmediately or push-delivery option. A team requiring either needs a client that documents it or an appropriate SDK call outside the function group, with version compatibility verified.
Common exam traps
- Publishing a bind address as the client-facing endpoint.
- Confusing the agent’s
versionwith the A2A protocol version. - Replacing
taskIdwithcontextIdwhen continuing interrupted work. - Treating a successful send or stream close as successful task completion.
- Using transient status messages as the only copy of a final deliverable.
Where the exam guide differs
The study guide’s “agent-to-agent communication protocols” predates A2A v1.0.0: v0.3.0 was released when the guide was written. A2A v1.0.0, released March 12, 2026, uses property-based content variants instead of inline kind discriminators and exposes supportedInterfaces for interface selection. This lesson teaches that specification separately from NVIDIA’s integration examples (NeMo Agent Toolkit 1.8), which show a card with a top-level url. The 1.8 client page lists explicit transport selection and gRPC/HTTP-REST support under “Coming Soon”; its documented transport is JSON-RPC over HTTP. Match an exam item’s revision and the deployed integration; do not splice v0.3 payloads into v1.0 requests.
What to remember
Publish reachable metadata, discover a compatible interface, and preserve task identity from submission through final artifacts. Choose the high-level string call only when it preserves everything the consumer needs. Progress, interrupted work, and completed outputs require different handling.
Knowledge check
Your client delegated a claim review to a remote agent over A2A v1.0.0. The returned task is now in TASK_STATE_INPUT_REQUIRED, asking for the policy number. How should the client supply it so that the agent resumes that work?
taskId and contextIdcontextIdmessageId and no other identifiersmessageId unchangedtaskId continues that task; including its matching contextId preserves the context explicitly. A context only groups related tasks and messages, so a message that names the context alone — or nothing at all — need not resume this task, and replaying the original request does not supply the missing policy number.In a NeMo Agent Toolkit 1.8 workflow, your UI must acknowledge each delegated research request within 3 seconds and let the user reconnect after 2 minutes to see the result. Research takes about 45 seconds, and the remote agent runs each request as a task. Which a2a_client interface gives the application what both requirements need?
call(query) , with task_timeout set above 45 secondscall(query) , with the HTTP request held open for the UIget_info() , polled until the agent reports completionsend_message_streaming() , recording the first event’s Task.idcall(query) returns a string only when the work ends, so the UI has nothing to acknowledge and no task identifier to reconnect with. For task-backed work the stream begins with a Task , so the client can acknowledge it, record Task.id , and later retrieve state with get_task(task_id) ; the team still verifies that the first event arrives within 3 seconds, because streaming promises no latency. get_info() describes the agent, not a task.A NeMo Agent Toolkit A2A server runs in Kubernetes and binds to 0.0.0.0; clients reach it through an ingress at https://agents.example.com/claims. Clients fetch the Agent Card successfully, but every SendMessage then fails because the card advertises an internal cluster hostname. What fixes the failure?
task_timeout to ten minutespublic_base_url on the server to the ingress addressagent_card_path at the ingress addressversion so that clients discover it againpublic_base_url makes it advertise the reachable one. Discovery already works, so the card path is not the fault; a longer timeout only waits longer for an address clients cannot reach; and version describes the agent release, not its endpoint.A specialist agent produces a structured policy comparison. Your client was consuming the task’s stream and had received several TaskStatusUpdateEvent progress messages when the connection dropped. The client retained the task identifier and must recover the comparison when the task completes. What should it do?
GetTask until completion and read the artifactsTask.id , observes its status, and consumes the artifacts when it completes. Progress text is not the deliverable, and resubmission risks duplicating the work.