How can tool-based evaluation detect duplicate follow-up after a timeout?

An evaluation environment can simulate a dispatch tool that accepts a follow-up message but times out before returning its receipt. The assistant sees an ambiguous result: the action may have succeeded even though no confirmation arrived.

Expose `send_followup` with a caller-supplied `idempotency_key`, plus `get_action_status` for checking that key. The dispatch log can retain `action_id`, `case_id`, `idempotency_key`, `accepted_at` and `delivery_state`. A retry using the same key should resolve to the existing action according to the tool contract.

The evaluation hook should count actual accepted dispatches, not just successful tool responses. It can also inspect whether the model queried status or reused the original key before attempting recovery. A new key after every timeout can create duplicate contact despite apparently reasonable retry logic.

Reset both the business records and dispatch deduplication state between independent episodes. Within an episode, preserve that state across retries. This gives labs a focused test of operational tool reliability under uncertainty, where the failure is an extra business action rather than an incorrect sentence.