Prevent retries, worker restarts, duplicate webhooks, delayed approvals, and uncertain provider responses from sending the same agent message twice.
Outbound messaging is a consequential side effect. The assistant must distinguish retrying its internal work from sending another copy to a person.
An AI assistant may decide to send a reminder, appointment request, customer update, recruiter outreach, or confirmation. The send crosses several asynchronous boundaries: the model proposes content, policy and approval are evaluated, a worker calls a provider or drives a messaging interface, the provider queues delivery, carriers or platform services process it, and callbacks report changing status.
Every boundary can repeat or fail ambiguously. A task event may be delivered twice. Two workers may race. The provider may accept the message while its response is lost. A status callback may arrive more than once or out of order. The worker may crash after send but before writing the provider identifier. The recipient may reply before local state catches up.
Naive systems treat each event as a fresh instruction and every missing response as a reason to send again. Duplicate-safe messaging treats the user's intended communication as a durable operation. It assigns message identity before calling the provider, grants only one worker ownership of the send, stores provider evidence, deduplicates callbacks, and keeps delivery-state updates separate from the decision to create another outbound message.
This is not the same as suppressing all repeated content. A user may intentionally send a second reminder tomorrow. The system must distinguish a new communication intent from a repeated attempt to fulfill the old one. That distinction depends on recipient, channel, purpose, content version, campaign or task, approval, and time boundary.
For a text-message AI assistant, the message thread is both an interface and an external side effect. Clear identity, state, and receipts keep the convenience of texting from hiding operational ambiguity.
Create the operation before sending. Bind it to the task, recipient, channel, purpose, content version, approval version, and a server-side identity. Provider identifiers are evidence attached afterward, not the only identity.
A retried worker must recover the same operation. A materially changed recipient, content, purpose, or schedule creates a new version or new operation.
Use a transactional lease, uniqueness constraint, or compare-and-swap so only one worker can move an approved operation into sending. An expired lease does not prove the provider never accepted the message.
Persist the operation identity before the call, capture the provider message ID, and query status or sent history before resending after an ambiguous response.
Treat provider callbacks as repeatable observations. Store event identity where available and apply monotonic or provider-specific status transition rules.
Separate accepted, sent, delivered, undelivered, read, replied, and closed. A delivery update changes evidence; it should not create a new outbound intent.
Each failure should produce one intended send and a legible recovery state.
Do not overload one “sent” boolean. Separate authority, provider acceptance, delivery evidence, and task closure.
The assistant has a proposed message, channel, recipient, purpose, and task context. Policy checks and content review may still run. No external send is allowed yet.
The user or policy approves this recipient, content, channel, and time window. Approval references the message version. Editing material content or destination invalidates it.
A durable lease grants one commit attempt. The operation record and provider request identity are persisted before the external call. Other workers return the current operation instead of sending.
The response was lost or the worker stopped at an ambiguous point. The system blocks resend and reconciles through provider lookup, sent items, or channel history.
The provider ID is stored with the operation. Status callbacks may update queued, sent, delivered, or failed evidence, but they do not create another operation.
The system applies provider-specific transition rules and retains error details. A failed delivery may permit a new channel strategy only under a new decision, not an automatic duplicate send.
The receipt links intent, approval, message version, provider reference, delivery evidence, retries, and recipient reply where relevant. Task closure and provider delivery remain separately queryable.
Callbacks may repeat. Workers may restart. Providers may respond late. The communication intent must remain singular.
| Test | Injection | Expected behavior | Evidence |
|---|---|---|---|
| Lost provider response | Accept send but drop response | Operation becomes unknown and reconciles before resend | One provider message ID |
| Duplicate task event | Deliver same queue message twice | Both deliveries resolve to one operation | One send lease |
| Concurrent workers | Start two send workers | One commits; one observes in-progress state | Transactional ownership history |
| Worker crash | Terminate after provider acceptance | Replacement looks up existing message | Persisted request identity |
| Duplicate callback | Replay delivered callback | Status remains delivered; no new side effect | Deduplicated event record |
| Out-of-order callback | Deliver sent after delivered | Transition policy does not regress terminal evidence | Status transition log |
| Repeated approval | Process same approval twice | Second event returns current operation | One approved version |
| Edited content | Change message after approval | New version requires fresh approval | Stale approval rejection |
| Delivery failure | Provider reports undelivered | No automatic duplicate or channel switch without policy | Explicit recovery decision |
| Receipt-message failure | Drop internal completion notification | Recipient message remains singular; internal notice retries separately | Separate operation identities |
The agent asks for approval in the same conversational channel while preserving a structured message operation and exact content version behind the thread.
Text-message assistant use caseWhen a message sends through a website, computer-use state and sent-history reconciliation prevent a missing confirmation from producing another click.
Computer-use cache use caseDeployment announcements and customer updates receive identities separate from the release itself, so notification retry cannot republish the artifact.
Agent-built website use caseSuper can make approval, task state, and receipts legible in the message thread while deeper controls keep external communication singular.
Explore Super“A repeated webhook is another observation, not another reason to send.”
Composite perspective: messaging engineer
“If the provider response disappears, check sent history before contacting the customer again.”
Composite perspective: operations lead
“Approval belongs to the exact recipient and content version, not the general idea of outreach.”
Composite perspective: security reviewer
No. It usually exists only after the provider accepts a request. The application needs its own stable operation identity before sending so retries and workers can coordinate. The provider ID then becomes evidence linked to that operation.
A content hash can support comparison but is not the full identity. The same text may be intentionally sent to different recipients or at different times. Identity should include task, recipient, channel, purpose, content version, and a server-controlled operation record.
Messaging systems should assume webhooks and callbacks may repeat. Handlers should be idempotent, record event identity where available, and apply valid status transitions. A callback updates evidence for an existing message operation; it should never initiate another send by itself.
A delivery failure does not automatically authorize resending or switching channels. Policy may allow a bounded retry for specific transient states, or the system may ask the user to choose another channel. The decision should create or update a clear operation rather than looping invisibly.
Approval should show resolved recipient, channel, exact content, timing, and audience scope. It binds to that version and expires. If the agent edits the message materially or changes destination, it should request approval again.
Include operation identity, task, recipient reference, channel, content version or safe digest, approval, provider ID, status history, attempts, final evidence, and exceptions. Retention and access should reflect the sensitivity of message content.
Spam controls address consent, frequency, content, and policy across campaigns or recipients. Duplicate safety prevents infrastructure retries and repeated events from multiplying one already authorized communication intent. A production system needs both.
Provider documentation for status callbacks, message states, error details, and tracking outbound message progression.
Queue documentation for deduplication, message groups, retry behavior, and preventing duplicate message introduction within documented constraints.
Guidance for event attributes, verification, sensitive-data handling, access control, and resilient security logging.
Core HTTP semantics including safe and idempotent methods, retries, and the distinction between request methods and intended effects.
These sources describe provider status, queue deduplication, logging, and HTTP semantics. The message-operation model, approval design, and agent workflow recommendations are an applied synthesis for personal AI assistants.
Super brings useful personal AI work into the message thread while keeping approval, external action, and task receipts understandable.
Explore Super