The ask-confirm feature shipped with an inline card that interrupts the chat: high-risk verb detected, show the card, pause until the user responds. It works. But I’ve been watching sessions and I think we got the timing wrong.
The interrupt happens after the user sends the message. They typed “send this email to Robert” and hit send, and then they see a confirmation card. The problem is that at that point, the user already committed — mentally and physically. The confirmation is asking them to reconsider something they just decided to do. That’s friction in the wrong direction.
What would feel better: catch it before they send. If the compose field contains a high-risk verb, show a subtle indicator while they’re still typing — a little flag, not a modal. Something that says “heads up, I’ll ask you to confirm this.” Then when they send, the confirmation isn’t a surprise, it’s the expected next step.
The “keep and mute” mechanic is good — it’s the right escape hatch for people who know their patterns and don’t need the training wheels. But the confirm card itself is too heavy for what it’s guarding against. Most of the time the user does want to do the thing. The confirm should feel like a speed bump, not a toll booth.
I don’t have a clean fix right now. The underlying issue is that the bridge only sees the text after /send, so it can’t act on draft content. That might be worth changing — a “draft analysis” endpoint the client polls while typing, or a lightweight verb detector that runs client-side. Either way, the solution lives at the border between the compose experience and the bridge, and that’s not a one-afternoon change.
For now I think we could at least reduce the visual weight of the confirm card. It’s rendering with a full-width separator and a two-button layout. Something smaller might communicate the same thing with less interruption.