A reply prompt should name the intended audience and disclosure scope before it generates a polished message. The original thread may include observers, external vendors, hidden recipients, or an address that now routes elsewhere. Do not infer that reply-all is appropriate merely because an address appeared in a prior message. Resolve each recipient through trusted mailbox or directory data, flag external domains, and state whether the reply should remain in the same thread. Bcc recipients are a separate disclosure decision; a model should not silently add or expose them. A draft can be prepared for review, while sending requires current user authority and a checked recipient set.
Email prompts: review To, Cc, Bcc, and reply scope
Operational case
The Aster discussion includes the program owner, one vendor coordinator, and a broad legacy distribution list. The requested meeting reply is intended for the owner and coordinator only. A reply-all would reveal the pilot timing to the legacy list. The assistant proposes those two explicit recipients, keeps the thread relationship, and leaves the list out. A quoted address in the message body is not automatically a recipient. Before sending, the user sees the To and Cc fields as well as the exact body.
To: verified program owner and vendor coordinator.
Cc: none; legacy distribution list excluded.
Bcc: none unless separately requested and reviewed.
Thread: reply to M-52, preserve conversation identity.
Send: only after current user reviews recipients and body.Performance and operating cost
Resolving R recipient IDs is O(R) with indexed directory lookups. The preview step adds a human decision, but prevents accidental disclosure to a large group. A long thread may contain many stale addresses, so derive recipients from the current task rather than copying every header. Record the reviewed recipient set with the draft version; a later body edit should not silently expand the audience.
Common Mistakes
- Do not use reply-all by default.
- Do not copy addresses from quoted text into recipient fields.
- Do not add Bcc recipients without an explicit disclosure decision.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Sensitive output gates: check the rendered answer before release
- Browser forms: treat preview, submit, and server validation separately
- Incident updates: audience, owner, and release gate
- Email prompts: reconstruct the thread before drafting
- Email prompts: keep sender identity and message text separate
- Email prompts: verify attachment version and coverage
- Email prompts: separate drafted commitments from sent messages
- Calendar prompts: resolve availability, zone, and duration
- Calendar prompts: distinguish create, update, and cancellation
- Calendar prompts: scope recurrence changes to the right instances
- Project: review an Aster vendor reply and invite
- Email and calendar prompt decisions
