AI Agent Deliveries: Draft, Saved, Sent and Published

As of September 7, 2026, an editorial classification defines sixteen delivery situations for AI agents, grouped into preparation, storage, dispatch, and audience access, to clarify what 'delivered' means. The guide instructs that statuses must name the specific copy, destination, and audience supported by evidence, and that unknown states should be reported as UNVERIFIED.

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 below when receiving work or designing an agent’s final report. It contains sixteen selected situations, grouped by preparation, storage, dispatch and audience access. These groups are our editorial vocabulary, not a universal sequence that every application follows. A saved draft may already be shared; a public page may exist without any message being sent. 1. 01Name the copy.A status belongs to an identifiable version at a destination, not to the task in the abstract. 2. 02Separate dispatch from access.A service receipt and a reader opening the result establish different boundaries. 3. 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. | Complete selected editorial classification; informed by the primary sources discussed below. As of September 7, 2026. | | | |---|---|---| | Situation and group | Supported statement | Evidence and remaining boundary | |---|---|---| | Preparation: Conversation draft | Text is present in the session. | Inspect the text; durable storage outside the session remains unverified. | | Preparation: Unsaved editor buffer | Content appears in an open editor. | Check the save result before naming a durable location. | | 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: Local file | A file exists at a named local path. | Reopen that copy; recipient access has not been established. | | Storage: Remote draft | A remote system stores a draft revision. | Read back the revision; inspect sharing separately. | | Storage: Exported copy | A derived file was produced. | Match its contents to the intended source revision. | | Storage: Retained result | A job result was copied to a lasting location. | Record the retained copy and any known retention conditions. | | 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 https://www.rfc-editor.org/rfc/rfc9110.html 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 https://www.rfc-editor.org/rfc/rfc5321.html 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. The remaining distinctions in this table are explicit reporting choices. Neither standard defines our saved-draft or audience-check rows. Application documentation and direct inspection must supply the actual state evidence. A status label copied from an interface is useful context, but its meaning still needs to match the claim being made. 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 /blog/ai-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 /blog/ai-agent-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 /blog/ai-agent-publication-review 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 - 16 delivery situations across 4 evidence boundaries. The complete selected reference appears above; no claim of exhaustive coverage. - 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. - Counting - Each row is one selected editorial case, assigned to its displayed group. Chart widths use 45 SVG units per entry. Group sizes describe this reference, not a measured distribution. - 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 /services/ai-transformation .