NVIDIANVIDIA-Certified Professional: Agentic AI2026-1010.4 Enable human oversight and intervention for accountability and trust.
Match approval to action consequences
Completed by the knowledge check
Learning objective
Gate actions behind human approval based on impact and reversibility.
Core idea
An approval decision authorizes a particular consequence. Decide whether review is necessary from the affected people, resources, and recovery options, rather than from how confident the model sounds. A highly confident agent can still propose an irreversible disclosure.
See 9.4.3 for safe outcomes when detectors fail or reviewers are unavailable, and 10.1.1 for interaction controls. Here you decide which business actions require approval and what that approval covers. The key artifact is an action policy that relates an operation’s scope and reversibility to its required reviewer and permitted outcome.
Impact and reversibility are independent. A reversible update to thousands of employee records can be high impact. A low-cost message sent outside the organization can be impossible to retract. Approval belongs before the consequence, even if the workflow has already spent tokens preparing it.
How it works
Classify the proposed operation
Define the action policy over concrete operations: read a record, prepare a draft, change an internal record, publish information, or transfer value. For each operation, record affected scope, maximum acceptable loss, sensitivity of disclosed data, and the recovery procedure.
A useful reversibility test asks whether the organization can restore the relevant business outcome within its permitted time and cost. Deleting a newly created internal ticket might be straightforward. Deleting an email from the sender’s mailbox does not recover information already delivered to a recipient. A compensating transaction can repair some business effects without restoring the exact original state; Microsoft’s pattern documentation explicitly makes compensation application-specific.
The policy must also classify aggregate impact. Individually permitted changes can exceed a batch’s authorized scope. A tool that updates 2,000 records needs a batch-level limit even if each individual edit looks harmless. Require the executor to compare the proposed batch with the reviewed batch before it begins.
Put approval in the effectful tool
NVIDIA’s Jira HITL example configures create_jira_tickets_tool with hitl_approval_fn. The function resolves that reference through builder.get_function, invokes the approval function through acall_invoke(), and returns without creating tickets when confirmation is false or raises an exception. The config sets hitl_approval_fn: "hitl_approval_tool" and _type: hitl_approval_tool; that function uses HumanPromptText(timeout=60, error="Approval window has expired.") and returns True only when the lowercased reply contains a whole-word yes or y match. Use a structured decision and authenticated authorization checks for production rather than treating free-text matching as an authorization protocol. The important property is placement: the function that performs the external write waits for confirmation first.
The toolkit’s interactive mechanism obtains Context.get().user_interaction_manager and awaits prompt_user_input(...). Its returned response supplies the human input. Use that mechanism to obtain a decision, then enforce your action policy in the write path. An agent instruction to ask permission is weaker than a tool implementation that refuses to write without it.
For a production adaptation, make the proposed target, arguments, affected count, expected consequence, and recovery option visible to the reviewer. Store a proposal revision alongside the decision. Immediately before executing, compare the submitted action with that revision; an edited amount, destination, or batch invalidates the prior approval. The example does not compare revisions; add that check in your write path.
The write path therefore holds two checks before the external write: the approval function’s confirmation, then a comparison with the stored proposal revision.
Select a policy mechanism for argument-sensitive review
In a Python LangChain agent, HumanInTheLoopMiddleware configures review through interrupt_on. Its allowed_decisions can restrict an action to approve and reject. A when predicate receives a ToolCallRequest and can decide from its arguments whether review is necessary; this conditional facility requires langchain>=1.3.3.
Keep that predicate deterministic for the same call. The documentation warns that it runs again on resume: if it changes to false, the call executes and the reviewer’s answer, even a rejection, is ignored. Do not make the same proposal change classification merely because a live exchange rate or mutable external record changed during review. Capture the classification inputs with the proposal, and re-propose when they become stale.
LangChain’s middleware requires checkpointing. This is a framework-specific implementation option, not a configuration key you can paste into an arbitrary NeMo Agent Toolkit workflow.
Key distinctions and trade-offs
Choose the review class from both consequence and recovery:
| Action class | Deciding condition | Implementation choice | Cost |
|---|---|---|---|
| Bounded preparation | No external effect and access is authorized | Run the read or draft operation within tool permissions | Compute and token use |
| Limited reversible write | Small authorized scope and tested recovery | Permit under explicit policy or require one reviewer | Recovery work or review delay |
| Broad reversible write | Recovery exists, but disruption exceeds policy | Review the exact batch before the write tool executes | Reviewer capacity and delayed completion |
| Irreversible disclosure or commitment | Recovery cannot undo the material consequence | Require an authorized decision before execution, or refuse | Human latency and potentially lost automation benefit |
An approval policy is not a model confidence threshold. Confidence can help prioritize review, but it does not change who receives money or whether a recipient can retain confidential content. Similarly, technical permission to call an API does not establish business approval for its particular arguments.
Architecture / decision scenario
A wholesale distributor’s procurement assistant prepares 240 supplier-order changes each hour. The buyer team can review 30 proposals an hour. The application policy permits automatic internal draft edits, requires a buyer for reversible quantity changes above $500, and requires a procurement manager for a nonrefundable commitment above $5,000.
Of the 240 proposals, 216 only change drafts, 20 alter submitted quantities above $500, and four commit more than $5,000 without a refund option. A proposal to approve every operation overwhelms the team by eight times its capacity. A proposal to approve only low-confidence generations misses a confidently generated nonrefundable order.
The procurement owner selects consequence-based review: 24 proposals enter review, while 216 remain bounded preparation. The write tool enforces the buyer or manager requirement and checks the proposal revision. Set the approval window longer than the case’s queue wait plus decision time; copying the example’s 60-second window can expire approvals into refusals even when 24 arrivals an hour fit within capacity of 30 reviews an hour. If a manager reduces a commitment from $8,000 to $6,000, the application treats the edited proposal as the decision’s target and revalidates its policy class before execution. It never applies approval for one supplier to another supplier’s order.
The engineering owner tests a direct invocation of the write tool, a changed proposal after approval, and repeated submission of a reviewed batch. The acceptance criterion is absence of unauthorized effects, not merely the appearance of an approval prompt.
Common exam traps
- Treating a reversible operation as low impact regardless of the affected population.
- Approving the workflow’s goal while allowing its targets or arguments to change afterward.
- Placing confirmation after the write because the final response still needs review.
- Letting a mutable
whenpredicate bypass a rejection on resume. - Assuming human approval substitutes for downstream access permissions.
Where the exam guide differs
The study guide’s suggested readings use “NVIDIA Agent Intelligence Toolkit.” The product documentation calls it NeMo Agent Toolkit. For an exam item about approval placement, choose the effectful tool before its write, as in NVIDIA’s hitl_approval_fn example, rather than relying on an instruction to the agent.
What to remember
Classify impact and reversibility separately. Review the operation before it creates its consequence, bind the decision to the reviewed proposal, and enforce it in the effectful path. Reviewer capacity determines which policy can operate under load; it does not justify silently weakening approval requirements.
Knowledge check
An HR agent proposes changing the cost-center field on 3,000 employee records, and a tested nightly snapshot can restore them within an hour. The agent reports 0.97 confidence. Policy permits automatic execution of reversible writes that affect at most 50 records. Which handling fits the policy?
A NeMo Agent Toolkit agent creates Jira tickets through a tool. No ticket may be created without a human’s confirmation, even when the agent skips asking or the tool is invoked directly. Which design meets that requirement?
create_jira_tickets_tool a hitl_approval_fn that it invokes first, returning without creating tickets when confirmation is not received. An instruction to the agent is weaker than a tool that refuses to write, and confirming or filtering the answer happens after the tickets exist.A procurement manager approves a proposal to order $8,000 of stock from supplier A. Before the write tool executes, the agent revises the proposal’s delivery warehouse and lowers the quantity. What should the write path do?
A payment tool in a Python LangChain agent uses HumanInTheLoopMiddleware with a when predicate that converts the amount at the live exchange rate and requests review above €10,000. A reviewer rejects a payment; when the agent resumes, the rate has moved, the predicate returns False, and the payment executes. Which fix prevents this?
allowed_decisions to approve and rejectwhen read the captured valueFalse the tool runs and the reviewer’s answer — even a rejection — is ignored. The predicate must return the same result for the same call, so its classification inputs are captured with the proposal and the proposal is re-proposed when they become stale. Restricting decisions or persisting checkpoints leaves the changing predicate in place, and a lower threshold only narrows the rate moves that flip its result.A team adapts NVIDIA’s Jira approval example, keeping its timeout=60. Reviewers have capacity for every proposal, but a proposal typically waits eight minutes in the queue, so approvals expire into refusals. The review policy and staffing must stay as they are. Which prompt configuration change accommodates the queue delay?
References
- NVIDIA, Interactive Workflows Guide
- NVIDIA, Jira ticket creation tool
- NVIDIA, HITL approval function
- NVIDIA, Jira HITL configuration
- LangChain, Human-in-the-loop
- Microsoft, Compensating Transaction pattern
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide