A customer-service multi-agent system can draft refund decisions, but company policy requires that any refund over $500 must be approved by a human supervisor before the refund tool executes. Agents may still gather facts and draft the recommendation autonomously below that threshold. Which implementation best meets the requirement?
Select an answer to reveal the explanation.
Short Explanation
Policy is clear: you can let agents work below the threshold, but refunds over $500 need human approval before the tool runs. You need a human-in-the-loop gate that pauses the workflow, shows the draft for approve/reject/override, and only then executes the refund. Notifying supervisors after money leaves isn't control.
Full Explanation
Correct implementation: insert a human-in-the-loop approval gate that pauses the workflow for refunds over $500, surfaces the draft for supervisor approve/reject/override, and only then invokes the refund tool. Multi-agent orchestration includes human-in-the-loop processes such as approval workflows, overrides, and edge-case handling. Conditional gates based on business thresholds pause autonomous execution until a human decision is recorded, then proceed or cancel the tool call.
Allowing every refund tool call to execute immediately and emailing a summary after the money is sent is wrong because post-facto notification does not prevent unauthorized high-value refunds.
Disabling the refund tool entirely and forcing supervisors to use a separate legacy desktop app with no agent context is wrong because it fails autonomous handling below the threshold and assisted handling above it.
Lowering model temperature so the agent never proposes amounts over $500 is wrong because temperature controls sampling randomness, not policy enforcement of monetary limits.
Exam focus: human-in-the-loop approval is a control before side-effecting tools, conditioned on business rules.