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 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.

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.

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.

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.