Missing Idempotency on Agent Calls

Problem

A timeout that retried succeeds twice on the backend even though the client saw one logical operation. Cards get charged twice, emails get sent twice, duplicate tickets appear. The agent has no way to know which calls already committed. Worse: the retried calls often come from a different attempt loop and use different parameters (a regenerated email body), so deduplication after the fact requires fuzzy matching of natural language.

Solution

Generate idempotency keys at the planning layer (hash of plan-step id + arguments) and pass them through the tool wrapper. For backings without native idempotency, maintain a client-side dedupe table keyed by (run id, step id). Treat idempotency as a property of the *plan step* not the call, so regenerated arguments still collapse to the same key.

When to use

• Never. Cite when reviewing tool wrappers for state-mutating APIs.
• Add stable idempotency keys derived from plan-step id, not retry attempt.
• Maintain client-side dedupe table when backing service lacks native idempotency.