Ask an AI assistant to tidy a project folder and the instruction sounds harmless. Yet “tidy” might mean renaming files, moving them, deleting apparent duplicates or changing who can see them. The useful result is not merely a cleaner folder. It is a cleaner folder in which nothing important has disappeared and nobody has acquired unintended access.
Once an assistant can act through software tools, a fluent interpretation becomes a change to the world. The practical question is how to inspect that change before it happens. An agent should be able to prepare an exact change preview, leave consequential actions unexecuted, and carry out only the approved version of the proposal.
This is not a call for a confirmation box before every click. It is a case for making the boundary between preparation and commitment real. The opportunity is substantial: people could delegate the labour of organising and preparing work without surrendering the decisions hidden inside it.
A plan is not a preview
“I will organise the documents by project” is a plan. “These six files will move from these locations to those locations; two ambiguous files will remain untouched; permissions and contents will not change” is closer to a preview. The difference is whether a person can inspect the particular objects and consequences rather than approve a general intention.
For a proposed message, the inspectable objects are the recipients, text and attachments. For a document edit, they are the exact changes and the version being edited. For file organisation, they are the source and destination of each move, any naming conflicts and the treatment of uncertain cases.
The preview should come from the same structured action record that execution will use. If the model writes a reassuring summary and later invents a fresh set of tool calls, approving the summary has not constrained the action. A proposed design would instead freeze the operation list, validate it, present it in readable form and bind approval to that list. Any material revision would require a new preview.
Alkemata has argued that a verifiable answer exposes something another person can check. Acting systems need a related but different object: a verifiable proposed change.
Why “undo” is not enough
Microsoft’s HAX guidance on efficient correction calls for making AI outputs easy to edit, refine or recover, including undoing automated actions. That is an important design goal. But recovery has boundaries.
Renaming a local file may be reversible if the system records its old name and nothing else has changed. Restoring an earlier document version may recover its contents while discarding someone’s later contribution. A correction email can explain a mistake, but it cannot make a recipient unread confidential information already delivered.
A useful preview would therefore state the recovery method and its limits. “Undo available” is too broad. Which state can be restored? For how long? Could anyone or any downstream process already have acted on the first result? These questions distinguish restoring data from repairing consequences.
For the folder example, a cautious first version might permit moves within a private working copy but prohibit deletion, external sharing and overwriting. This deliberately narrows what “tidy” can mean. It turns a vague promise of safety into a boundary that software can enforce.
The preview can become stale
Even an exact preview can be wrong by the time it is approved. A colleague may edit a document, a destination may acquire a file with the same name, or a permission may change while the person reviews the proposal. Checking yesterday’s state and executing against today’s state are not the same operation.
There is an established software mechanism for part of this problem. HTTP’s If-Match condition, specified in RFC 9110, can require a resource’s current entity tag—a representation identifier—to match the one supplied with a change request. It is used to prevent accidental overwrites when clients act in parallel. A failed condition means the requested change must not be performed.
An agent workflow can apply the same principle where its tools support it: execute only against the version that was reviewed. Otherwise stop, read the changed state and prepare a new proposal. A quick read immediately before a write is weaker than a server-enforced condition because another change can occur between them. Where the service offers no suitable safeguard, the interface should disclose that limitation rather than promise conflict-free execution.
Another failure is less visible. The tool may complete a request while its response is lost. Retrying blindly could repeat the effect. Amazon’s Builders’ Library explains idempotent requests: a client-supplied request identifier lets a supporting service recognise retries without producing additional side effects. This is duplicate-request protection, not undo, and it depends on the service’s actual contract. An agent cannot create that guarantee simply by announcing that it will act once.
The proposed change record should preserve request identifiers and outcomes so the system can reconcile uncertain results. A batch that partly succeeds must report the completed operations separately from those still pending. “Something went wrong” is not enough information to decide what may safely be retried.
Review is work too
The strongest objection is that previews could make delegation pointless. If someone must inspect hundreds of low-level operations, the assistant has merely converted execution work into review work. Worse, an impressive-looking preview can invite approval without understanding.
The answer is proportionate delegation. A person might authorise a bounded class of routine changes in advance while reserving exceptions for review. The system could group identical operations, highlight deviations and show exclusions explicitly, while keeping the full record available. The boundary should depend on consequences and authority, not just a model’s confidence.
Anthropic’s December 2024 engineering account of agents recommends environmental feedback, checkpoints and sandbox testing, while warning about compounding errors. Those are engineering practices, not proof that a particular agent is dependable. They support testing a bounded workflow before granting broader powers.
People must also be able to understand the preview. A raw technical log is not an adequate interface for everyone. Plain-language descriptions, accessible comparisons and a genuine way to reject or narrow the proposal are part of the design. The person requesting a change may not have authority over every affected file or colleague; approval cannot supply missing rights.
Try a change-preview rehearsal
A small experiment needs no real inbox or live shared drive. Create a private test folder containing ten invented documents, including similar filenames, an apparent duplicate with different contents and one deliberately ambiguous item. Keep an untouched copy outside the agent’s permitted workspace. Do not use personal or confidential material.
Ask the assistant to propose an organisation, without making changes. Require a source-to-destination list, explicit exclusions and a recovery explanation. Resolve any consequential ambiguity first, using the selective approach explored in Alkemata’s article on clarification. Then permit only the agreed operations inside the disposable workspace.
Compare the observed result with the preview. Did any unlisted item change? Did an uncertain file remain untouched? Can the recorded moves be reversed without overwriting anything? In a separate run, alter one test document after the preview and check whether the workflow detects the stale proposal. If the tool cannot enforce the boundary, record that as a failed capability, not as a prompt-writing problem.
This rehearsal does not certify an agent for financial transactions, publication or confidential communications. It establishes something narrower and useful: whether a particular toolchain can keep a promise about a bounded change. Start there. Before delegating more authority, ask it to make the next action inspectable—and show that execution respects what was inspected.
Author
What did this make you think?
Choose a reaction or write a comment. Comments are reviewed before publication.