# 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.

Version 1.0 · 2026-07-29 · 8 min

## 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

- A generated proposal is not an executed action.
- Confirmation must show what will change and trigger a fresh server-side check.
- Recovery and trace are part of the workflow, not operational afterthoughts.

## 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.

## A controlled action contract

Every action path needs an explicit state machine that the model cannot skip.

### 1. Resolve

Gather the current user, record, rule and evidence. Stop if essential context is absent.

### 2. Propose

Create a typed pending action with the target, parameters, rationale and expected effect. Do not claim completion.

### 3. Preview

Show editable values, evidence and consequences in the product interface. Keep cancel and recovery obvious.

### 4. Confirm

Collect an explicit user decision for consequential work. The checkpoint should belong to the host product, not only the conversation.

### 5. Revalidate and execute

Check identity, permissions, current state and invariants again. Reject stale or no-longer-valid proposals.

### 6. Trace and recover

Record proposed, confirmed, rejected, completed and failed as separate states. Provide the next safe step after failure.

## Examples

### 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.

## Checklist

1. Action levels are named and documented.
2. Pending actions use a typed schema.
3. The preview shows target, values, evidence and expected effect.
4. Consequential work requires explicit confirmation.
5. The server revalidates identity, permissions and state.
6. Idempotency or duplicate protection exists where needed.
7. Rejected, failed and partial outcomes have a recovery path.

## Limitations

- 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

1. [Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — NIST, 2023; type: standard.
2. [τ-bench: Tool-Agent-User Interaction in Real-World Domains](https://openreview.net/forum?id=roNSXZpUDN) — Yao et al., 2025; type: research.
3. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25) — MCP maintainers, 2025-11-25; type: standard.
4. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; type: research.

## 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.

---

Canonical: https://scoperail.fokalabs.io/en/guides/automate-without-removing-the-decision
Author: Ramzi Laieb, FokaLabs