An agent that manages GitHub repository settings is designed to run on a schedule. Due to an infrastructure issue, the agent's execution is interrupted midway and it restarts automatically, re-running all steps from the beginning. Which design principle MOST effectively prevents the agent from creating duplicate issues, posting duplicate comments, or applying conflicting settings changes on the re-run?

Idempotency is the property that executing an operation multiple times produces the same result as executing it once. In agent systems that perform write operations on shared state, such as GitHub repositories, issue trackers, and settings, idempotency is fundamental to correctness. The global-lock approach prevents concurrent duplicate execution but does not help with sequential re-runs. If the agent crashes, the lock may need manual clearing before the agent can restart. Distributed locks also introduce their own failure modes, such as the lock holder crashing before release and lock timeout issues. Locks prevent concurrent problems; they do not make individual operations safe to re-run. The read-before-write idempotent design is correct because it checks current state before writing: before creating an issue, it checks whether an identical issue already exists and skips creation if it does; before posting a comment, it checks whether the comment was already posted; before changing a repository setting, it reads the current value and skips the write if it already matches the desired value. This pattern makes each operation intrinsically safe to re-run, regardless of whether the re-run is caused by crashes, retries, tests, or duplicate triggers. The idempotency key lives in the operation's own logic, making it independent of external coordination systems. The checkpoint-system approach is valid but more complex and less robust than idempotency. Checkpoints require reliable storage for the progress state, correct implementation of resume logic, and handling of partial-completion edge cases. If the checkpoint system fails, the agent falls back to a non-idempotent re-run. Idempotent operations do not depend on checkpoint correctness. The exactly-once message-queue approach moves the problem to infrastructure. Truly exactly-once delivery in distributed systems is extremely difficult to guarantee and often means at-most-once or at-least-once with deduplication. Even with exactly-once delivery, the downstream GitHub API call may still be retried due to timeouts, making the deduplication problem resurface. Idempotency at the operation level is more robust than exactly-once delivery guarantees.