# An AI Agent Should Show Its Changes Before Publishing > Source: > Published: 2026-09-07 00:00:00+00:00 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. 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. 1. 01Approve a candidate.Name the version and destination rather than asking for a general yes. 2. 02Show meaningful changes.Include omissions, link changes and audience changes that a visual preview may hide. 3. 03Recheck what moved.Changes after review need a scope check before the approved action runs. ## 01 — Make the publication decision inspectableMake the publication decision inspectable 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. | Original editorial decision aid; examples describe proposed checks, not measured outcomes. Reviewed September 7, 2026. | | | |---|---|---| | Review field | What to show | When to revisit | |---|---|---| | Candidate | Exact document, build or revision under review. | Reconfirm if the proposed content changes outside approved scope. | | Meaningful difference | Added, removed and altered claims, links and behavior. | Expose changes that are not obvious in the preview. | | Destination | Named page, account, folder or publication surface. | A different destination can require a different decision. | | Audience | People or roles able to access the result. | Broader access must fit the authorization. | | Side effects | Notifications, sends or other actions coupled to release. | Do not treat page approval as approval for every distribution action. | | Approval conditions | Owner, candidate, allowed edits and stopping conditions. | Compare the final action against this record before release. | ## 02 — Connect the review to a versionConnect the review to a version [Git’s diff documentation](https://git-scm.com/docs/git-diff) 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. [RFC 9110, section 13.1.1](https://www.rfc-editor.org/rfc/rfc9110.html#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. The practical rule here is our interpretation: retain both the reviewed candidate and the conditions of approval. A system without revision preconditions may need an application-level check. Do not imply that adding a confirmation sentence to a prompt creates an enforced publication control. ## 03 — Show what a preview leaves outShow what a preview leaves out 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. 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](/blog/ai-content-update-fact-preservation) to trace dependent claims before assembling the review packet. Keep the packet readable. Explain the consequential differences in plain language, then link the exact comparison for inspection. A list of filenames is insufficient when the reader’s decision concerns a promise, an audience or an external side effect. ## 04 — Decide when approval needs another lookDecide when approval needs another look 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](/blog/ai-agent-ask-instead-of-guessing) covers that threshold. 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. ## 05 — Close the loop with release evidenceClose the loop with release evidence 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](/blog/ai-agent-delivery-states-reference) supplies precise language for preparation, storage, dispatch and access. 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. Retain the approval and outcome together so the next editor can distinguish what was proposed, what was authorized and what appeared. This makes a later correction easier to scope without turning every minor edit into a new approval ritual. ## 06 — DecisionWhat to do next ### Make approval refer to the action that will run. Show the candidate and its consequential differences, retain the scope of approval and check the final version against it. Then report the observed release outcome. For implementation support, explore our [AI transformation services](/services/ai-transformation).