Result
Lead with what changed
Name the completed or failed outcome in user language: files uploaded, website published, message sent, appointment booked, account unchanged, or rollback completed.
Send AI agent action receipts by text message.
Return the outcome where the user made the decision, with enough evidence to trust the result and a secure path to complete details.
Build the receipt flowSite published. The approved artifact is live and 6 checks passed. Deployment access is closed. Receipt: secure.example/r/7K4P
Correlate one taskSummarize one outcomeName every failureConfirm access closureLink secure detailRecord delivery stateCorrelate one task
Why text works
The receipt belongs in the channel where approval happened.
Close the conversational loop
A personal agent may ask for permission by text because the user is away from the browser, the task runs asynchronously, or the consequential step occurs long after the original request. Once the user approves, the conversation becomes the natural place to return the outcome.
A weak completion message says "done" and forces the user to open another application to learn what changed. A strong action receipt summarizes the exact task, result, failed checks, and authority-closure state, then offers a secure link to structured evidence. The message remains useful even if the user never opens the link.
Messaging ruleThe first text must state the outcome and any failure plainly. Never hide a broken custom domain, incomplete verification, or still-active credential behind a generic success message.
SMS and iMessage also impose useful discipline. Small screens and interruption-heavy reading encourage a concise hierarchy: outcome first, evidence second, next action third. Sensitive values stay out of the message body, and detailed records remain behind authenticated, expiring links.
Message anatomy
Five facts belong in the first screen.
Match the approval
Reference the approved artifact, item set, account, or destination without exposing sensitive identifiers.
Name verification
State which checks passed and call out anything that failed, timed out, or remained unverified.
Confirm closure
Tell the user whether temporary access, browser sessions, and isolated runtime state are closed.
Implementation workflow
Six stages from canonical receipt to delivered text.
STAGE A
Create one correlation ID before approval
The approval request, credential grant, agent execution, verification checks, canonical receipt, outbound message, and reply handling must share a stable task identifier.
task_id: task_7K4P
approval_id: approval_884
receipt_id: receipt_7K4PSTAGE B
Finalize the canonical receipt first
Build the complete structured record from trustworthy source events. Include intent, approval, artifact or item identifiers, agent and runtime identity, authority scope, execution outcome, verification, failures, and closure.
STAGE C
Compose a channel-safe summary
Derive the message from structured receipt fields rather than asking the model to remember the task. Use explicit templates for completed, partial, failed, rolled-back, and access-still-open states.
status: partial
headline: "Site published; custom domain failed"
checks: "5 passed, 1 failed"
access: "closed"
next_action: "Update DNS"STAGE D
Issue an authenticated, expiring detail link
Use an opaque token, short expiry, recipient binding where practical, and reauthentication for sensitive records. Do not place task content, credentials, or predictable identifiers in the URL.
STAGE E
Deliver idempotently and record state
Use the receipt ID as an idempotency key so retries do not send duplicate completion messages. Record provider acceptance, delivery status when available, and fallback-channel use.
STAGE F
Handle replies against the same receipt
Replies such as "details," "retry," "rollback," or "revoke" should resolve to the canonical task, check current policy, and create a new action rather than mutate the historical receipt.
Message templates
Write the status users actually need.
COMPLETE
Website published. The approved artifact is live and 6 checks passed. Deployment access is closed. Receipt: secure.example/r/7K4P
Use when everything passed
Outcome, verification count, closure state, and secure detail path fit in one concise message.
PARTIAL
Website published to Render, but the custom domain still returns 404. Deployment access is closed. Next step: fix DNS. Receipt: secure.example/r/8Q2M
Use when user-visible checks disagree
Lead with the split result instead of calling the whole task successful.
FAILED + ROLLED BACK
Release verification failed, so I restored the prior version. The old site is healthy and publishing access is closed. Receipt: secure.example/r/3D9L
Use when safety action succeeded
Tell the user the requested change failed and the rollback outcome separately.
Status policy
Choose the message state from evidence, not tone.
| Evidence state | Message status | Required wording |
|---|---|---|
| Execution and all required checks passed; authority closed | Complete | Name the result, check summary, and closure. |
| Core action succeeded but one user-visible check failed | Partial | Name both the success and failure plus the next action. |
| Execution failed before a consequential change | Failed | State that no change occurred and confirm authority closure. |
| Execution changed state, verification failed, rollback passed | Rolled back | State requested change failure and restored-state verification. |
| Any temporary authority remains active | Attention required | Never say complete; name the active access and revocation action. |
| Verification timed out or could not run | Unverified | Distinguish provider response from unknown user-visible outcome. |
Security checklist
Keep the text useful without turning it into a data leak.
No secrets in message content
Exclude tokens, passwords, cookies, one-time codes, private keys, and sensitive payloads.
Opaque receipt links
URLs reveal no account, task, artifact, phone, or predictable receipt identifiers.
Recipient-aware access
Sensitive details require authentication or proof tied to the intended recipient.
Short link lifetime
Detail tokens expire independently while the canonical receipt remains accessible after sign-in.
Safe lock-screen preview
The first line communicates status without exposing confidential customer or account details.
Consent and channel policy
Respect messaging permission, quiet hours, opt-out handling, and fallback-channel preferences.
The best receipt text is complete enough to trust and small enough to understand before the user unlocks another app.
Failure handling
Design delivery failures as carefully as task failures.
Message delivery fails
Keep the canonical receipt intact, record provider status, retry idempotently under policy, and use the user's approved fallback channel when available.
Never rerun the agent task because the receipt text failed.Detail link expires
Require authentication and issue a new short-lived link to the same immutable receipt. Do not create a replacement receipt with changed history.
Refresh access, not evidence.User replies "retry"
Treat the reply as a new action request linked to the old receipt. Reevaluate current state, policy, artifact, destination, and authority before execution.
A receipt is history, not an executable command.Use this with Super
Super can keep approval and accountability in one conversation.
A natural messaging workflow
The text-message AI assistant can ask for a bounded approval, pause while the user decides, continue execution, and return the evidence-backed receipt to the same thread. The conversational history makes the relationship between request, consent, and result easier to follow.
For remote browser work, the computer-use cache can preserve safe state while the receipt states which sensitive access was temporary and whether it closed. The message does not need to expose implementation details to clarify that boundary.
When an AI agent builds and publishes a website, Super can text the preview approval request and later deliver the live route, verification count, failed custom-domain status, rollback result, and deployment-access closure in one compact receipt.
FAQ
Messaging implementation questions
Should the complete receipt fit in one SMS?
The essential outcome should fit in one concise message when practical, but the canonical structured receipt should not be compressed into the SMS. Use a secure authenticated link for details and evidence.
Can iMessage include richer receipt previews?
Potentially, but design the core semantics to survive plain text and fallback delivery. The outcome, failure, verification, closure, and next action should not depend on rich rendering.
How should multiple agent tasks be handled in one thread?
Use stable task and receipt IDs internally, include a short human-friendly task reference in messages, and resolve replies against explicit current context. Ask for clarification when a reply could apply to multiple open tasks.
Should receipt links contain signed tokens?
They can use signed or server-stored opaque tokens, but the URL should not expose sensitive claims. Use short expiry, replay controls where needed, authentication for sensitive content, and revocation support.
What if the user opts out of messages during a task?
Honor the opt-out immediately for nonessential messaging, preserve the canonical receipt, and deliver it through the user's configured product inbox or approved alternative channel.
Primary references
- NIST, Implementing a Zero Trust Architecture. Just-in-time access, least privilege, continuous evaluation, and policy decisions.
- NIST SP 800-207, Zero Trust Architecture. Dynamic access policy and resource-level authorization.
- OWASP Secrets Management Cheat Sheet. Secret audit, expiration, revocation, rotation, and secure token handling.
- NIST SP 800-63B, Authentication and Authenticator Management. Authentication lifecycle and verifier requirements relevant to secured receipt access.