Every team building agents eventually has the same argument. One side wants approval steps everywhere. The other says that defeats the point of automation. Both are half right, and the argument is usually settled by whoever is loudest rather than by any principle.

There is a principle. It is not about trust, it is about reversibility.

The Only Question That Matters

For any action your agent can take, ask: how expensive is it to undo? Not how likely is it to be wrong. How expensive to undo.

Reading a database row is free to undo, because nothing happened. Drafting an email is nearly free. Sending that email to two thousand customers is not undoable at any price. Notice that the model accuracy did not enter the calculation once.

A Four-Tier Model You Can Actually Apply

Most teams over-control tier one and under-control tier three. They make an analyst approve every database read, then let the agent email customers unsupervised because that part felt like a feature.

The Protocol Finally Supports This Properly

Approval used to be awkward to build. A server needing input mid-task had to hold a stream open, which meant infrastructure complexity most teams skipped.

Multi Round-Trip Requests in the current MCP spec fixed that. The server returns an input_required result describing exactly what it needs, the client collects the answer, and the original call is retried with the response attached. No held-open connection, no session to preserve. One platform team described exactly this use: confirming the cost of a new project before creating it, or warning before a query that would delete data.

The takeaway for architects is that a confirmation step is now a cheap design decision rather than an infrastructure project. There is no longer a technical excuse for skipping it.

How to Design a Checkpoint People Read

Here is the failure everyone eventually meets. You add approvals, people approve everything within a week, and you have built a rubber stamp with extra latency.

• Show the diff, not the intent. Do not say the agent will update the customer record. Show the old value and the new value.
• Make the risky option the slow one. Approving a refund of ten pounds and ten thousand pounds should not feel identical.
• Batch the boring, isolate the scary. Twenty routine updates in one review. One irreversible action on its own screen.
• Give a reject reason field. Rejections are your best training data and most teams throw them away.
• Track approval time. When median approval drops under three seconds, your checkpoint has become decoration.

When to Remove a Checkpoint

Checkpoints should expire. Pick a threshold before you launch: after the agent handles two hundred cases of this type with under a two percent rejection rate, the approval moves from before the action to a sampled review after it.

Write that rule down at the start. Otherwise approvals become permanent furniture, everyone works around them, and the automation you paid for never arrives.

Conclusion

Put your checkpoints where reversal is expensive, not where you feel nervous. Show diffs rather than intentions, keep the scary actions visually separate from the routine ones, and set a numeric threshold for removing each gate before you ever ship it. An agent with three well-placed approvals is more useful, and considerably safer, than one with thirty that everybody clicks through on autopilot.

Frequently Asked Questions

Does human review defeat the purpose of automation?

Only if you review everything. The value is in the agent doing the work, not in it acting unsupervised. Reviewing a proposed action takes seconds. Producing it took minutes.

Who should approve, the expert or the operator?

Whoever will carry the consequence. If a mistake lands in the support queue, support should hold the button, not engineering.

How do I stop approval fatigue?

Reduce the number of gates rather than making the interface prettier. Fatigue is a volume problem. If people are approving fifty things a day, your tiering is wrong.