Automate the work. Keep the decision.
Separate answers, guidance, proposals and execution. Give people a useful preview, a real checkpoint and a reliable recovery path.
Short answer
Automation is safest when the system prepares work before it performs consequential work. Define four levels: answer, guide, prepare and execute. A proposal should contain the intended change, evidence, editable fields and expected effect. The host application then checks permissions and invariants again when the user confirms. Low-risk reversible actions can be delegated deliberately. Ambiguous, irreversible or high-impact actions keep a human checkpoint and a visible recovery path.
Key points
- 01
A generated proposal is not an executed action.
- 02
Confirmation must show what will change and trigger a fresh server-side check.
- 03
Recovery and trace are part of the workflow, not operational afterthoughts.
01 / SITUATION
Most useful automation lives between suggestion and execution
Teams lose time collecting details, checking rules, copying values and preparing the same handoff. Those steps are strong candidates for assistance because they reduce repetitive work without hiding the final decision.
The risk begins when a fluent response is treated as authority. A model can select the wrong tool, misunderstand an exception or act on stale state. The product should therefore make the boundary between preparation and execution visible in both the interface and the backend.
02 / MECHANISM
A controlled action contract
Every action path needs an explicit state machine that the model cannot skip.
- 01Resolve
Gather the current user, record, rule and evidence. Stop if essential context is absent.
- 02Propose
Create a typed pending action with the target, parameters, rationale and expected effect. Do not claim completion.
- 03Preview
Show editable values, evidence and consequences in the product interface. Keep cancel and recovery obvious.
- 04Confirm
Collect an explicit user decision for consequential work. The checkpoint should belong to the host product, not only the conversation.
- 05Revalidate and execute
Check identity, permissions, current state and invariants again. Reject stale or no-longer-valid proposals.
- 06Trace and recover
Record proposed, confirmed, rejected, completed and failed as separate states. Provide the next safe step after failure.
03 / In real work
Prepare a support ticket
The assistant collects context and proposes the ticket. The user edits and sends it. No external side effect occurs before confirmation.
Correct a record
The assistant identifies a missing field and prepares a correction. The product checks the latest record and write permission when the operator confirms.
Approve a request
The assistant can assemble evidence and open the approval screen. The authorised person still owns the decision.
Common failure modes
- Displaying a confirmation button without showing the exact change.
- Executing from a stale proposal without rechecking current state.
- Logging a proposal as completed before the tool returns success.
- Giving the model a broad credential that bypasses the user’s access boundary.
- Designing the happy path without a retry, cancel or escalation path.
Implementation checklist
- Action levels are named and documented.
- Pending actions use a typed schema.
- The preview shows target, values, evidence and expected effect.
- Consequential work requires explicit confirmation.
- The server revalidates identity, permissions and state.
- Idempotency or duplicate protection exists where needed.
- Rejected, failed and partial outcomes have a recovery path.
What this approach does not claim
- Human confirmation does not make an unsafe operation safe by itself.
- A reversible action may still have privacy, contractual or operational consequences.
- Benchmarks do not replace evaluations using the organisation’s own tools and policies.
Sources and reference types
- 01Artificial Intelligence Risk Management Framework 1.0NIST · 2023Standard
- 02τ-bench: Tool-Agent-User Interaction in Real-World DomainsYao et al. · 2025Research
- 03Model Context Protocol specificationMCP maintainers · 2025-11-25Standard
- 04AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Research
Practical questions
Should every action require confirmation?
No. Teams can deliberately delegate low-risk, reversible actions after evaluation. The classification and authority still belong to the product.
Can confirmation happen inside chat?
It can be displayed there, but the host application should own the final server action and permission check.
What should be logged?
Enough to distinguish request, evidence, proposal, confirmation, execution and outcome without copying unnecessary sensitive content.