NVIDIANVIDIA-Certified Professional: Agentic AI2026-1010.1 Build intuitive UIs with user-in-the-loop interaction.
Make review controls change execution state
Completed by the knowledge check
Learning objective
Implement pause, approve, edit, reject, and resume controls in agent UIs.
Core idea
A review control is useful only when its result changes what the workflow can execute. Stopping token display does not pause a tool, and recording a thumbs-up does not authorize a pending action. Connect each control to an explicit waiting point and show the state the backend acknowledges.
See 1.1.1 for interaction surfaces and 1.1.2 for progress presentation. Here, the decision is what each button means for one pending proposal. Risk-based approval policy belongs to 10.4.1; interrupt and cancellation semantics belong to 10.4.2.
How it works
Pause at an executable boundary
NeMo Agent Toolkit exposes UserInteractionManager through Context.get().user_interaction_manager. Calling await user_input_manager.prompt_user_input(prompt) pauses workflow execution to wait for input. Workflow code processes the returned response before execution continues. Put this interaction before the tool operation that depends on the answer.
For a user-requested Pause, the application needs a path from the control to a cooperative stopping point. For example, an application-owned pause_requested flag can cause the workflow to request confirmation before its next tool call. The label remains Pause requested until that boundary is reached; then it becomes Paused. That flag is a design choice, not a Toolkit configuration key. It cannot reverse a call already sent to an external system.
Toolkit prompts provide the waiting point; the surrounding function implements the decision. With HumanPromptText, the workflow receives a matching response model and reads response.content.text. Validate the answer before interpreting it as an instruction. A missing answer is not approval.
The execution interface matters: nat serve supports all documented human interaction data models, whereas nat run supports only HumanPromptText. The Toolkit frontend must use WebSocket mode for interactive prompts. A console text example therefore does not prove that a binary-choice form works over every serving interface.
Tie the response to the pending prompt
In the WebSocket schema, system_interaction_message carries the human prompt. Its content.input_type identifies the control: text supports a correction, and binary_choice supports a pair such as Continue/Cancel. Choice options have id, label, and value; the displayed label and the value consumed by workflow code have different jobs.
The client sends the answer as user_interaction_message. The schema includes id, thread_id, parent_id, and conversation_id; parent_id links a message to its originating message. Preserve the interaction identity instead of treating the answer as an unrelated chat turn. Otherwise, a delayed response can be applied to a different proposal that happens to appear in the same conversation.
Over HTTP, POST /executions/{execution_id}/interactions/{interaction_id}/response addresses one pending prompt; the server accepts it with 204 and rejects a second answer with 400. The interaction-required response supplies status_url, interaction_id, prompt, and response_url; see 2.5.3 for the client flow and resolved-interaction handling. This identifies the prompt, so the application still needs a proposal_revision check to identify the reviewed content.
Keep the proposal being reviewed visible: target, proposed arguments, expected effect, and whether an external action has begun. Use an application-owned proposal revision to distinguish edits. For example, proposal_revision: 3 is your service’s field, not a required Toolkit field. Check that revision when accepting the response and return the revised proposal for review when it no longer matches.
Make expiry observable
The WebSocket prompt content supports timeout in seconds and an error message. timeout defaults to null, meaning no timeout. With a configured timeout, the frontend displays a countdown, dismisses the expired prompt, and shows the error. The server also enforces the timeout and raises TimeoutError to the workflow.
Choose the timeout from how long the proposal remains actionable. For an application-selected 90-second review window, show that window and handle TimeoutError as an expired interaction. Keep the dependent action unexecuted and offer a refreshed proposal. Leaving an enabled Approve button on an expired prompt creates a misleading interaction even if the server rejects the response correctly.
Key distinctions and trade-offs
Implement the five controls with distinct transitions:
| Control | Deciding condition | Mechanism | Cost or constraint |
|---|---|---|---|
| Pause | The user needs execution to stop before another action | Application pause request reaches a prompt_user_input boundary | A running external call can finish before the pause is acknowledged |
| Approve | The displayed proposal is acceptable | binary_choice response selects the allowed branch | Approval applies to the reviewed proposal, not future edits |
| Edit | Correctable content or arguments need human changes | text prompt returns revised content for validation and review | Editing adds a review round and can invalidate earlier approval |
| Reject | This proposal must not execute | Response selects a branch that skips the dependent operation | The workflow needs a visible rejected outcome or a revised proposal |
| Resume | A paused workflow has valid input to continue | Workflow processes the correlated response and continues after the wait | Resuming computation does not necessarily authorize an external write |
LangChain’s HumanInTheLoopMiddleware encodes the same three-way decision through interrupt_on and per-tool allowed_decisions: ["approve", "edit", "reject"]; it requires a checkpointer to maintain state across interruptions.
An edited draft can resume into validation while still awaiting approval. A rejected proposal can resume into a safe alternative branch. Avoid a single Continue control whose meaning changes silently between those cases. Define the branch in the function that processes the response, rather than asking the language model to infer whether an ambiguous sentence grants permission.
Architecture / decision scenario
A construction supplier’s employee assistant prepares purchase requests. In this hypothetical deployment, requests below $500 can be drafted automatically, but every submission requires the buyer’s confirmation. The team measures 12 seconds for draft preparation and allows 90 seconds for review before refreshing stock and price data.
A proposed design merely stops the browser’s stream on Pause and sends any later chat message to the model. It is attractive because it needs little UI state. The purchasing product owner rejects it: a submission can continue after the stream disappears, and a correction can be mistaken for consent.
The workflow instead reaches prompt_user_input before submission. A Pause request shows Pause requested until the waiting point is acknowledged. The buyer sees supplier, quantities, and total. Edit opens a text interaction; changing quantity produces a revised draft that must be reviewed again. Approve selects the submission branch for that revision. Reject skips submission and presents the rejected result. Resume after a pause returns to the pending review rather than silently approving it.
If 90 seconds elapse, the frontend dismisses the prompt and the workflow handles TimeoutError without submitting. The application requests fresh stock and price information before presenting another review. The workflow engineer owns these transitions; the UI engineer owns matching labels and pending states. The purchasing owner determines the submission policy rather than embedding it in button text.
Common exam traps
- Treating a hidden stream as a paused workflow.
- Assuming
nat runsupports every interactive prompt model supported bynat serve. - Sending an approval as an unrelated chat turn without preserving its interaction identity.
- Letting an edit retain approval of the previous proposal.
- Equating Resume with permission to perform the next external action.
- Leaving an expired prompt actionable or interpreting timeout as consent.
Where the exam guide differs
The study guide’s suggested readings use “NVIDIA Agent Intelligence Toolkit.” The documented product is NeMo Agent Toolkit, with UserInteractionManager and prompt_user_input implementing interactive waits. The guide names no pause or resume API: for an item about waiting for user input in the Toolkit, identify prompt_user_input as the waiting point and the calling function as the owner of continuation.
What to remember
Make the backend waiting point authoritative. Correlate the answer with the proposal, validate edits before approval, and show acknowledged pause, rejection, expiry, and continuation separately. A control label describes a transition; workflow code must enforce it.
Knowledge check
A purchasing assistant built on NeMo Agent Toolkit streams its progress and then calls a supplier-submission tool. Users press Pause expecting no further supplier action until they have reviewed the order. Today the button only stops the browser’s token stream, and a submission sometimes completes afterwards. Which change makes Pause hold the workflow before its next tool call?
prompt_user_input before the next tool calltimeout to null on the review prompt that precedes the submission toolprompt_user_input before the next tool call, and the UI should show Pause requested until that point is acknowledged. Asking the model to stop leaves permission to inference, and removing a timeout only removes a deadline. Even a correct pause cannot reverse a call already sent.A review service handles answers through Toolkit HTTP Interactive Execution. A buyer opened a pending interaction that showed proposal revision 3; a colleague’s edit has since produced revision 4. The buyer’s Approve now reaches that interaction’s response_url, carrying the application’s proposal_revision: 3. What should the service do?
An assistant presents a supplier order over the Toolkit WebSocket interface with an application-selected timeout of 90 seconds, because stock and prices may change after that. The buyer does not answer, and the server raises TimeoutError to the workflow. What should the workflow do next?
timeout set to nullA developer’s nat run test of a free-text HumanPromptText correction passed. They now add an Approve/Reject review as a binary_choice prompt and want to test it the same way. What should they conclude before relying on that test?
nat runtimeout to run under nat runnat serve rather than nat runnat serve supports every documented human interaction data model, whereas nat run supports only HumanPromptText . A passing console test of a text prompt therefore says nothing about a binary-choice form; test it under nat serve , with the Toolkit frontend in WebSocket mode. A timeout is optional, and a checkpointer belongs to LangGraph rather than to Toolkit prompts.References
- NVIDIA, Interactive Workflows Guide
- NVIDIA, HTTP Interactive Execution
- LangChain, Built-in middleware
- NVIDIA, WebSocket Message Schema
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide