Comparison
IdempotentvsSide effects and idempotency in tools
Idempotent
you can safely run the same operation five times and the system ends up in exactly the state it would after one.
The property that applying an operation repeatedly has the same effect as applying it once. It is what makes retries safe, and retries are unavoidable in any networked system, because a timeout does not tell you whether the work happened. Idempotence is about the effect on state, not about the return value or the work performed.
Full entry →Side effects and idempotency in tools
the model called the same write tool twice, and it only mattered because you had not made the write idempotent.
Design rules carried over from distributed systems: separate read tools from write tools, make writes idempotent where possible, and require confirmation for irreversible actions. Models retry and occasionally repeat themselves; tools must be safe under that behaviour.
Full entry →