How can generated tool contracts prevent duplicate contact during retries?

A `send_reminder` contract can accept `case_id`, `obligation_id`, `recipient_endpoint_id`, `template_id`, `expected_version` and `idempotency_key`. The environment checks the current obligation state and contact permission before accepting the action.

The accepted operation should atomically create the outbound message, append a contact event and update the case's last-contact reference. If these writes happen independently, the agent may see a sent message without the corresponding policy history and mistakenly send another reminder.

Define retry behaviour explicitly. Reusing an idempotency key with the same payload should return the original outcome. Reusing it with a different payload should produce a conflict. A rejected precondition should return a structured reason that tells the agent whether it needs to refresh state or choose another action.

MirrorFirm could generate action schemas and test episodes containing interrupted responses or repeated calls. A reset must clear episode-specific idempotency records alongside messages and case state. Evaluation can then distinguish a safe retry from a second business action, rather than counting every tool invocation as a separate contact.