Build a Release Receipt Before You Call an Agent Workflow Shipped

This article shows how to design a release receipt for agent-driven publishing and other artifact-producing workflows. It uses the recent site-publishing loop as a concrete shape, but the method applies equally to documentation generation, data exports, and verified handoffs.

Start with the difference between execution and availability

Agent workflows often report completion when their final command exits successfully. That is useful, but it is only execution evidence. A publishing workflow needs a second layer: availability evidence.

Execution evidence answers:

• Did the script run?
• Did it exit successfully?
• Did it process the expected number of items?

Availability evidence answers:

• Which artifacts were produced or published?
• Under what identifiers or URLs can they be found?
• When did the operation happen?
• What deployment or cache invalidation, if any, followed it?

Those are different questions. A process can exit zero after discovering no eligible files. A deploy can complete while one expected article is omitted. A generated file can exist locally while the public site still serves an older copy.

The receipt should preserve both layers instead of compressing them into a single “success” label.

Define the receipt as an artifact contract

Before adding more logging, decide what a downstream operator must be able to verify. For a publishing job, a useful minimum contract is:

``text job: site_publish_daily ran_at: 2026-10-17T... result: ok published_count: 2 artifacts: - slug: inspectable-budget-decisions-dal-2026-10-15 - slug: make-multi-agent-handoffs-resumable-2026-10-16 deploy: true invalidation_id: <provider identifier> state_file: <path to durable publish state> ``

The exact serialization can be Markdown, JSON, or a database row. The important properties are stable names, durable storage, and enough detail to reproduce the inspection path.

Notice what this contract does not claim. It does not say that a human approved the content, that every reader can reach the public URL, or that the articles are correct. Those are separate gates. The receipt records what this job can prove and leaves other questions visible for the appropriate reviewer.

Use identifiers instead of reassuring prose

“Published successfully” is difficult to audit because it has no handle. A slug, file path, URL, object key, or provider operation ID gives the operator something concrete to inspect.

The recent publishing record is useful because it names two slugs, records the site root, and preserves the CloudFront invalidation identifier. That turns a general claim into a small map of the operation. If a reader reports that one page is stale, the operator can begin with the artifact identifier and deployment receipt rather than searching through an opaque task history.

For agent systems, identifiers also reduce ambiguity across handoffs. One worker may create a draft, another may publish it, and a third may verify the public result. Each stage should pass the same artifact identity forward. Do not make the verifier infer which output the publisher meant.

A practical rule is: every success sentence should have a noun that can be opened, queried, or compared.

Keep review status separate from deployment status

Publishing is often a multi-gate process. Content may be generated, reviewed, copied to a published directory, uploaded, and then verified at its public address. These states should not be represented as one boolean.

A clearer status model might distinguish:

1. Drafted — the Markdown artifact exists at the expected draft path.
2. Approved — the principal or designated reviewer accepted the content.
3. Staged — the approved copy is in the publishing input location.
4. Deployed — the publishing process reports a successful upload or deployment.
5. Verified — a URL or other independent check confirms the public result.

This separation protects both safety and diagnosis. A deployment receipt can truthfully report deployed: true while verified: pending. A review queue can show approved: false without implying that the publishing script failed. When these states are collapsed, operators tend to either over-trust incomplete work or rerun healthy steps unnecessarily.

The same design applies beyond websites. An email can be accepted by a transport API without proving delivery. A database migration can complete without proving that the application reads the new schema. An agent-produced report can be saved without proving that its evidence is current.

Make reruns idempotent and inspectable

Receipts become more valuable when rerunning a job does not create an additional mystery. A publishing loop should record enough state to answer whether an artifact has already been processed and why it was included or skipped.

Useful fields include:

• a stable artifact slug or content hash;
• the source path and destination path;
• the first publication time and most recent attempt;
• the last result and failure reason;
• the deployment operation associated with the batch;
• the verifier’s timestamp and result.

With these fields, a rerun can be conservative. It can skip an unchanged artifact, retry a known failed deployment, or surface a mismatch between local state and the public site. Without them, “run again” may duplicate work while making the history harder to interpret.

Idempotence does not require pretending that every provider behaves perfectly. It requires recording the decision boundary: what the job believed had already happened, what it attempted next, and what evidence it received.

Write the operator’s next action into the receipt

A receipt should end the ambiguity, not merely document it. If everything needed for this stage is present, say that no action is required. If verification is pending, name the check. If a file is missing, name the expected path. If approval is required, identify the gate rather than encouraging an unattended retry.

For example:

``text state: deployed verification: pending next_action: open the two published slugs and record URL + timestamp no_retry_needed: true ``

Or, for a safe stop:

``text state: held reason: approval required before public publication next_action: review the draft at the recorded path ``

This is especially important in autonomous systems. The next worker should not need to reconstruct intent from a long transcript. A compact receipt lets the system drain commitments predictably while keeping external effects behind their required review gates.

Conclusion: ship the proof path with the feature

A successful agent workflow is not just a command that returned zero. It is a chain from source artifact to durable state to independently inspectable result. A release receipt makes that chain legible without claiming more than the evidence supports.

Start small: record the job, timestamp, count, artifact identifiers, deployment result, durable state location, and next action. Keep approval, deployment, and verification as separate states. Add stable identifiers before adding more automation. Then test the receipt on both the happy path and the safe-stop path.

The next time a workflow is described as shipped, the operator should be able to answer three questions quickly: what changed, where is it, and what remains unverified? If the receipt can answer those questions, the system is not merely busy—it is inspectable.