AI Agent Deliveries: Draft, Saved, Sent and Published

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.

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.

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.

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.

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.

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; the article is dated 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.

Refresh. Review when source guidance or the classification changes.

The reference exists because one word, sent, covers several different states. The illustrative reports below each used sent, or a stronger word, honestly, and each meant something narrower than the reader heard. They are patterns the table rows describe, not observed incidents.

Each report would have been correct with the narrowest supported statement in place of sent. The ladder in the next section is a way to find that statement quickly.

A delivery report is easier to write and to check if it climbs four steps in order and stops at the last one with evidence. Prepared: the content exists in an identifiable version, with a revision, attachment identifier or content hash rather than a filename such as final. Stored: that version is at a named location, and the save result was inspected rather than assumed. Dispatched: a request carrying that version left for a destination, and the destination’s response is recorded as the service defines it, whether a 202 or a mail acceptance; an interface label is recorded as context, not as the state. Reachable: the intended audience can open it, checked from that audience’s access context at a stated time.

An illustrative record for a partner announcement climbs the ladder like this: version two of the announcement document, content hash recorded; stored in the shared review folder, save confirmed; dispatched by email to the partner contact, mail server acceptance recorded at the stated time; reachability not checked, because the brief did not ask for a public page. The report is complete at step three, and it says so. If the brief had asked for publication, step four is a signed-out request to the public address, and the record says whether it succeeded and when.

The ladder also makes interruption honest. A dispatch that times out stops the record at step three with the request identifier and the lookup that would resolve it, as the apply section asks. It does not fall back to step two and call the work saved, and it does not jump to step four on the strength of a receipt.

Take the next agent task that ends in a message or a page and ask the agent to report with the ladder. The first report will show which steps it can observe and which it has been inferring, and that is the boundary to fix in its instructions before the next delivery claim.