SMS and iMessage recovery playbook
Send personal AI agent recovery receipts by text message
Tell the user what changed, what was verified, and whether they need to act. Keep internal retries, trace noise, and uncertain claims out of the conversation.
Your booking update paused while we checked whether the first request completed.
Verified: one booking confirmed for 3:00 PM. No duplicate was created.
DELAY NOTICEACTION NEEDEDVERIFIED RECOVERYUNRESOLVED OUTCOMEONE MESSAGE IDENTITYNO RETRY SPAMDELAY NOTICEACTION NEEDEDVERIFIED RECOVERYUNRESOLVED OUTCOMEONE MESSAGE IDENTITYNO RETRY SPAM
A receipt is not an incident log
A recovery receipt sent by text is a concise, user-facing statement about the outcome of work that paused or failed inside a personal AI agent.
The user usually does not need every tool error, retry attempt, worker restart, or trace identifier. They need to know whether their intent completed, whether the agent prevented a duplicate, what remains uncertain, and what action is required from them.
Text is a strong recovery channel because it is immediate, conversational, and already connected to the original request in many personal-agent products. It is also unforgiving. Internal noise becomes notification fatigue, vague reassurance becomes a trust problem, and a duplicated receipt can look like a duplicated real-world action.
The design goal is therefore not “send the audit record.” It is to project structured recovery evidence into a short message while preserving a link to deeper details. The message should be generated only after a notification policy evaluates user impact, confidence, urgency, and whether the state meaningfully changed.
This playbook covers SMS and iMessage-style channels, but the core rules apply to any phone-native conversation: one stable notification identity per recovery milestone, factual outcome language, explicit action when needed, and no claim of success while a critical effect remains unknown.
Decide whether to send
A recovery event should produce a text only when it changes the user’s understanding or asks them to do something.
Send a delay notice
The expected completion time changed materially, the user may otherwise repeat the request, or the agent paused to prevent a duplicate.
Send an action request
Recovery needs renewed approval, updated information, authentication, or a decision only the user can make.
Send a final receipt
The user-visible outcome is verified, including any repaired or preserved side effects and relevant caveats.
Stay quiet
An internal retry completed inside the original expectation, no user action is needed, and the outcome has not materially changed.
Identify the notification milestone
Map recovery state into a small set of user-visible milestones: delayed, action required, verified recovered, stopped, or unresolved. Internal transitions such as worker reassignment and evidence polling should not emit messages by default.
Give the milestone a stable identity derived from the original intent, recovery case, audience, and message class. Reprocessing the same milestone must not create another text.
Resolve the facts
Read the intended outcome, user-visible effect state, recovery decision, verification method, remaining caveats, and required action from structured records. Do not rely on a model summary produced before the external effect was reconciled.
- Complete means independently verified.
- Unknown remains unknown.
- “No duplicate” requires evidence about the relevant effect identity.
Choose the audience and channel
Send to the person who owns the original intent or its delegated approver. Confirm that the phone identity is still linked, the channel permits the content, and the conversation context is appropriate. Sensitive receipts may need a short status plus an authenticated detail link.
Compose from a constrained schema
Generate the user-facing copy from explicit fields: task label, current state, verified outcome, next action, deadline, and detail URL. Keep the model inside that schema. It can improve readability but cannot add causal claims or confidence not present in the evidence.
Lead with the outcome. Avoid internal component names, raw exception text, and generic apologies that hide whether anything actually happened.
Apply notification policy
Check quiet hours, urgency, prior milestone, batching window, user preference, and whether the new message supersedes an unsent one. Escalate genuinely time-sensitive approval requests; defer informational receipts when appropriate.
Suppress messages whose only difference is another internal attempt number. A state machine should decide suppression, not string comparison.
Send with one operation identity
Use a stable outbound operation key and store the provider message ID, request fingerprint, accepted status, delivery events, and conversation linkage. If the send times out, reconcile the provider before retrying with the same logical identity.
Record and verify the receipt
Append the notification to the recovery case with template version, evidence revision, policy result, rendered content hash, provider identity, and delivery state. The deeper receipt should show exactly what the user was told and when.
If the user replies, attach that response to the active recovery case and re-evaluate intent or authorization before resuming the agent.
Message patterns
These patterns keep the message concrete. Replace only fields supported by structured recovery evidence.
Delayed while checking
Use when the agent is reconciling an uncertain external effect and another user request could create duplication.
Update: your grocery order request is paused while I verify whether the first checkout completed. Please do not submit it again. I’ll text you when the status is confirmed.
Action required
Use when the original approval expired or recovery would materially change the authorized outcome.
Approval needed: the original appointment time is no longer available. Reply YES to book 3:30 PM instead, or NO to stop. I have not created a new booking.
Verified recovery
Use when the outcome and duplicate-prevention claim are supported by provider or postcondition evidence.
Recovered: your site is live on revision a91c. I verified the deployment and did not trigger a second release. Details: example.com/r/7JQ
Message design rules
Lead with state
Start with “Update,” “Action needed,” “Recovered,” “Stopped,” or “Still checking.” The first words should tell the user why the message exists.
Name the task naturally
Use the user’s goal, such as “appointment confirmation” or “site release,” instead of internal workflow, queue, or tool names.
Separate fact from next action
State what is verified, then what the user should do. Never ask the user to repeat a request when the prior effect remains unknown.
Use links sparingly
A short authenticated link can expose the complete receipt, evidence, or controls. The text itself should still communicate the essential state without requiring a click.
Design for replies
When replies are supported, constrain expected answers, define expiry, and bind the reply to the exact recovery case. Free-form replies should route through the same message-processing core as the original conversation.
Applied personal-agent patterns
Text-message assistant
The conversation itself becomes the recovery surface. Stable inbound and outbound identities connect the user request, provider evidence, approval reply, and final receipt without opening another dashboard.
Computer-use recovery
When a browser session fails after a click, send a delay notice only if the user may repeat the task. Send the final receipt after the agent inspects the actual postcondition.
Website release recovery
Text the operator when approval is required or a release status materially changes. Include the intended revision and verified live state, not every deploy poll.
Pre-send checklist
Every recovery message should pass these checks before it reaches the provider.
The message represents a meaningful user-visible milestone.
The recipient owns or is authorized for the original intent.
Every outcome claim is backed by current evidence.
Unknown effects are described without implied success or failure.
The task is named in user language.
The next action is explicit when one is required.
The notification has a stable operation identity.
Prior messages for the same milestone are deduplicated.
Quiet hours and urgency policy were evaluated.
Sensitive details are omitted or behind authenticated access.
Reply commands are scoped and have an expiry.
The provider send will be reconciled after a timeout.
The rendered message and evidence revision are recorded.
The full recovery receipt remains available for audit.
Frequently asked questions
Should every recovery send a text?
No. Send when the user’s expectation changes, they need to act, the system pauses to prevent duplicate work, or a final outcome is verified. Quiet internal retries should remain internal.
Can a model freely write the message?
Use the model to improve clarity within a constrained schema. The current state, facts, action, deadline, and links must come from structured records. Reject copy that adds unsupported causes, confidence, or completion claims.
How do you prevent duplicate receipts?
Create a stable notification key from intent, recovery case, recipient, and milestone. Store the provider operation and delivery state. On timeout, query or reconcile before repeating the same logical send.
What if the outcome remains unknown?
Say that verification is still in progress, tell the user not to repeat the request when duplication is possible, and give a realistic next update. Do not turn uncertainty into “failed” merely to make the message simpler.
Should raw errors be included?
Usually not. Translate the user impact and current state. Keep exception text, payloads, traces, and internal service names in the detailed receipt for authorized operators.
How should replies resume the agent?
Bind an expected reply to the exact recovery case, proposed action, inputs, and expiry. Re-check authorization and changed context before executing. Record the reply as a durable approval or decision event.
Primary references
RFC 9110: HTTP SemanticsIdempotent request semantics and retry considerations.
RFC 5724: URI Scheme for GSM SMSStandards context for SMS URI addressing.
CloudEvents SpecificationPortable identity and source fields for recovery and notification events.
OpenTelemetry Observability PrimerEvidence correlation across agent and messaging services.
Text the outcome. Keep the noise backstage.
Super connects personal-agent workflows to phone-native conversations where recovery updates can be immediate, factual, and actionable.
Explore Super