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.
The shortcut that failed: one voice profile
I initially treated voice and identity as one global profile, with channel detection layered on top. It seemed efficient.
Testing a reply involving LinkedIn exposed the flaw: the X/NAFO tone leaked into a professional reply, and recipient identity could be confused — producing replies like “Thanks Igor!” to someone else.
I changed the design so each channel has its own identity and tone profile. Personal examples stay with their user. Recipient names must come from the current post, comment, or conversation. An empty profile uses a neutral fallback instead of silently borrowing another channel’s voice.
The lesson I took from it: identity and tone are product data, not just prompt instructions.
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?
I used AI assistance to organize and edit this article; I checked the facts. The design example comes from my own experience.
The extension I built from this work is Riffwise. It drafts from the conversation you choose; you review it, and nothing is sent automatically. The selected context goes to Riffwise and OpenAI.
Top comments (0)