Meridian Line is adding a tool that can actually amend a customs declaration in the source system, not just read one. What should the engineer add before wiring this tool into the compliance agent's toolbox?
Select an answer to reveal the explanation.
Short Explanation
Reading a record and changing one are not the same risk category -- a wrong read gives a wrong answer, a wrong write changes a real customs filing. Anything that takes an action needs a human or a policy gate in front of it, not just a good tool description.
Full Explanation
Tools that take actions with real-world side effects -- amending a filing, sending a message, moving money -- need a stronger safety posture than read-only retrieval tools, because a hallucinated or misjudged call produces a real consequence rather than a wrong sentence in an answer. The standard mitigation is a confirmation or human-approval gate before the write executes, so a person or a policy check reviews the action before it takes effect, which is a guardrail concern layered on top of good tool design rather than a substitute for it. Treating a write tool as no riskier than a read tool ignores exactly this asymmetry and is the error the question is testing. A code comment is documentation for developers; it has no effect on runtime behavior and does not protect the customs record from an incorrect automated change. A blind retry loop on a write action is actively dangerous -- retrying an amendment that partially succeeded, or one whose failure the agent misdiagnosed, risks applying the change twice or applying a wrong change repeatedly. Exam framing: implementing guardrails and defining tools for multi-stage reasoning both cover distinguishing read from write actions and gating the higher-risk ones.