How to make AI emails actually sound like you

You can always tell. Someone replies to your email and a machine clearly wrote it. The greeting is a notch too formal. A sentence opens with “I hope this email finds you well.” The sign-off reads like a press release. You would never write any of it, and the person reading it knows you would never write any of it.

So here is the fix, stated plainly before the explanation. You do not make AI emails sound like you by writing a clever prompt that describes your tone. You make them sound like you by handing the model a corpus of emails you actually sent, a written style file you maintain the way you maintain code, and a hard rule that it drafts but never sends. Tone descriptions fail because your voice is not a list of adjectives. It is a few hundred small, real decisions about word choice, length, and rhythm that you could not fully name if someone asked.

I have written before about building an AI voice profile. Email is the sharpest test of one, because the reader already knows you.

Why tone-guide prompts fail

The standard approach is a prompt. You tell Claude to write in a friendly, concise, professional tone. Maybe you add “warm but direct.” Maybe you list three rules. Then you wonder why every draft still lands slightly wrong.

It lands wrong because a tone guide is a description of your voice, and your voice is a behavior.

Think about what “concise” actually means. To one writer it means short sentences. To another it means no preamble. To a third it means cutting every adjective that is not load-bearing. The word does not carry the decision. When you write a real email, you are not consulting a list of qualities. You are making dozens of micro-calls. Open with their name or skip the greeting. Say “thanks” or “thank you.” End with “best,” with your initials, or with nothing. Use a comma where a stricter writer would use a full stop. Those calls are your voice. Not one of them lives in a tone prompt.

There is a second failure mode, quieter than the first. A tone prompt has no memory. You correct a draft today, you correct the same thing tomorrow, and the prompt never learns because nothing wrote the correction down. The model starts every email from the same generic place. You are not training anything. You are re-explaining yourself, forever, to something that cannot remember the last conversation.

This is why the output drifts toward a kind of beige professional default. The model has read an enormous amount of corporate email, and absent strong evidence of who you are, it averages. The average business email is bland because most business email is bland. A description cannot pull the model off that average. Only evidence can. And the evidence already exists, sitting in a folder you almost never open on purpose.

Build a voice corpus

Open your sent folder, not your inbox. Your sent folder is the only place your real voice lives, because it holds what you chose to write rather than what landed on you. Pull a sample of 100 to 200 emails. Harper Reed, documenting his own setup, had Claude review the past couple hundred emails he had sent, and that range is a reasonable target. Below roughly 50 emails the model sees your habits but not your range. Past a few hundred you are mostly feeding it redundancy. Then prune the sample. Cut what is not your voice: forwarded threads, one-word replies, anything written while annoyed, anything legal or HR drafted on your behalf. Keep the ordinary messages. The reply to a client, the quick note to a teammate, the polite refusal. Those carry your defaults. Hand that pruned set to Claude and ask it to describe the patterns it sees before it writes a single draft.

That last step matters more than it looks. When the model reflects your corpus back to you, you find out whether it actually caught your voice or just caught your job. It will tell you things you did not know about your own writing. That you almost never use exclamation marks. That you open with a one-line context sentence before the ask. That you close warm with people you know and flat with people you do not. Some of it will be wrong. Correct it now, in conversation, before any of it hardens into a rule.

One caution on the corpus. It is a snapshot of how you wrote, not a constitution for how you must write. If you spent two years sending rushed, terse emails you were not proud of, do not enshrine that. Pull the sample from a stretch you would be happy to be judged on. The corpus is raw material. The next step is where you shape it.

Version your voice rules

The corpus teaches the model your patterns. A style file teaches it your intentions. You need both.

Keep a plain text file. Harper Reed used a CLAUDE.md file for this; the format barely matters, what matters is that it is a file and not a chat message. Call it communication-style.md. In it you write the rules the corpus cannot show, because they are about what you are trying to do rather than what you have done. Things like: never start with “I hope this finds you well.” Match the recipient’s formality, do not exceed it. If the email is bad news, say it in the first sentence. Keep paragraphs to three sentences. Sign off with just my first name unless it is a first contact.

Then add a banned-phrases list and treat it as sacred. Every writer has tells they hate. “Just circling back.” “Per my last email.” “Reach out.” “At your earliest convenience.” Write them down. The model will reach for them because the internet is built from them, and the list is what stops it.

Here is the part that makes this compound instead of evaporate. When a draft comes back wrong, do not just fix the draft. Fix the file. The draft was too stiff, so you add a line about contractions. The draft buried the ask, so you add a line about putting the ask up top. Each correction becomes a rule, the rule applies to every future email, and you stop re-explaining yourself. This is the same discipline that keeps brand voice consistent across AI outputs: the standard lives in a versioned file, not in someone’s memory. Put the file in git if you can. You will want the history, because in a month you will wonder why a rule exists, and the commit message will tell you.

Wiring it into Gmail

A corpus and a style file are useless if you have to paste them into a chat window every morning. The connection is the Model Context Protocol, the open standard that lets Claude reach into Gmail directly. Anthropic documents the setup in the Claude Code MCP guide, and there are several Gmail servers to choose from: the widely used GongRzhe Gmail MCP server, the Composio integration, and managed routes through services like Zapier and Pipedream. All of them need a one-time Gmail OAuth authorization, and then Claude can search your mail, read a thread, and create a draft.

There is a real decision buried in that list, and it is about privacy, not features. A managed router like Pipedream or Zapier sits between your mailbox and the model. Your email passes through that company’s infrastructure on the way. For a personal account that may be fine. For a business account under any kind of data agreement, it is a question you should answer before you wire anything up, not after. A self-hosted Gmail MCP server keeps the path shorter: your machine to Gmail to Anthropic, with no extra party in the middle. It is more setup. It is also the version a security team will actually approve.

If you are doing this for a team rather than yourself, the wiring is the smallest part of the job. The hard part is agreeing on what a shared voice even is and keeping a dozen people’s style files from drifting apart. If you want help shaping that, Blue Sheen runs engagements like this.

Draft only by default

This is the rule that is not optional. The model drafts. You send. There is no configuration where it sends on its own, no “trusted senders” exception, no overnight batch that goes out while you sleep.

Harper Reed learned this the direct way. His system saves everything as a draft for review, and he is blunt about why he does not trust it further:

“I trust these agents to write code way way more than I trust them to write an email to a friend, stranger or business partner.” — Harper Reed, writing up his own Claude email workflow

That is the right instinct. Code that is wrong throws an error. An email that is wrong damages a relationship, silently, and you may not find out for months. The blast radius is not symmetric, so the safeguard should not be either.

There is also a calibration period, and you should plan for it rather than be surprised by it. Expect the first stretch of drafts to be close but not right. The common guidance is to review your first hundred or so generated emails by hand, correcting each one and feeding the correction back into the style file. Over those weeks the gap between the first draft and the version you actually send narrows, until most mornings the draft is yours already, give or take a word. That is the goal. Not an inbox that runs itself. An inbox where the blank page is gone.

Watch for the edge cases the corpus will get wrong. Sarcasm does not survive a draft. Conditional, careful messages where the wording is doing legal or political work should be written by you, every time. And some emails should not sound like you at all, because they are policy, or they are formal on purpose. Tell the style file about those. The model is good at your default voice. It does not know when you would deliberately drop it.

The goal here is narrow and worth saying plainly. You are not automating relationships. You are removing the part of email that was never really writing: the cold start, the staring at an empty reply box, the friction between knowing what you want to say and having said it. Your voice is worth protecting. Lend it to the machine carefully, keep your hand on the send button, and it gives you back the only thing email ever actually cost you, which was time.