A permitting agent's create_permit tool occasionally gets called twice for the same request after a network retry, and each call currently creates a brand-new permit record, producing duplicates. How should the tool be designed to make retries safe?
Select an answer to reveal the explanation.
Short Explanation
An order number keeps the kitchen from cooking your meal twice when the waiter walks back to confirm. An idempotency key is that order number for create_permit.
Full Explanation
Any tool with a create side effect will eventually be called more than once for the same intent, because retries happen at layers the agent does not control—network stacks, proxies, client libraries. Safety therefore has to be a property of the operation itself rather than a promise about how often it is invoked.
An idempotency key supplied with the request lets the permitting backend recognize a second call carrying the same key as a repeat of the original request and return the existing permit record instead of creating another. The operation becomes safe to retry by construction, so a network blip costs a duplicate response rather than a duplicate permit.
Instructing the agent never to retry is advisory text aimed at the wrong layer, since the duplicate calls originate below the agent and often without its knowledge; creating a new record every time and reconciling overnight leaves incorrect permits live in a system applicants and staff read from all day; stripping retry logic entirely trades duplicates for lost work, turning every transient failure into a permanent one.
Exam caveat: idempotency keys matter for state-changing operations—a read-only lookup is naturally safe to repeat—and the key must be derived from the request's intent rather than generated fresh on each attempt, or every retry looks new. Operational check: send the same create_permit call twice under one key and confirm exactly one record exists and both responses reference it.