Ask an AI agent where the result exists and who can reach it before accepting “delivered.” A draft in the conversation, a saved document, a dispatched message and a public page are different outcomes. The right status names the particular copy, destination and audience supported by the evidence.
Use the reference when receiving work or designing an agent’s final report. Preparation, storage, dispatch and audience access can overlap: a saved draft may already be shared, and a public page may exist without any message being sent.
- 01Name the copy.A status belongs to an identifiable version at a destination, not to the task in the abstract.
- 02Separate dispatch from access.A service receipt and a reader opening the result establish different boundaries.
- 03Keep unknown states visible.If the evidence is missing, report UNVERIFIED instead of advancing the status.
01 — Match the delivery claim to its evidenceMatch the delivery claim to its evidence
Each row names one delivery situation and the evidence to inspect. “Sent” is particularly ambiguous: it may mean a request left the agent, a service accepted it, or a recipient received it. Replace the bare word with the narrowest supported statement. Audience means the people or systems intended to receive the result, not everyone with access to the agent’s session.
| Situation and group | Supported statement | Evidence and remaining boundary |
|---|---|---|
| Preparation: Unsaved text | Text appears in a conversation or open editor. | Inspect that text; check a save result before naming a durable copy. |
| Preparation: Preview build | A rendered candidate can be inspected. | Identify the preview version; production availability is a separate claim. |
| Preparation: Approved candidate | An owner has approved an identified candidate. | Retain the approval scope; approval is not execution evidence. |
| Storage: Saved or retained copy | A file or draft revision exists at a named location. | Reopen or read back that copy; record retention conditions and check recipient sharing separately. |
| Storage: Exported copy | A derived file was produced. | Match its contents to the intended source revision. |
| Dispatch: Request submitted | The client attempted the delivery operation. | Preserve the request record; server acceptance may still be unknown. |
| Dispatch: Accepted for processing | The service acknowledged pending work. | Keep the job identifier and inspect its terminal outcome. |
| Dispatch: Transport accepted | A transport service accepted responsibility. | Use the transport receipt; do not infer human receipt or reading. |
| Dispatch: Failed delivery reported | A service reported a delivery failure. | Retain the failure scope and affected destination before deciding on a retry. |
| Audience: Named access checked | The intended collaborator can access the copy. | Record the checked identity or role and version. |
| Audience: Public access checked | The intended public view was retrieved. | Record URL, version and observation context; indexing is separate. |
| Audience: Receipt acknowledged | The recipient confirms receiving the item. | Associate the acknowledgment with the specific item. |
| Audience: Use confirmed | The recipient confirms using the result. | Record the stated use; do not infer approval of every detail. |
02 — What acceptance receipts establishWhat acceptance receipts establish
RFC 9110, section 15.3.3 defines HTTP 202 as acceptance for processing while completion remains pending. An agent that receives this response should preserve the job reference and inspect the later result. The response alone does not establish publication.
RFC 5321, section 4.2.5 describes an SMTP server accepting responsibility after the message data is accepted. That responsibility can include later delivery attempts or failure reporting. This supports distinguishing transport acceptance from a person reading a message; it does not define the labels in every email interface.
For application states, inspect the saved draft or destination itself. An interface label supplies context, but the completion report must match the state actually observed.
03 — Follow the exact copy through the taskFollow the exact copy through the task
Consider a hypothetical agent preparing a partner announcement. It writes the approved text in a document, exports a PDF and attaches an earlier PDF to a message. All three copies exist, and the message may have been dispatched successfully. The delivery claim still needs to identify which version went to the partner.
Give the deliverable a stable identifier appropriate to the system: a revision, an attachment identifier or a content hash. A hash is a fingerprint of file contents; it helps compare copies but says nothing about whether the contents are correct. Keep the identifier beside the destination rather than relying on a filename such as “final.”
Our file-output acceptance reference covers whether the delivered file is usable. Apply that check to the copy that crossed the boundary, not only to the source document the agent previewed.
04 — Check access from the intended audienceCheck access from the intended audience
A publisher’s authenticated preview can show a page that an ordinary reader cannot reach. Conversely, an unlisted link may already grant access to anyone holding it. Describe the access conditions you checked: signed out, named collaborator, organization member or another relevant audience.
An audience check is a point-in-time observation, not a promise of permanent availability. If a link expires, record that condition. If the task only required a private draft, private availability is the intended result. Do not publish more broadly merely to produce a stronger-sounding completion message.
The screenshot evidence reference helps bound what a capture supports. A screenshot taken in an editor’s account does not independently establish the view available to a public visitor.
05 — Write a delivery record someone can act onWrite a delivery record someone can act on
A useful record reads: result and version; storage location; requested delivery boundary; action attempted; evidence observed; remaining uncertainty. Add the recipient or audience when relevant. For example, a hypothetical report can be “saved at the review location, sharing checked for the named reviewer, external dispatch not requested.” That is complete if it matches the brief.
For an interrupted dispatch, preserve the request identifier and say which lookup would resolve the uncertainty. Avoid treating missing evidence as proof of failure. A second send can create a second message even though the first status lookup failed.
Approval belongs in a separate field. The publication review guide explains how to bind approval to the proposed version and destination. Permission to save a document should not be interpreted as permission to publish it.
- Scope
- Preparation, storage, dispatch and audience-access claims with their required evidence.
- As-of date
- September 7, 2026. Actual source collection and review date; assigned publication is September 7, 2026.
- Collection
- Select distinct claims about preparation, storage, dispatch and audience access. Read the two protocol sources, then state the application evidence each claim would require. Assign each row to its immediate reporting boundary.
- Sources and interpretation
- HTTP and SMTP establish limited protocol distinctions. Other rows are original reporting cases, not standardized statuses. Groups can coexist for one artifact; the selected list is not exhaustive.
- Exclusions
- No vendor census, model benchmark, search-volume estimate, measured savings or failure rate. Worked examples are hypothetical; no customer operations were tested.
- Gaps and limitations
- UNVERIFIED means the required evidence was not inspected, was inaccessible or remains ambiguous after inspection. A selected case can overlap others in practice; preserve the specific claim and its uncertainty.
06 — DecisionWhat to do next
Report the boundary you actually checked.
Identify the copy, destination and audience. Match the requested outcome to evidence at that boundary, and leave uncertain transitions visible so the next person knows what to inspect.
For implementation support, explore our AI transformation services.