AI Agents & Automation Practical insights
Stop failed API calls from sending campaigns twice
Design campaign recovery around action identifiers, status checks and controlled retries so a timeout does not trigger a second customer message.
A timeout does not prove a campaign failed to send. The receiving service may have accepted the request before the connection broke. An agent that immediately repeats the action can therefore create duplicate messages. Design recovery around the external system’s actual state.
Give the action a stable identity
Assign one identifier to the intended send and retain it across retries. If the service supports idempotency keys, follow its documented behavior and retention period. A new key for every attempt defeats the protection. Keep the campaign, audience version and approval linked to that identifier.
Separate failure from uncertainty
A rejected request, an accepted job and an unknown outcome require different responses. For an unknown outcome, query the job status or reconcile delivery records before acting again. Do not interpret a reassuring model response as confirmation. Tool design should make these states explicit. [1]
Test the awkward moment
In a sandbox, interrupt the response after acceptance. Submit the same approved action twice and inspect the resulting jobs. Also test a partially completed audience. The expected recovery must specify whether the remaining recipients can be identified safely.
Provide a stopping point
After bounded retries, place unresolved sends in a human queue with the action ID and evidence. Measure duplicate sends and unresolved outcomes alongside completion time. A workflow that pauses transparently is easier to recover than one that silently repeats a consequential action.
Sources and evidence
Sources checked on 4 October 2026. Proposed workflows and hypothetical examples are editorial analysis.
From insight to practice