An approval step is the least impressive thing you can put in a demo. It is also the only part of an agent that is load-bearing when the model is wrong.
Key takeaways. The costs of a wrong read and a wrong send are not symmetrical, so they should not have the same policy. Draw the line at recoverability, not at importance — importance is a judgment the runtime cannot make. A product that asks about everything trains people to approve without reading. Enforce the boundary in the runtime, not the prompt. A rule a model can be talked out of is not a rule.
The asymmetry. An agent with unsupervised write access to an inbox is a category of risk that most of this market is quiet about, and the reason is straightforward: confirmation is friction, and friction does not demo well. The version where the agent handles it end to end is a better thirty-second video. The argument for asking anyway is that the costs are not symmetrical. Reading a thread wrongly costs you nothing — you notice, you correct, nobody else was involved. Sending one wrongly can cost you a relationship, and there is no undo. Same model, same confidence, wildly different downside. Anything with that shape wants a different policy on each side, and the interesting engineering question is where exactly to put the divide.
Recoverability beats importance. The obvious answer is to gate the important actions. It does not survive contact with implementation, because importance is contextual and the runtime cannot see the context. Deleting a task is trivial on Tuesday and expensive on Friday, and no classifier is going to know which day it is looking at. Recoverability is a property of the action itself, which makes it something a policy can actually evaluate. Can this be undone by the person, in their own account, in a minute? Then run it. Has it reached another person, or is the thing it changed gone? Then stop and ask. That produces a boundary you can state in one sentence and check against the code. Drift stops and asks before anything reaches another person, and before it deletes something. Everything else — reading, and work inside your own account that you can undo — runs without interrupting you.
Asking about everything is its own failure. The mirror-image mistake is to confirm every action. It looks maximally safe and it is not, because approval fatigue is real and fast. A card that appears forty times a day gets dismissed forty times a day, and by the second week it is being cleared without being read. At that point the confirmation step has become worse than useless: it has moved the responsibility onto the person while removing their attention, and it has done so with the ceremony of a safety feature. So the list of things Drift does not ask about is as deliberate as the list of things it does. Reading anything, including searching twelve months of mail history. Reading changes nothing. Saving a draft in your own mailbox. Nobody has seen it. Creating or completing a task, creating or editing a Notion page. Undo is one action away.
What the card has to show. A confirmation is only as good as what it puts in front of you, and the tempting shortcut is to summarise. "Send reply to Priya?" fits on a line and tells you almost nothing. A confirmation card states the exact external effect before you approve it. For a message that means every recipient and the body text, not just the subject line — approving a subject is not consent to words you have never read. An unanswered card expires, and nothing happens. Declining also needs to be a real outcome rather than an error state. Drift is told that a person chose not to allow the action, so it acknowledges the choice and moves on instead of retrying with a rephrase; decline the same action twice and it stops proposing it in that conversation. An agent that treats no as an obstacle is an agent you will stop reading carefully.
Enforce it below the model. The most important implementation detail: a boundary that lives in a system prompt is not a boundary. Prompts are negotiable, and the negotiation does not have to be adversarial — a long enough conversation with a helpful enough model will find its way around a rule that only exists as a sentence. So the classification of which actions require approval sits in the runtime, beside the code that executes tools, and applies regardless of what the conversation has convinced the model of. There is no per-account setting that turns it off, because a setting is another thing that can be wrong. There is one documented exception, and it is worth stating rather than hiding, because a clean rule with a silent exception is a rule that gets caught. Calendar writes are the one exception, and they include deletes. They run inline, with no confirmation card. An earlier build did ask, by pausing the turn and resuming it after approval — and because each resume was a fresh model turn, the same event was created over and over until the turn hit its tool limit. Running calendar writes in the same turn as the reads is what stopped that. It is the one place the rule bends, and it is a deliberate trade, not an oversight.
No. Sending, replying and forwarding are classified as actions that reach another person, and each one stops on a confirmation card first. There is no setting that turns this off, because the rule is enforced in the runtime rather than configured per account.
A confirmation card states the exact external effect before you approve it. For a message that means every recipient and the body text, not just the subject line — approving a subject is not consent to words you have never read. An unanswered card expires, and nothing happens.
Declining is a decision, not an error. Drift is told a person chose not to allow the action, so it acknowledges the choice and moves on rather than retrying. Decline the same action twice and it will not be proposed again in that conversation.