An AI Agent Should Show Its Changes Before Publishing

An AI agent should put the proposed result in front of the person authorizing publication, then publish the version that was reviewed. The important detail is the connection between those two moments. If the agent changes the contents, destination or audience after review, the earlier approval may no longer cover the action, and “you approved it” becomes true of a document nobody has seen.

This is a release decision for publishers and founders, not a demand to interrupt every edit. Existing authorization can cover routine work within a defined scope. When approval is required, make it concrete: identify the candidate, expose the changes that matter and state where the result will appear. This guide sets out the six fields of a review packet, how to pin the review to a version, what a visual preview hides, when an approval has gone stale, the ways an approval ends up not covering what ran, and how to close the loop with evidence from the destination.

In a chat, approval feels like a moment: the owner says yes, the agent proceeds. But the thing being approved is a specific state of a specific artifact, headed for a specific place and audience. If any of those four moves between the yes and the publish, the yes no longer refers to what happens. The agent did not disobey; it published something the approval never described.

The fix is to make approval refer to things the agent can check at publish time. A revision identifier, a destination, an audience and a list of permitted edits are all comparable to the state of the world a minute before release. “Looks good, go ahead” is not. The review packet below is a way of forcing the approval into a form the final action can be compared against.

A review packet is the small set of material needed to authorize release. The table gives six fields worth keeping together. It is an editorial decision aid, not a prescribed approval system. A short revision can fit in a few lines; a complex release may need linked evidence, but the approval should still identify a single candidate.

The right-hand column is the condition under which each field should be looked at again. Approval is not a one-time event followed by a free hand; it is a record that stays valid only while the fields it describes stay true.

Git’s diff documentation describes comparisons between working files, staged content and committed trees. The comparison must name the relevant endpoints. Looking at unstaged edits alone can miss content already staged for the candidate, so “show me the diff” is not a complete instruction; “show me the diff between the last published commit and the candidate commit” is.

RFC 9110, section 13.1.1 defines If-Match for conditional requests, including avoiding accidental overwrites when a representation has changed. Where supported, a revision check can guard the write boundary. It is a concurrency mechanism, not proof that a human approved the proposed content: it can stop the agent from overwriting someone else’s edit, and it says nothing about whether the content it protects was ever reviewed.

Put the two together and the approval has an anchor at each end. The diff names what was reviewed; the conditional write refuses to land on a destination that has moved. Neither alone is the control.

Consider a hypothetical announcement whose visible body looks correct. The candidate also changes a download link and makes the page available to everyone instead of a named review group. A screenshot of the body can leave both differences unclear. The reviewer needs the destination and access change alongside the visual candidate, because those are changes a visual preview can easily leave out.

Show removals as well as additions. A shorter draft may omit a limitation the owner relied on, even if every remaining sentence is accurate. For a factual update, use the fact-preservation guide to trace dependent claims before assembling the review packet, so that the “meaningful difference” row lists the chart and the summary as well as the sentence that changed.

Summarize consequential differences in plain language and link the exact comparison. Highlight changed promises, access and side effects so the publisher can assess them without interpreting filenames. The summary is for the decision; the linked diff is for anyone who wants to check the summary.

Suppose an owner approves candidate A for a public page. The agent then fixes a typo within an explicitly allowed editorial scope. That may remain covered. If it also changes a price, removes a qualification or adds an email announcement, those actions require checking the approval’s scope. The relevant distinction is what was authorized, not whether the agent calls the change small.

When scope is unclear, keep the prepared result reviewable and ask about the specific difference. Do not discard useful completed work merely because release needs another decision. Our ask-instead-of-guessing guide covers that threshold, and the question should name the exact change: “the approved candidate did not include the price change on line 12; publish without it, or re-approve with it?”

For a changing destination, identify both the candidate revision and the destination revision against which the update was prepared. If another editor changes the destination, compare the new state before overwriting it. A candidate can be unchanged while the proposed update is no longer the same operation.

In each illustrative case below, the owner said yes, the agent published, and the owner was right to be surprised. None involves the agent ignoring an instruction. Each involves the approval and the action referring to different things.

The moving candidate: approval was given on the preview, the agent kept editing for twenty minutes, and the version that went live had a paragraph nobody reviewed. The quiet widening: the page was approved for a review group, and the publish step defaulted the visibility to public. The bundled broadcast: approving the post also fired the newsletter, because the two were wired together and the packet had no side-effects row. The overwritten colleague: between approval and publish another editor fixed the live page, and the agent’s write replaced their fix with the approved candidate, which no longer had it.

Candidate, audience, side effects, destination revision. The packet has a row for each, and the one-second-before-publish check in the first section is simply reading those rows back against the world.

After the authorized action, record what actually happened: published candidate, destination and a check from the intended audience. If the action only saved a draft, report that state. The delivery-state reference supplies precise language for preparation, storage, dispatch and access, and the right word matters: “published” and “saved as draft” are different states that an agent’s summary can collapse into “done”.

A failed status lookup should not trigger a second publication automatically. Keep the operation reference and inspect the destination. The review packet authorizes an action under specified conditions; it does not establish whether an uncertain attempt completed. The same unknown-outcome discipline that governs a lost form response governs a lost publish response, and the same instinct, to try again, produces the same duplicate.

Where the approved content is itself a recorded decision, our guide to keeping decisions separate from ideas covers how the record reaches the packet with its status intact. Teams that want approval pinned to a version and checked at publish time inside their own publishing workflow can do that with our AI transformation practice.