A treasury payment-processing tool can fail three ways: a network timeout, a validation error on the payer's account number, and an authorization failure because the calling agent lacks permission. Architecturally, how should the agent's response differ across these three?
Select an answer to reveal the explanation.
Short Explanation
A dropped call, a wrong number, and a locked door need three different responses: redial, ask again, or find someone with a key. Only the dropped call deserves a retry.
Full Explanation
Failure handling should be driven by what would have to change for the call to succeed. For a treasury payment tool, a network timeout, a bad payer account number, and an insufficient-permission rejection differ on exactly that question, so any uniform response policy will be wrong for at least two of the three.
The timeout is transient—nothing about the request is wrong, so an automatic retry is likely to succeed and needs no human. The validation error requires different input, so the agent should fail fast and request a corrected account number rather than resending a value already rejected. The authorization failure requires different credentials, which the agent cannot grant itself, making escalation to a human with the right access the only path forward.
Retrying all three a fixed number of times spends calls on two failures retrying can never resolve while delaying the correct action for both; escalating everything to a human immediately gives away the automation value on precisely the case agents handle best; returning a generic apology in every case discards the diagnosis, leaving the resident and any downstream logic unable to resolve anything.
Exam caveat: this branch exists only if the tool reports which category applies—without a trustworthy error category the agent is back to uniform guessing. Operational check: inject each of the three failures in staging and confirm the agent retries once, prompts for corrected input once, and escalates once, with no crossover between them.