Your agent didn't get worse in production. It just stopped being the only thing touching the state it was reasoning about.
In testing it reads a record, plans, acts. Nothing else moves. The world it saw at step one is still true at step four.
Production deletes that assumption. Between the read and the write, a user edits the order, a retry fires, a scheduled job closes the window, an operator cancels. The plan stays perfectly coherent. It is just coherent about a world that has expired.
That is not a model quality problem. It is the oldest write-path problem there is, and payment systems had to solve it long before agents existed: never let an actor apply a decision based on state it no longer holds.
What I carry over from payments and deal-lifecycle work:
An agent action is a state transition with a guard, not a function call. The transition declares the state it expects, and it fails loudly once the record has moved.
Every action is idempotent and keyed, so a retried step cannot double-apply.
Re-read at write time instead of plan time, and treat a changed record as a new decision rather than an error to retry past.
Whatever you cannot guard goes to a human queue instead of a guess.
Fixtures are the reason this stays invisible until launch: removing concurrency is most of what makes a test deterministic. A single-actor test can show you the agent is reasonable. It cannot show you the agent is safe.
I write up more of these production patterns on my blog, if that is useful: https://polycratia.com/c/a82d75f5
Worth knowing where your agent's plan window actually closes: at read, at approval, or at write...