Consider a synthetic request: “Move two nights from Tokyo to Kyoto.”
Inside a travel product, it can describe several very different actions. The assistant might explain the tradeoff, show a proposed route, create a separate candidate trip, or rewrite the itinerary the traveler is already using.
Those outcomes should not share one permission policy merely because they begin with the same sentence.
A useful agent distinguishes advice, preview, confirmation, and execution.
Advice has the smallest blast radius
An advice-only workflow reads authorized context and returns a recommendation. It does not change the trip.
This is appropriate for questions such as whether a day looks crowded, which neighborhood better fits the itinerary, or what might be missing before departure. The assistant can explain evidence and tradeoffs while leaving the traveler in control.
Read-only does not mean unrestricted. The system still needs to verify that the requester may see the trip, collection, or agency workspace. It should load only the context required for the question and avoid exposing private notes, bookings, collaborators, or unrelated memory.
Advice is safer because its consequences are reversible: the traveler can ignore it. That makes it a good default when intent is ambiguous.
A preview turns language into a candidate
Some requests are easier to evaluate when the traveler can see the proposed result.
A route revision may change overnight bases, transport legs, and several days at once. Explaining those changes in chat is less useful than building a candidate that shows what the new trip would contain.
The preview should remain separate from the live object. Planning can fail, be cancelled, or become stale without damaging the existing itinerary. The candidate can carry a summary of preserved and changed content, unresolved concerns, and the action required to continue.
This boundary also protects the assistant from accidental authority. Producing a good candidate does not mean the model has permission to apply it.
Confirmation must identify a specific change
“Yes” is not a durable authorization contract by itself.
A confirmation should be tied to the acting user, the exact candidate, the object being changed, and the current version of that object. If the traveler edits the trip after the preview was prepared, the confirmation should become stale rather than overwrite newer work.
The interface should state what will happen in ordinary language. “Replace current trip” and “Keep as a separate version” communicate different consequences. A generic “Continue” button does not.
High-impact actions deserve a structured confirmation control rather than an intent inferred from free-form prose. Natural language can initiate the proposal; the explicit action authorizes execution.
Execution returns to deterministic authority
The model may help decide what to change. Backend policy decides whether the change is allowed.
Immediately before execution, the system should recheck:
- The current user's identity and role
- The target trip or collection
- The candidate's status and expiration
- The expected graph or revision version
- Protected bookings, purchases, or collaboration rules
- The exact mutation scope
- Whether the operation already completed
These checks must occur at execution time, not only when the preview was created. Access and state can change while the traveler is reviewing a proposal.
An atomic operation should either apply the complete authorized change or leave the original object intact. A partial graph rewrite is much harder to recover from than a rejected stale candidate.
Different actions need different policies
A practical agent registry can describe capabilities by their effect.
Read-only tools inspect and explain. They require read access and bounded context.
Low-impact writes make narrow, reversible changes such as updating one editable note. They still require write access and scope validation.
Previewed writes prepare a candidate without changing live state. They separate planning quality from mutation authority.
High-impact writes replace routes, remove content, alter access, publish material, or affect bookings and commerce. They require explicit confirmation and final revalidation.
This classification is more durable than maintaining a loose list of phrases that sound dangerous. New tools inherit a policy based on what they can do.
Retries should not repeat the consequence
Networks retry. People double-click. Browsers refresh. Background workers can deliver results late.
A safe execution path uses an idempotency identity so repeated requests converge on one outcome. If the first operation succeeded but its response was lost, the second request should report the completed result rather than apply the mutation again.
Cancellation needs the same rigor. Once a candidate is cancelled, a late worker should not revive it. Once a newer candidate supersedes an older one, the old confirmation should no longer be valid.
These rules are not visible when everything goes well. They become the difference between a calm recovery and a duplicated or damaged trip when something goes wrong.
Test the denied paths
Action tests should cover more than successful execution.
A useful suite verifies that:
- A viewer can receive permitted advice but cannot mutate the trip.
- A candidate never changes live state before confirmation.
- Confirmation from another user is rejected.
- A stale graph or expired candidate cannot execute.
- A protected trip uses copy-only behavior where replacement is not allowed.
- A repeated confirmation returns the original completed result.
- Cancellation blocks a late write.
- A model-supplied identifier cannot select an unauthorized object.
- Failure leaves the original graph intact.
The model response is only one input to these tests. The final assertion belongs to the state of the product.
The durable lesson
Agentic software becomes more useful when it can act, but usefulness does not require treating every request as immediate permission.
Advice helps the traveler think. A preview makes consequences inspectable. Confirmation records a deliberate choice. Deterministic execution enforces authority against current state.
That progression allows an AI assistant to do meaningful work without making fluency a substitute for consent.
Loading comments...