Start with goal, audience, and tone

An empty compose window makes AI tempting. You type “Write an email asking for the report,” receive a polished paragraph, and feel that the hard part is done. But polished language can hide unresolved decisions. Which report? Why do you need it? Who is receiving the request? When is it actually due? Is the recipient responsible for producing it, or are they helping as a favor?

AI can turn instructions into prose, but it cannot reliably infer the sender’s situation. When the prompt leaves out purpose and context, the model fills gaps with conventional language. The result may sound professional while being vague, too forceful, falsely familiar, or impossible to act on.

Treat AI as a communication assistant, not as the owner of the communication. Before asking it to draft, define three anchors: goal, audience, and tone.

The goal is the outcome the message should produce. “Send an update” describes an activity; “help the project lead decide whether to delay Friday’s launch” describes an outcome. A strong goal answers:

• What should the recipient know, decide, provide, or do?
• Why does that matter now?
• What is the requested action?
• When is that action needed?
• What happens after the recipient responds?

One email can contain context, but it should usually have one primary job. If you need approval, feedback, and three unrelated files, consider separate messages or label each request clearly. A model asked to “make this better” may shorten away one request or blend several into an unclear closing.

Write the goal in plain language before drafting: “I need Maya to confirm the revised budget by 3 p.m. Tuesday so finance can submit it.” That sentence gives the model a real target and gives you a standard for reviewing its draft.

Audience is more than a name and job title. Consider the recipient’s relationship to you, existing knowledge, authority, time, language preferences, and likely concerns.

A teammate who attended yesterday’s discussion needs less background than an executive seeing the issue for the first time. A customer deserves a different explanation than an internal engineer. A recipient who cannot approve your request should not receive language that assumes they can.

Useful audience notes include:

• relationship: manager, peer, customer, vendor, or unfamiliar contact;
• context already shared;
• technical knowledge and terms to avoid;
• decision-making authority;
• likely question or objection;
• accessibility or language needs.

Do not ask AI to imitate a person’s identity or manipulate them. “Use direct, respectful language for a busy department head” is appropriate. “Write it so she feels guilty and cannot say no” is not. Good audience awareness reduces effort for the reader; it does not exploit the reader.

Tone labels are slippery. “Professional,” “warm,” and “confident” mean different things to different people. Translate the desired tone into visible writing choices:

• concise: under 150 words, short paragraphs, one clear request;
• warm: acknowledge the person’s effort without invented praise;
• direct: state the purpose in the first two sentences;
• calm: avoid blame, exaggeration, and emotional punctuation;
• formal: use complete sentences and avoid slang;
• collaborative: explain the shared objective and invite correction.

Tone also depends on stakes. A schedule reminder can be friendly. A compliance concern needs precise, neutral language. A condolence, disciplinary message, legal notice, or medical issue deserves more human care than a generic tone instruction can supply.

Goal, audience, and tone are the foundation, but the model also needs approved facts. Separate facts from instructions so you can inspect both:

Facts: The review moved from Thursday to Friday. Two sections are incomplete. Priya owns the data appendix.

Instruction: Draft a concise note to the project team. Explain the change without assigning blame. Ask section owners to update their material by noon Thursday. Do not invent reasons for the delay.

Boundaries are especially useful: “Do not promise a new deadline,” “keep the quoted policy wording unchanged,” or “insert [DATE NEEDED] where information is missing.” Placeholders are safer than plausible inventions.

Use this compact frame before generating:

1. Goal: the result this email should achieve.
2. Audience: who will read it and what they already know.
3. Facts: names, dates, evidence, and constraints that may be stated.
4. Tone: observable writing choices.
5. Action: exactly what the recipient should do and by when.
6. Boundaries: claims, promises, or details the model must not invent.
7. Format: subject line, length, structure, and number of options.

For example: “Draft an email to a peer who knows the project but not the schedule change. Goal: get confirmation that they can review by Tuesday. Facts: review was planned for Monday; the source data arrived one day late. Tone: direct, calm, collaborative. Keep it under 120 words. Do not blame the data team. Include a subject and one explicit question.”

The generated draft is still a proposal. Check that it preserves your intent and contains only facts you supplied.