An agent that passes testing and then breaks in production usually hasn't gotten worse at reasoning. It has started repeating itself.
In a test run every step executes exactly once. State is clean, there is one pass and one actor. Production takes away all three guarantees. A gateway times out and retries. A worker restarts and the queue redelivers the message. The agent itself re-plans after a partial failure and takes the step again, because from where it sits the step never completed.
Repeating a model call costs you nothing. Repeating a tool call that writes is a different story.
And most agent frameworks treat tool calls as function returns: a result, nothing more. There is no notion of an effect that already landed. So the second execution creates a second record, the agent reads state that contradicts its own plan, and corrects it with a third write. The logs read like a reasoning failure. It is a delivery failure.
I handle this the way I handle payment endpoints. Every writing tool gets an idempotency key derived from the intent of the step, not generated at call time, because a random key is new on every replay and protects nothing. The effect goes into a log keyed by that value, and the tool checks the log before acting, returning the previous result instead of acting twice.
That one discipline is what makes an agent safe to re-run, and safe to re-run is what production is asking for.
Agent readiness is a side-effects problem long before it is a prompt problem.
I keep writing up these production-side notes here: https://polycratia.com/c/f4382bc1
If you run agents with real write access, I'd like to know what you key idempotency on: the step intent, the plan node, or the task id...