How can an environment evaluate routing when another worker changes the case?

A simulated environment can attach a `record_version` to each request. The agent reads CASE-1158 at version 4 and proposes an assignment. Before it writes, a scheduled event assigns the case through another worker and advances the version to 5.

The `assign_request` action can require `expected_version`. A write using version 4 returns a conflict response and leaves the current owner intact. The agent must retrieve the latest record and decide whether further action is required under the supplied policy.

Evaluation hooks can capture the stale write, subsequent read and final disposition. Useful failure conditions include repeated writes without refreshing, overwriting the new assignment through an unrestricted action, or claiming success after a rejected update. A conflict itself is an environment event, not automatically an agent failure.

Reset should restore the starting snapshot, event schedule and action history. Replaying the same interleaving lets teams compare recovery behaviour across agents. If tool retries are permitted, idempotency keys can prevent duplicate assignment events and distinguish safe retry handling from repeated creation of work.