A support operations lead deploys an agent that refunds orders via connected billing tools. Low-value refunds can auto-process, but high-value refunds and repeated tool errors need finance review. Which escalation path design based on tool usage best ensures control?
Select an answer to reveal the explanation.
Short Explanation
You've got the right setup when your small refunds sail through and big amounts plus tool hiccups go straight to finance. You're basically running an express checkout for everyday items with threshold-based escalation for anything oversized.
Full Explanation
The correct design balances efficiency and control by auto-processing low-value refunds within policy while escalating both high-value refunds and repeated tool errors to finance, matching the threshold rule and ensuring financial judgment where risk or systemic failure exists. The logging-and-retry approach fails by observability without governance because it records errors for automatic retry and maintains flow yet withholds repeated billing failures from finance review despite potential fraud, double-charging, or integration faults. The manual-approval-for-everything approach fails by over-control because it sends even routine low-value refunds to finance, satisfying oversight but violating the explicit auto-process requirement and creating unsustainable workload. The support-triage approach fails by misrouted accountability because it handles high amounts and repeated failures responsively but assigns financial risk decisions to support staff without approval authority, breaking segregation of duties. An exam caveat is to distinguish handling an exception from escalating to the mandated owner, since plausible workflows log or reroute correctly while missing the required finance queue. A practical check is to test thresholds in staging with high-value cases and injected tool errors to confirm routing, audit trails, and queue assignment trigger finance review.