From the buyer's side, duplicate follow-up emails do not look like successful recovery. They look like a supplier has lost track of the conversation. If the second email also changes the wording or attachment, the recipient may have to decide which version to trust.
The underlying failure can be surprisingly small. An agent sends a message, receives no response from the service, and interprets a timeout as proof that nothing happened. It rewrites the email and tries again. The first request may already have been accepted.
Meta's October 12 introduction of Muse Wonder describes Active Focus as helping a model persist and recover from errors. That capability description does not establish duplicate prevention in an external email service. The design recommendations here concern the surrounding sales workflow, not an undocumented claim about Meta's implementation.
Unknown is a real state, not an inconvenient error
A confirmed send, a confirmed rejection and an unavailable result need separate treatment. A request rejected before acceptance is different from an accepted request whose response was lost. A timeout alone does not tell the calling system which event occurred.
Give the sales record a pending-verification state. An operator seeing it should inspect the sending service's task result or sent-message record before composing a replacement. If the service's records are delayed, follow its documented behavior rather than inventing an arbitrary waiting period and assuming absence proves failure.
This distinction also prevents an unrelated reporting mistake. Acceptance by a sending service does not show that the buyer received, read or understood the message. Delivery failures and customer replies are separate facts. Duplicate prevention should not silently advance a CRM opportunity to contacted or engaged.
When reliable readback is unavailable, the task may need human reconciliation. That is preferable to repeatedly experimenting with the same customer-facing action. For a Chinese exporter and its overseas sales partner, both teams need to see the pending state; otherwise one may manually fill the perceived gap while the other is still investigating.
Identify the business action before making the call
Time-bounded sending access establishes whether the agent may send; reconciliation establishes whether it has already sent. Create a stable identifier for the intended follow-up before sending it. Associate that identifier with the recipient, business record and approved content version. A retry should retain that identity rather than becoming a new task because the model chose another opening sentence.
If the provider supports an idempotency key, use the same key for retries of that action according to the provider's rules. If it does not, an internal task record can still support checking and suppression, but it is not proof that all concurrent duplication has been eliminated. The implementation needs to match the actual external service.
A body hash is insufficient as the sole business identity. An agent can change punctuation and produce a new hash while performing the same follow-up. Conversely, the same brochure text sent to different buyers should not be blocked as one global duplicate. The relevant unit includes the recipient and the purpose of the action.
Concurrent human and automated work needs coordination too. Mark when the action is being executed, preserve the resulting external message identifier, and show that state to anyone taking over. A shared to-do list without an executing state can still let two senders act at once.
Recovery may mean recording success, not sending again
If the original message is found, finish by recording its result and continuing the workflow. Do not repeat the send simply because the agent's earlier tool call ended with an error. If the request is confirmed unaccepted and remains authorized, retry under the service's rules. If the result is unresolved, stop that external action and give a named person the evidence needed to investigate.
Quotes, changed attachments and delivery statements deserve particular care because slight differences between duplicate messages can create a substantive ambiguity. The agent should not solve uncertainty by drafting a more persuasive second version. It needs to establish what the recipient may already have received.
If duplication has happened, do not automatically add an apology email. First compare the messages and determine whether the buyer needs a clarification. A salesperson can then choose the appropriate response. A third unnecessary message can make a technical recovery feel like another interruption.
Sources
Meta Newsroom, Introducing Muse Wonder and Muse Wonder Full: Frontier Models for Agents, October 12, 2026.