While building an AI reply workflow, I kept coming back to a question beyond whether a model could write a sentence: what should a writing assistant be allowed to see and do?
A reply assistant sits close to somebody else’s words. That makes its trust boundary a product decision, not a footnote.
1. Make the request explicit
The user should start a reply or quote-draft action. Read only the relevant post or email context for that request. If a cloud model generates the draft, explain what text or media is sent and who receives it before use.
A useful test: after a quick look at the screen, can a new user say what context is sent, who receives it, and why? If not, the interface needs to explain it more clearly.
2. Keep “draft” separate from “send”
Return words for the person to review. Editing, inserting, copying, or ignoring a draft are different from publishing it; the person decides whether and when to post or send. Inserting text into a composer is not the same as publishing it, and the interface should make that distinction obvious.
A generated reply is a suggestion, not an action taken on someone’s behalf.
3. Give people controls that change the result
Tone, length, language, and personal writing instructions can be more useful than a dozen novelty modes. They let a person shape a draft while making the limits visible: a model can help with a first pass, but the person still owns the words.
4. Be candid about the tradeoff
Human review does not make a cloud tool private by magic. If a service receives writing context or attached media to generate a draft, say so plainly. If someone would not be comfortable sending a conversation for processing, they should not use that workflow for that conversation.
I’m still working through these design questions. If you build browser tools or AI features, where do you draw the line between helpful context and too much access?
Disclosure: I used AI assistance to prepare this article and reviewed the final text.
Top comments (0)