What breaks when an agent receives production write access
The failures are rarely the reasoning. They are idempotency, partial writes, and success that was never achieved.
Retries are not free once writes are involved
A retry on a read is harmless. A retry on a write is a duplicate unless something prevents it. The usual something is an idempotency key computed before the first attempt and honoured by the receiving system — which means the receiving system has to support it, and many internal systems do not.
Where it is not supported, the retry logic has to be replaced with a reconciliation step: check whether the intended change is already present before attempting it again. This is more code and more latency, and it is not optional. A workflow that retries blindly against a system without idempotency will eventually create two of something, usually under exactly the load conditions that make it hardest to notice.
Partial writes and the shape of a rollback
Most useful operations touch more than one record. Updating a qualification decision might mean writing a field, adding a note, and reassigning an owner. If the second call fails, the operation is now in a state that neither the old nor the new logic describes.
The instinct is to wrap it in a transaction, which works when everything lives in one system and does not when it does not. Across systems, the practical answer is to make the sequence resumable and to record intent before acting: write down what the run is about to do, then do it, then mark it done. A run interrupted halfway can then be finished or reversed by something that knows what it was trying to achieve, rather than inferring it from a half-changed record.
The failure that matters most is silent success
The worst outcome is not an error. It is a call that returns success while the change did not take effect — a validation rule that silently dropped a field, a write to a record that had been merged, an update applied to a stale version. The run completes, the evidence says it completed, and the operation is wrong.
This is the argument for reading back what was written as part of the operation rather than trusting the response. It is an extra call and it feels redundant until the first time it catches something. Evidence that a change was requested is much weaker than evidence that a change is present.
It is also why before-and-after values belong in the record. A change you can see is a change you can reverse. A change recorded only as an event is one you have to reconstruct.
Sequence it deliberately
The order that tends to hold: read-only for long enough to establish that the decisions are right; then propose-and-approve, where the system produces the change and a person commits it; then scoped write on the narrow set of fields where the decisions have proven reliable; and only then any widening.
Each step is reversible and each produces the evidence needed to justify the next. Skipping to the end is possible and occasionally works. It just removes every checkpoint that would have told you it was not working.