NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.1 Design user interfaces for intuitive human-agent interaction.
Show status, sources, and recoverable errors
Completed by the knowledge check
Learning objective
Surface progress, tool actions, evidence, uncertainty, and recoverable errors without overwhelming users.
Core idea
Show the person what is happening, what the result rests on, and what they can do next. A useful interface summarizes workflow state and exposes supporting detail on demand. Raw payloads make the person reconstruct state themselves.
Build the display from execution events and retrieved sources. Generated narration can explain an operation, but it should not be the record that proves the operation completed. NVIDIA NeMo Agent Toolkit supplies intermediate messages and structured errors; the NVIDIA RAG Blueprint demonstrates numbered citations and a Sources panel.
How it works
Turn events into a compact task state
The toolkit’s WebSocket schema distinguishes system_intermediate_message, system_response_message, and error_message. Workflow messages can carry status values in_progress, completed, or failed. Use those values in your display model instead of treating any arriving text as success.
Preserve association fields: id identifies a message, conversation_id groups the conversation, and parent_id links an update to its originating message. Intermediate-step examples also include intermediate_parent_id, with content.name and content.payload describing the step. Associate updates with their originating request so concurrent runs cannot interleave into a false sequence.
Translate that record into concise labels such as “Searching runbooks” and “Draft ready.” Avoid an invented percentage when the workflow has no bounded total: three completed tools do not establish 75% completion if the agent can choose more tools.
A system_response_message can carry a response token with status: "in_progress", as the reference example shows. Keep partial output distinguishable from completed answers.
Show tool outcomes rather than raw deliberation
Use a step’s content.name as an input to an application-maintained display label, and interpret content.payload through the corresponding tool adapter. For a lookup, show that records were retrieved. For a write, show completion only after the tool’s result establishes it. The agent’s proposed action and the tool’s observed outcome belong to different moments.
The toolkit’s full streaming transaction returns raw IntermediateStep objects without step-adaptor translations at /v1/workflow/full (experimental versioned path) or /generate/full (legacy). The documented filter_steps=LLM_END,TOOL_END selects model-end and tool-end events; filter_steps=none suppresses intermediate steps. Update a write-action card from the TOOL_END result, checking whether the operation succeeded. Select display-safe payload fields separately: a type filter is not redaction.
The supplied UI exposes NEXT_PUBLIC_NAT_ENABLE_INTERMEDIATE_STEPS to show reasoning steps by default and NEXT_PUBLIC_NAT_SHOW_DATA_STREAM_DEFAULT_ON for the data stream display. Show concise summaries and keep raw diagnostics in a separate view. The UI README separately labels Live Data Streaming experimental; do not generalize that status to every streaming endpoint.
Attach evidence to the answer
The RAG Blueprint UI displays numbered citations when citations are enabled. Its Sources panel expands to show a document name, a relevance score, and a preview of the text or image. Keep the answer readable and its basis inspectable.
Preserve the association between the returned citation and its source preview when adapting that pattern. A list of documents consulted somewhere during execution does not show which material supports a particular statement. For an access-reset answer, let the person inspect the runbook beside the claim about who can authorize it.
The UI setting Confidence Score Threshold ranges from 0.0 to 1.0 and sets minimum document relevance; higher values are more selective. Despite its name, this retrieval cutoff does not measure answer correctness. A relevant document can omit the requested fact, and the agent can misread it.
Make uncertainty specific
The RAG Blueprint implements an upstream Response Groundedness Check with ENABLE_REFLECTION=true. A reflection LLM scores the answer from 0 (not grounded) through 1 (partially grounded) to 2 (well-grounded). Below RESPONSE_GROUNDEDNESS_THRESHOLD (default 1), it regenerates while iterations remain; MAX_REFLECTION_LOOP defaults to 3 refinement attempts.
Each iteration adds latency, and response streaming is unsupported during response groundedness checks. Use workflow status to explain the wait rather than promising answer tokens during that check. Keep the internal score separate from a user-facing confidence badge.
Show specific limitations with the document name and preview: “The cited runbook covers employees; this request concerns a contractor.” The retrieval team owns source availability, the workflow team owns groundedness checking, and the product team owns the limitation message. Measuring how often answers are unsupported belongs to 3.1.1.
Give recoverable errors a next action
The WebSocket error_message has structured content.code, content.message, and content.details. Documented codes include invalid_user_message_content, user_auth_error, and workflow_error. Dispatch the error adapter by message type: authentication failures also arrive as auth_response_message with status: "error" and payload.code: "user_auth_error". The error_message example itself carries status: "in_progress"; status alone cannot identify failure. Preserve diagnostic detail for the operator.
An invalid_user_message_content outcome needs an input correction before resubmission. A user_auth_error needs the authentication path repaired. A workflow_error alone does not establish that retry is safe: the workflow owner must determine what failed and whether a side effect already happened. See 2.4.1 for failure classification and 2.4.2 for retry limits. Expose only the recovery action the backend permits.
Each of the three documented codes needs a different response, and an authentication failure can arrive as either message type.
A disconnected stream does not prove tool failure. For an async run submitted with a caller-supplied job_id, resubmit the same ID: the server returns the existing job’s status instead of submitting another job. See 1.1.1 for the async endpoint. Preserve that ID across reconnection; this mechanism does not make unrelated writes idempotent.
Key distinctions and trade-offs
Progress describes execution state; evidence supports an answer; uncertainty describes a limitation in what can be concluded. None substitutes for another. A busy progress indicator does not make an uncited result credible, and many citations do not prove that a tool write succeeded.
More detail costs user attention and client rendering work. Use a compact status and answer as the default view, with expandable steps and sources for inspection. Engineers can consume raw intermediate objects in a diagnostic view without making every customer read them. Choose the event adapter and display policy together.
Architecture / decision scenario
An IT service-desk employee assistant performs six tool steps, retrieves 20 runbook excerpts, and submits access-reset requests. Its service manager requires readable status within two seconds and a completed tool result before displaying “Request submitted.”
Streaming every payload into one transcript buries the answer beneath 20 excerpts and can imply success before the write completes. Instead, the frontend owner groups step events by parent_id, shows concise status, and updates the request card from TOOL_END. The backend supplies display-safe payloads. With reflection enabled, the two-second target applies to status; the groundedness check delays answer text and does not support response streaming.
Numbered citations expand into Sources. If the runbook covers employees but the request concerns a contractor, the result names that limitation and requests the appropriate source. Invalid input gets a correction action; auth_response_message failure gets the authentication path. After a dropped async connection, the client resubmits the preserved job_id for status. The employee gets progress, action outcomes, evidence, uncertainty, and recovery without reading an execution log.
Common exam traps
- Equating streamed text with workflow completion.
- Presenting a planned tool call as a completed business operation.
- Treating
filter_stepsas redaction of sensitive payload fields. - Calling a relevance score or Confidence Score Threshold calibrated answer confidence.
- Expecting response streaming during reflection groundedness checks.
- Treating every
workflow_erroror disconnected stream as safely retryable. - Assuming a display toggle changes the backend’s authorization or data exposure.
What to remember
Derive status from execution messages and tool results, associate updates with their request, and keep supporting detail expandable. Show sources for claims, identify specific uncertainty, and offer only the recovery action justified by the underlying outcome.
Knowledge check
An IT service-desk assistant built on the NeMo Agent Toolkit submits access-reset requests through a write tool. The service manager requires that the card “Request submitted” appear only once the reset request has actually been submitted. Which event should change the card?
TOOL_END step for the reset tool, once its result shows that the write succeededsystem_response_message whose text mentions the submitted requestTOOL_END event has to be checked for success. Narration about the reset, a response token marked in_progress , or a stream that simply ends can all appear without the write having succeeded.A customer-facing status view reads /v1/workflow/full so that people can see which tools have finished. Tool payloads include employees’ personal phone numbers, which must never reach the customer’s browser. The team proposes requesting filter_steps=TOOL_END. What should the design be?
filter_steps=TOOL_END and render each event’s payload in the status viewfilter_steps=LLM_END,TOOL_END and collapse every payload behind an expandable details panelNEXT_PUBLIC_NAT_ENABLE_INTERMEDIATE_STEPS and show the steps only on requestfilter_steps=TOOL_END and have the backend pass on only display-safe payload fieldsfilter_steps selects which step types are streamed; it is not redaction, so a TOOL_END payload still carries whatever the tool returned. The backend has to select display-safe fields before anything reaches the client. Collapsing a panel or switching off a UI display default changes what the person sees first, not what data the browser receives.A product manager plans to show a “High confidence” badge whenever the RAG Blueprint UI’s Confidence Score Threshold is set to 0.8 and documents are returned. What does passing that threshold actually tell the reader?
The service-desk assistant receives an error_message whose content.code is workflow_error, after the agent had already invoked the access-reset write tool. The backend has not yet reported whether the reset took effect. Which recovery should the interface offer the employee?
workflow_error alone does not establish that retrying is safe: the workflow owner has to determine what failed and whether the write already took effect, and the interface exposes only the recovery the backend permits. An input correction answers invalid_user_message_content , and an authentication repair answers user_auth_error ; neither fits this code.The RAG Blueprint’s response groundedness check is enabled. It takes several seconds, but the service manager requires readable progress within two seconds while retaining that check. What should the interface show during the wait?