Idempotent operation

An operation whose repeated application with the same intended input has the same relevant effect as applying it once.

An idempotent operation produces the same end result no matter how many times it runs, so a retry causes no extra harm. The action either takes effect once or recognizes it already ran and does nothing more. Picture an agent updating a to-do item's status to "done." If the network drops and the agent retries, marking it done again leaves the item exactly as it was, so the repeat is safe. Contrast that with an agent that adds a new "done" note each time: three retries leave three duplicate notes. Designing the action so the answer settles on one stable state is what makes a retry harmless.

Builder example

Agents retry constantly because networks fail, services time out, and runs resume after a crash. If your steps are idempotent, a retry just lands on the same result and you can recover freely. If they are not, a single retried step can charge a customer twice, send a duplicate email, or post the same record again. Tell the agent to write actions that set a final state or check for an existing result before creating a new one, so repeats settle instead of stacking up.

Common confusion: Idempotence concerns the defined effect, not identical responses or zero side effects. A read can update access counters, and repeated setting can emit notifications unless those effects are also deduplicated.