Task
Canonical receipt service
Owns task identity, intent, approval, immutable artifacts or item sets, authority provenance, execution events, verification, failure classification, closure, corrections, and linked follow-up tasks.
Build an AI agent receipt inbox for iMessage.
Correlate approval, execution, verification, failure, and access closure in the same conversation without turning chat into a raw event log.
Follow the implementationWebsite release · Partial
Hosting route passed. Custom domain still returns 404. Deployment access is closed. Reply DETAILS or FIX DNS.
Hosting route passed. Custom domain still returns 404. Deployment access is closed. Reply DETAILS or FIX DNS.
Model one taskCorrelate all evidenceDerive statusCompose channel-safe textLink secure detailRoute replies safelyModel one task
System goal
Make iMessage the user interface while structured receipts remain the source of truth.
Architecture before wording
The message thread should never be the only record of an agent task. Messages can arrive late, delivery can fail, users can delete history, and conversational language can blur important distinctions. Build a canonical task and receipt service first, then render iMessage summaries from its verified state.
The architecture needs stable correlation across request, approval, grant, agent runtime, tools, browser actions, provider outcomes, independent checks, revocation, outbound messages, and replies. Every channel event points back to the same task, but the receipt remains immutable once finalized.
Implementation ruleThe model may improve phrasing, but it cannot decide whether the task is complete, whether verification passed, or whether authority is closed. Those states come from structured evidence.
The inbox view can live in the conversation itself, a companion application, or a secure web page linked from iMessage. The important part is consistent state: needs approval, running, complete, partial, failed, rolled back, unverified, or attention required.
Architecture
Four services keep conversation and evidence aligned.
Message composer
Maps accountable states into explicit channel-safe templates with outcome, failed checks, closure, and next action.
Secure detail gateway
Issues opaque expiring links and requires appropriate authentication before exposing sensitive evidence.
Reply action router
Turns DETAILS, REVOKE, RETRY, ROLLBACK, and remediation replies into fresh policy-checked actions.
Canonical schema
Define the accountable task before building the inbox.
Receipt record
This simplified schema separates user intent, authority, execution, and outcome while retaining a common task identity.
{
"task_id": "task_7K4P",
"state": "partial",
"intent": { "action": "publish", "target": "site_A" },
"approval": { "artifact": "sha256:6f82...", "channel": "imessage" },
"authority": { "scope": "deploy:site_A", "closed": true },
"execution": { "release_id": "deploy_185", "status": "success" },
"verification": { "passed": 5, "failed": ["custom_domain"] },
"next_actions": ["details", "fix_dns"],
"receipt_version": 1
}
Build sequence
Seven steps to a production inbox.
STEP A
Issue stable task and approval identifiers
Create identifiers before the first approval message. Include them in policy, agent, browser, credential, verification, receipt, and delivery events.
STEP B
Ingest attributable source events
Normalize events while retaining source, timestamp, actor, integrity metadata, and redaction status. Never trust a model summary as the only evidence.
STEP C
Derive status through explicit rules
Define required checks and closure conditions by task type. A provider success cannot produce complete status when a required custom route fails.
if authority.open: state = "attention"
elif rollback.passed: state = "rolled_back"
elif required_checks.failed: state = "partial"
elif required_checks.unknown: state = "unverified"
else: state = "complete"STEP D
Compose from state templates
Use deterministic receipt fields for outcome, failure, checks, closure, and next action. Language generation can shorten or clarify within those facts.
STEP E
Create an opaque secure detail link
Bind access to receipt, intended recipient, expiry, and authentication policy. Keep account names, task content, and receipt IDs out of the URL.
STEP F
Send idempotently and track delivery
Use receipt ID plus version as the idempotency key. Record provider acceptance, delivery when available, and fallback handling without rerunning the task.
STEP G
Route replies into fresh actions
Resolve the task, authenticate sensitive actions, reevaluate current state, and create a new linked request. Historical receipts stay unchanged.
Reply routing
Treat conversational shortcuts as requests, not commands.
| Reply | Policy action | Expected behavior |
|---|---|---|
| DETAILS | Low risk | Issue or refresh an authenticated detail link to the immutable receipt. |
| REVOKE | Verify context | Identify active grants and ask for confirmation when multiple tasks or accounts match. |
| RETRY | Fresh evaluation | Create a new task with current artifact, destination, policy, and authority requirements. |
| ROLLBACK | Step-up approval | Verify rollback target and consequence before issuing temporary authority. |
| FIX DNS | Separate capability | Start a new infrastructure-change task; do not reuse the deployment grant. |
| STOP | Immediate | Cancel safe pending work, revoke available authority, and report what could not be stopped. |
Message states
Test the states users will actually encounter.
COMPLETE
Site published. Six required checks passed and deployment access is closed. Reply DETAILS for the receipt.
Verified ending
All required execution, outcome, and closure conditions are satisfied.
PARTIAL
Published to Render, but the custom domain returns 404. Access is closed. Reply FIX DNS or DETAILS.
Split outcome
State what succeeded and failed, then offer a bounded remediation action.
ATTENTION
The update was blocked, but the temporary browser session is still active. Reply REVOKE now or open DETAILS.
Open authority
Keep the task prominent until sensitive access is closed or explicitly accepted.
Verification checklist
Test the inbox as a distributed system
Out-of-order events
Late tool and verification events cannot incorrectly regress finalized state.
Duplicate delivery callbacks
Provider retries do not create duplicate receipt messages.
Ambiguous replies
The router asks for clarification when multiple open tasks could match.
Expired secure links
Users can authenticate and refresh access to the same immutable receipt.
Partial verification
Unknown and failed checks cannot be summarized as complete.
Active authority alarms
Open sensitive grants remain visible and trigger escalation policy.
The iMessage thread is the interface. The canonical receipt is the evidence. Neither should pretend to be the other.
Failure recovery
Protect the task record when messaging breaks.
Outbound message fails
Keep the canonical receipt, record delivery state, retry idempotently, and use approved fallback channels. Never rerun agent execution.
Messaging failure is not task failure.Receipt state changes later
Append a correction event and send an explicit update referencing the prior status. Do not silently rewrite delivered history.
Corrections need provenance.User deletes the conversation
The canonical receipt remains available after authentication according to retention policy. Message history is not the system of record.
Conversation is a view, not storage.Use this with Super
Super already has the natural surface for a receipt inbox.
One conversation, structured underneath
The text-message AI assistant can preserve the natural request and approval flow while a canonical task service manages state and evidence underneath. The user receives concise updates without losing accountability.
For a computer-use cache, the inbox can distinguish persistent safe browser state from temporary sensitive access. Any authority that remains open can stay in the attention view until revoked.
When an AI agent builds websites, Super can correlate preview approval, artifact digest, deployment grant, provider release, Render verification, custom-domain failure, and revocation in one task-centered iMessage thread.
FAQ
Implementation questions
Do I need direct iMessage APIs?
The channel adapter depends on the available messaging infrastructure, but the canonical receipt, state derivation, secure links, and reply routing should remain channel-independent so SMS or an app inbox can serve as fallback.
Should receipt messages be generated by the model?
Use structured state templates for factual claims. A model can improve readability within supplied fields, but it cannot invent status, verification, failure, access closure, or next actions.
How do I prevent reply confusion?
Maintain explicit thread and task context, use short human-friendly task references, and ask for clarification when a reply could apply to multiple active tasks or accounts.
Can a receipt be updated?
Append corrections or new verification versions while preserving previous states. A delivered receipt should never be silently rewritten because users may have acted on it.
What should be retained?
Retain the minimum structured evidence required for accountability under user preferences, privacy obligations, and risk. Exclude secret values and support secure export and deletion.
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 policy and resource-level authorization.
- OWASP Secrets Management Cheat Sheet. Secret audit, expiration, revocation, and secure token handling.
- NIST SP 800-63B, Authentication and Authenticator Management. Authentication lifecycle relevant to secure receipt access.