The edit can be finished before it is accepted
Ask an agent to rewrite a paragraph. It can read the document, reorganize the section, and produce a complete replacement. If the interface presents that result as tracked changes or a diff, one thing is still unresolved: which version is the document?
That is the boundary I care about.
The agent can have permission to derive a new version without having permission to make that version authoritative. I find it useful to separate those two powers:
- Derivation authority: the agent may compute and propose a change.
- Transition authority: the user decides whether that proposed change becomes the accepted state.
The distinction sounds abstract until it is attached to one ordinary edit. The original paragraph is the baseline. The rewritten paragraph is a proposed delta. The diff is the review object. Acceptance is the moment the proposal crosses into the document the system should now treat as authoritative.
accepted baseline
→ proposed delta
→ inspectable review object
→ accept / reject / narrow
→ authoritative new state
The work can be complete before that final transition happens. That matters because generation capability and mutation authority are different product decisions, even when the interface currently makes them look like one operation.
The diff is the thing being authorized
A visible diff is useful for more than showing what the model did. At its best, it is the exact object the user is being asked to authorize.
That makes “human approved” a much more demanding statement than it first appears. Approved what? Against which baseline? Was the proposal still current when approval happened? Could the user reject one part without losing the rest?
The review surface is strongest when those answers stay attached to the proposal itself. It needs a known baseline, the exact proposed change, enough surrounding context to understand the effect, a clear accept/reject path, and some way to know whether the underlying object has changed since the proposal was generated. Recovery or undo helps where the object permits it, but reversibility should not be assumed just because a diff was visible.
Current Anthropic products make the interaction pattern concrete. Claude for Microsoft 365 describes Word edits through tracked changes that remain reviewable before the user allows them to be saved or sent. Claude Code onboarding describes visible file-edit diffs with explicit approval or rejection, while the Claude Code cheatsheet also documents an Accept Edits mode that can auto-approve file edits for the rest of a session.
Those are concrete product examples, not evidence that the industry has standardized one approval model. The useful point is smaller: the authority mode can be visible in the interaction instead of disappearing inside the fact that an agent is capable of editing.
Approval should expire when the proposal changes
Suppose an agent proposes an edit against version A of a document. The user inspects that diff and approves it. Before the change is applied, another person or process modifies the document and produces version B.
The earlier approval no longer cleanly describes what will happen next.
The user reviewed a transition from A to A-plus-delta. Silently rebasing the old proposal onto B may create a different result. If the underlying object has changed materially, the proposal should become stale and be refreshed or regenerated before the system treats approval as valid.
This is easy to hide in the interface because version binding can be an implementation detail, but it should not be an authority detail. The product does not need to show a hash to every user, but it does need to know whether the thing about to be applied is still the thing that was reviewed.
Otherwise the veto is attached to a memory of the proposal rather than the current proposal itself.
A veto can exist and still be useless
A reject button is not automatically meaningful control.
If one proposal bundles ten edits and the interface only offers “accept all” or “reject all,” a user may have to throw away nine good changes to avoid one bad one. The veto is technically present, but it is expensive enough that people will eventually stop using it carefully.
Approval granularity therefore has to match the work object closely enough that judgment remains practical. A document may support section-level or individual tracked-change acceptance. Code may support file or hunk review. Structured configuration may support field-level comparison. A plan may allow particular actions to be accepted while others remain proposed.
More controls are not automatically better. A boundary that is too coarse bundles consent. A boundary that is too fine turns the user into a mechanical checker.
The product problem is to keep the veto near the unit where mistakes actually matter.
Review fatigue is the strongest objection
Per-change approval can erase the productivity gain that made the agent useful in the first place.
If every punctuation fix, formatting cleanup, renamed variable, or low-risk rewrite demands a separate decision, the user becomes a queue processor. The model gets faster and the person gets a larger inbox.
I do not think the answer is to pretend the authority boundary disappeared, but to move it deliberately.
Low-risk changes can be batched. Mechanical changes can be separated from semantic ones. A user can choose scoped auto-approval for a bounded area, promote a trusted session into a more permissive mode, reserve explicit review for ambiguous or consequential changes, or rely more heavily on strong undo when the action is genuinely reversible.
Claude Code’s Accept Edits mode is useful as an example because the mode shift is explicit. Per-change approval and auto-approval are not the same trust contract with fewer clicks. They put transition authority in different places.
Auto-approve is not inherently wrong. It should simply be treated as a different authority mode, with scope and recovery made clear enough that the user understands what changed.
A diff is only one kind of proposal
Tracked changes work unusually well because editable text has a legible before-and-after state. That makes it tempting to turn the diff into a universal agent-safety metaphor. It is not one.
Some consequential actions do not have a useful text-diff representation. Drafting an email can be reviewed as text, but sending it crosses an external boundary. A command can be previewed, but its effects may extend beyond the command string. A database mutation can be expressed as a query while still having downstream consequences that are not obvious from the text alone.
Those actions need other review envelopes: a dry run, a transaction preview, a staged commit, an execution plan bound to exact inputs, a one-action permission request, a sandbox result, a reversible checkpoint, or a confirmation surface that names the affected resources.
The implementation changes with the action, while the underlying contract can stay recognizable: keep the consequential state transition provisional until the appropriate authority crosses a visible boundary.
A diff is one particularly good version of that contract for editable text.
The proposal becomes part of the product state
Once an edit is treated as a proposal instead of an immediate mutation, the proposal has a lifecycle of its own. It can be generated, rendered, reviewed, partially accepted, rejected, revised, invalidated as stale, superseded, applied, or undone where undo is actually available.
That lifecycle is not review chrome; it is product state.
The interface should make it possible to tell what is authoritative now, what is merely proposed, whether the proposal is still current, what acceptance will change, and whether the acceptance is total or partial. If any of those answers are ambiguous, “human in the loop” can become a label over a control surface that does not give the human a useful object to control.
This also changes how I think about autonomy. An agent can be highly autonomous in producing a proposed result while remaining deliberately constrained at the point where that result becomes authoritative. The human does not have to supervise every intermediate step for the final transition to remain theirs.
A proposal boundary does not make bad edits good. It does not replace permissions, evaluation, sandboxing, or recovery. It does not mean every change deserves manual approval forever.
The generated edit can be complete and still not be the accepted state.
// End of transmission. Keep proposal state and final authority separate — ZYANE