The email timed out. Did it send?

The agent sends a customer update. The connection times out before it receives a response, so it sends again. The customer receives both messages and asks which one is current. The second send repaired nothing and created a second customer action.

Gmail's draft guide explains that sending a draft removes the draft and creates a new sent message. Recovery has to inspect what happened to the message, since a missing response does not mean no send occurred.

A separate n8n Community thread reports repeated processing of the same incoming email. The cause there is at the trigger level, and the requirement is the same: identify the intended customer action independently of how many times the workflow starts.

Give uncertain outcomes their own state#

A delivery workflow needs at least four outcomes: prepared, confirmed sent, confirmed failed, and outcome unknown. Collapsing "unknown" into "failed" encourages blind retries, and collapsing it into "sent" leaves the customer waiting if the message never left.

Before the send, keep enough information to identify the business action:

• the intended conversation
• recipients
• approved content
• preparation time
• the provider identifiers you have

A subject line is not unique, since a renewal reminder can carry the same subject every month.

Take an agent sending the approved next steps for a customer launch. It loses the response at 3:02, then looks for the corresponding sent message in the authorized mailbox and inspects the target conversation. If it finds a matching sent message, it records that result and stops. If it cannot resolve the uncertainty, it brings the precise unknown state to the responsible person.

Make the retry decision explicit#

A retry policy should distinguish transient read failures from externally visible writes. Retrying a mailbox search differs from retrying a send, and a generic "retry three times" setting erases that distinction.

If the provider offers a deduplication mechanism for the operation, use it as documented. A custom header or local task identifier guarantees nothing on the remote side and only helps the agent recognize its own attempts.

Watch for two workers doing the same job#

A duplicate can occur without a timeout: a scheduled reminder and a manual request can both tell agents to contact the same customer. Establish one business action per reminder period and account, and let the second request inspect the first one's state before creating another proposal.

Define "same" carefully. A corrected attachment sent with a clear explanation is a new action. A retry of the identical approved message is an attempt at the old action.

When a duplicate has already gone out, record which messages reached which recipients. The account owner decides whether a correction is needed. An agent should not reflexively send an apology that adds a third interruption.

Verify recovery with a controlled failure#

Test with mailboxes your team controls:

1. Interrupt the connection after the send request begins and check how the workflow reports uncertainty.
2. Repeat with an explicit provider rejection.
3. Send two nearly simultaneous requests for the same reminder.
4. Send an unrelated message with an identical subject.

Inspect the recipient inbox as well as the agent's logs. A clean internal success message cannot prove that only one email arrived.

When reconciliation cannot settle the outcome, decide who authorizes a fresh send. Give that person the attempted time, recipients, message preview, and searches already performed to decide whether the cost of a possible duplicate is acceptable. Record the result as a new decision under uncertainty, since the system did not prove the first attempt failed.

Your team can keep its existing agent and use Deixic's activity history to inspect routed actions and results. Use approvals when a new external message requires a person's decision. Save the timeout case as a regression example for the workflow, so the next connection failure costs one reconciliation step.