Make Agent Actions Safe to Retry: Key, Dedupe, and Log Every Side Effect

A support agent receives a webhook, creates a ticket, then the delivery repeats. The customer sees duplicate tickets. The agent may also send duplicate emails or update the same record again. The problem is duplicate execution.

Agents consuming events from message queues or webhook infrastructure operate under at-least-once delivery semantics, so the same event can arrive again. Do not suppress webhook retries.

An agent that sends emails, updates records, or calls payment APIs can duplicate a real-world side effect when idempotency fails. Keep retries. Make each side effect safe to repeat.

Retry-safe handlers key, dedupe, and log

Idempotency means the same event produces the same committed result, not another action. The operator needs a stable event identity that survives retries, redeliveries, and manual replays.

Assign the idempotency key before execution. Take it from the source event, not the agent. A source event ID can anchor it. The key must be stable across retries.

Check the key against a dedupe store before running the action. If the key already has a committed result, return that result. Do not create another ticket, send another email, or update the record again.

Write the committed result to a side-effect log before returning success. Record the key, action, target, and result. If the process crashes after the external action but before the log, the next retry must be able to detect the committed result.

In an ack-then-process pattern, retries are safe when the acknowledgment is idempotent. The agent can acknowledge receipt, then process the event from a queue. The acknowledgment must not create another action.

Timeouts and observability keep retries safe

A three-operation webhook handler can run with a durable queue, backoff retries, an idempotency key, event-level observability, and a sensible timeout. For a support agent that creates tickets, sends emails, or updates records, the checklist below is the minimum set.

• Assign a stable key to each event before execution.
• Check that key against a dedupe store before running the action.
• Write the committed result to a side-effect log before returning success.
• Make the acknowledgment safe to repeat.
• Set a timeout that matches the slowest safe operation.
• Trace each event from receipt to committed result.

The key stops duplicate actions at the source. The dedupe check stops repeated execution. The log gives the next retry a committed result to compare against. Without it, the agent cannot tell whether the action committed.

A slow handler can trigger another delivery. Hookdeck sets a default webhook delivery timeout of 60 seconds, and a destination can be configured to allow up to 15 minutes. Pick the timeout from the slowest safe operation, not the fastest happy path.

Observability should show the event ID, key, dedupe result, and committed result. If a retry happens, the operator should see whether it was skipped, replayed, or failed. That visibility lets the operator find the duplicate before the customer does.

Event-driven delivery is faster but not retry-safe

Event-driven agent architectures can cut system latency by 70% to 90% relative to polling-based equivalents and use no compute while idle. A polling agent that checks every 5 minutes wastes more than 99% of its resource use when changes are infrequent. The efficiency gain does not remove duplicate delivery.

Event-driven delivery does not change the safety rule. If the agent can create tickets, send emails, or update records, treat every external write as a side effect that may repeat.

Send the same event again. The repeated delivery should not create another ticket, send another email, or update the record. If it does, the handler is not safe to retry.