When the customs-compliance tool cannot find a matching HS-code record, it currently raises an unhandled exception that crashes the agent's turn. What is the better design?
Select an answer to reveal the explanation.
Short Explanation
A crash tells your ops dashboard something broke; a structured 'not found' tells the agent what to say to the customs broker. Tools should hand the model information it can act on, even when that information is 'nothing matched.'
Full Explanation
A well-designed tool treats 'no result' as a normal outcome, not an exceptional one, and returns it as structured data -- a status field and a message -- so the calling agent can read that outcome and decide what to do next, such as telling the user no matching HS code was found or escalating to a human broker. An unhandled exception instead terminates the agent's reasoning turn outright, which produces a broken user experience and gives the model nothing to reason over. A crash is not a useful signal to the end user, and 'clarity for the operator' does not justify a failed customer-facing turn when a structured response would give the same visibility through logs while keeping the conversation functional. Silent infinite retry on a lookup that has no matching record will never succeed and just burns time and cost without informing the agent. Fabricating a plausible-looking HS code to always have an answer is the worst option: it produces a confident, ungrounded, and potentially compliance-violating response, which is precisely the hallucination risk that tool-calling and grounded retrieval are meant to avoid. Exam framing: tool development includes designing the tool's failure and empty-result paths, not only its success path.