Idempotent operation

An idempotent operation produces the same end result no matter how many times it runs, so a retry causes no extra harm. Setting a value to five is idempotent; adding five each time is not, because the total keeps growing.

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: Idempotent does not mean the operation runs only once. It means running it again leaves the result unchanged, so a retry is safe even when the same call arrives several times. Reading data is naturally idempotent; creating or incrementing usually is not until you design it that way.