How do you stop an AI agent from sending the same cold email twice?
It sounds like a trivial question, the kind you would expect a sending platform to have solved before you ever thought about it. Then you actually run an autonomous sender against a real list, a worker times out mid-batch, the job retries, and a hundred prospects get the same message twice inside ten minutes. Now it is not trivial. It is a deliverability incident, a support ticket, and a prospect screenshotting your double email to their network with the caption "great, the robots are broken."
Duplicate cold emails are not a copy problem or a targeting problem. They are a reliability problem, and specifically an idempotency problem - the same class of bug that payment APIs and message queues spent a decade learning to defend against. The uncomfortable part is that AI agents make this failure mode more likely, not less, and most of the guidance written for human-operated campaigns does not even name it.
Why agents double-send when humans rarely do
A human running a campaign clicks "send" once. If the UI hangs, they wait, they refresh, they check the sent folder before clicking again. That hesitation is a dedup layer made of nerves. An agent has no nerves. It has a retry policy, and a retry policy fires whenever it does not get the answer it expected.
Here is where duplicate cold emails come from in an autonomous stack:
- Lost responses. The send request reaches the mail server, the email goes out, and then the connection drops before the success response comes back. From the agent's side that looks identical to a total failure, so it retries. The recipient gets two.
- Over-eager retry wrappers. A generic HTTP client configured to retry on any 5xx, or any timeout, wrapped around a call that is not safe to repeat. This is the single most common way a well-meaning integration double-sends at scale.
- Multi-agent overlap. In a multi-agent cold email setup, two agents can both decide the same account is theirs to work. Without a shared claim, they both send. This is the failure the multi-agent post warns about directly: every new agent you add is a new way to double-send.
- Crash-resume replays. A worker processing a batch dies at row 400 of 1,000 and restarts from the last checkpoint. If the checkpoint was written before the sends flushed, rows 380 to 400 go out again.
Notice that only the first two are classic transport retries. The last two are logical duplicates: no single request was retried, but the same person still got the same email from two different decisions. Hold onto that distinction, because it is exactly where the standard fix falls short.
What idempotency actually means
Idempotency is the property that doing an operation twice has the same effect as doing it once. Payment APIs solved this years ago because charging a card twice is unforgivable, and the mechanism they landed on is the idempotency key.
The pattern, straight from Stripe's idempotency documentation, works like this. The client generates a unique key and attaches it to the request. The server saves the status code and body of the first request made for that key, whether it succeeded or failed. Any later request carrying the same key returns that saved result instead of executing again. Stripe suggests a V4 UUID or similar random string, allows keys up to 255 characters, and - the detail people miss - lets you remove keys automatically once they are at least 24 hours old. It also compares the incoming request parameters against the original and errors if they differ, so you cannot quietly reuse a key for a different payload.
Agent-native email platforms have adopted the same primitive. AgentMail's duplicate-send guidance uses an Idempotency-Key header on sends: a retry carrying the same key returns the original message and sends no second email, while a request that reuses a key with a different body gets a 409 Conflict. Their stated reasons for why agents need this are the same three you would guess - network errors, timeouts, and logic bugs.
If your send endpoint does not accept an idempotency key, you do not have retry safety. You have a hope that nothing ever times out, which on a large batch is not a plan.
So the transport problem is a solved problem. Attach a key, retry freely, done. The gap is what "unique key" should mean for cold email specifically.
The gap: random keys solve the wrong half
Every vendor doc tells you to generate a random key per request. That is correct for the problem those docs are written to solve: a single client retrying a single request. The random key makes that one call safe to repeat. It does nothing about the logical duplicates.
Walk it through. Your agent runs the nightly batch, generates a fresh random key for each send, and mails 500 people. The next morning a second agent run - a manual re-trigger, a scheduler that fired twice, a multi-agent peer - decides those same 500 people are due for step two, or worse, re-sends step one because it read a stale status. It generates 500 brand new random keys. Every one of them is unique. The API happily sends all 500 again, because from its point of view these are 500 requests it has never seen. Random per-request keys did their job perfectly and the prospect still got mailed twice.
The fix is to make the key describe the send, not the request. A deterministic key derived from the business identity of the message:
idempotency_key = hash(campaign_id + contact_id + sequence_step)
Now the key is the same no matter which agent, which run, or which retry produced it. The first send for campaign_42 : contact_918 : step_2 writes the key. Every subsequent attempt to send that exact logical message - tonight, tomorrow, from any agent - collides with the stored key and is refused. This is precisely what AgentMail hints at when it recommends generating identifiers deterministically from business logic rather than from random values. Random keys catch the retry. Deterministic keys catch the retry and the replay and the overlapping agent.
There is one caveat worth stating plainly, because it is where teams get burned. Idempotency-key stores are short-lived - a 24-hour window is typical. That window covers a retry storm. It does not cover a five-day sequence. So the deterministic key is your first line, but the durable record of "we have already emailed this person at this step" has to live in your own send log or suppression layer, queried before the send is ever attempted. The API key protects the next few minutes. Your database protects the next few days.
Where the dedup check has to live
You can hash a perfect key and still double-send if the check runs in the wrong place. The rule is the same one that governs every irreversible action in autonomous outbound: the guarantee has to live in the send tool, not in the model's prompt.
A prompt that says "do not email anyone you have already contacted" is a suggestion the model can forget, reason its way around, or simply not have the context to honor - the agent that re-triggers the batch may be a fresh process with no memory of last night's run. A send tool that computes the deterministic key, checks it against the durable send log, and refuses the call on a hit is a control. It holds no matter which agent calls it, which model is driving, or how the prompt was written that day.
This is the same argument behind tool calling for cold email: what protects you is not how the tool is described to the model, it is what the tool enforces below the model. Deduplication belongs in that enforced floor, right next to the suppression check and the volume cap. When send, suppress, and dedup are all tools with their own rules, the number of agents above them stops being a correctness question. A hosted cold email MCP server exists to be exactly that floor: the place where "have we already sent this?" is answered by infrastructure, not by trusting an LLM to remember.
Why this is a deliverability problem, not just an annoyance
It is tempting to file double-sends under "embarrassing but harmless." It is not harmless. Duplicate cold emails drive the two signals mailbox providers punish hardest. They spike spam complaints, because nothing says "spam" to a recipient like the identical message arriving twice. And they inflate your volume unpredictably, which is its own reputation risk.
Google's sender guidelines tell bulk senders to keep spam complaints under 0.3%, and ideally below 0.1%. That is a razor-thin tolerance. As an illustration of how fast duplicates eat it: if just 1 in 500 recipients of a duplicate hits "report spam" out of confusion or irritation, a 5,000-send night lands you at roughly 0.2% complaints - already double the 0.1% target - and unlike a soft copy problem, this one is fully self-inflicted and fully preventable. The duplicate does not just fail to convert. It actively spends the reputation that took months to build.
That is why deduplication sits in the same tier as email verification and suppression. All three are unglamorous pre-send gates that write no copy and book no meetings, and all three quietly protect the one asset - your sending reputation - that you cannot buy back once it is gone.
Key takeaways
- Duplicate cold emails are an idempotency bug, not a copy bug. They come from retries, timeouts, logic errors, multi-agent overlap, and crash-resume replays - failure modes agents hit far more often than humans do.
- An idempotency key makes a retry safe, by storing the first result and returning it for any repeat of the same key. If your send endpoint does not accept one, you have no retry safety.
- Random per-request keys only solve transport retries. For cold email, derive the key deterministically from business identity - campaign, contact, and sequence step - so it also catches logical duplicates from separate runs and overlapping agents.
- Key stores are short-lived, often pruned after 24 hours. Keep the durable "already sent" record in your own send log or suppression layer and query it before every send.
- Enforce the check in the send tool, not the prompt. A model instruction is a suggestion; a send action that refuses on a dedup hit is a control. Put deduplication in the same governed floor as suppression and volume caps - which is exactly what the FoxReach MCP server is built to hold.
