A procurement agent calls an external supplier API tool that occasionally returns partial JSON (missing required fields), HTTP 200 with an error object in the body, or numeric fields encoded as strings. The agent has begun treating these payloads as successful quotes and recommending invalid purchase orders. What is the most direct remediation within the tool ecosystem design?
Select an answer to reveal the explanation.
Short Explanation
If your tool returns garbage-shaped “success,” your agent will cheerfully reason over garbage. The fix is validation at the tool boundary: schema required fields, type coercion checks, and business-rule quality gates before anything enters the agent’s working context.
Full Explanation
Implementing tool result validation and quality checks that verify schema completeness, business rules, and typed fields before results are accepted into agent reasoning is the direct fix. Agents should not trust raw tool outputs blindly; incomplete JSON, application-level errors under HTTP 200, and type mismatches must be detected and handled (retry, fallback, or escalate) before influencing recommendations. Raising max_tokens for longer justifications is wrong because it affects generation length, not input integrity. Removing the supplier tool and inventing quotes from training knowledge is wrong because it undermines grounding and procurement controls. Switching only the orchestrator display language is wrong because localization does not validate payloads. Exam focus: treat tool outputs as untrusted until validated—schema, types, and domain rules.