Your agent did not get worse in production. It just stopped being the only writer.
A test run is single-writer by construction. The agent reads state, plans, acts, and nothing else touches that data in between. Production inverts that: an agent run is a long, uncommitted transaction spanning seconds or minutes, while every other service, operator and user keeps writing.
The mechanics are old and boring. The agent reads an order at step one and builds its plan on that snapshot. By step seven it is executing against a world that moved: the order was cancelled, a human already refunded the payment from the admin panel, the price changed, or a retry from an earlier step has quietly done the thing once already. Nothing in the trace looks broken. Every tool call returned success. The sequence was invalid.
What I carry over from payments: I do not let a writer act on state it read earlier without proving that state still holds. Pass the version or status you observed into the call, and let the tool reject it when reality has changed. The precondition belongs next to the write, not in the model's reasoning. Keep tools narrow for the same reason. And derive idempotency keys from the task, not from the attempt, so a retried step cannot double-apply.
Evals will not surface any of this. Concurrency is not an output-quality problem.
So I would go looking for the write in your agent loop that is still unconditional...