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.

Picture two people who both told the model the exact same three words: warm, clear, direct. One of them writes in two-line replies that get to the point in the first clause. The other writes a short paragraph that sets up the context before the request. Both descriptions are accurate. Both people would read the other’s email and know it was not theirs. The adjectives were never the problem. The problem is that an adjective is a label you apply after the writing exists, and the model needs the thing the label was applied to. You can describe a handwriting style as “neat” all day. Nobody could forge your signature from the word.

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.

The pruning is not housekeeping. It is the part that decides whether the model learns you or learns noise. A forwarded thread is mostly someone else’s words with your “see below” stapled on top; feed it in and the model picks up a stranger’s habits and files them under yours. A one-word reply teaches nothing except that you sometimes type one word. The email you wrote angry is the worst case, because it reads as decisive and the model loves decisive, so it will copy the sharp edges you only had that one bad afternoon. Picture a corpus that is half-forwards and a quarter terse acknowledgements. The model averages all of it and hands you back something that is technically drawn from your mail and sounds like nobody. Quality of sample beats size of sample. Two hundred messages that are actually you will beat five hundred that are mostly you and partly everyone you have ever replied to.

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.

The banned list works because it gives the model a clear rule where it otherwise has only a soft preference. Left to its own judgement it weighs “circling back” against every other way to follow up and often picks the cliché, because the cliché is the most common thing it has read. A written ban is not a suggestion it can outvote. It is a wall. The same logic explains why a vague instruction like “sound less corporate” fails while a specific one like “never write the word reach out” works. The first asks the model to make a judgement call. The second removes the call. Every line you can turn from a preference into a rule is a line you never have to fight about again.

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.

The reason to settle this first is that the convenient choice is hard to walk back. Pick the managed route to skip an afternoon of setup, run it for six months, and your mail has been flowing through a third party that whole time. You cannot un-send those threads. If a contract you signed says client data stays inside an approved set of systems, a router you added on a quiet Tuesday probably is not on that list, and that is a problem you created without noticing. Ask the dull question early. Whose servers does this email touch between my mailbox and the model, and is every one of them allowed to. The self-hosted path is more work because you do the OAuth dance yourself and you keep the server running. What you buy with that work is a short, auditable line you can describe in one sentence and defend in a review.

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.

Sit with the asymmetry, because it is the whole argument for the draft-only rule. A bad line of code fails loudly and fast. A test goes red, a build breaks, a page will not load, and you fix it in the same hour you wrote it. A bad email does none of that. It arrives looking fine. The recipient reads a sentence that was a shade too cold or too familiar, decides something quiet about you, and never tells you. There is no error message for a client who trusts you slightly less than they did last week. The cost shows up months later as a call that did not happen, and by then you cannot trace it back to the email, let alone the draft. An auto-send setting is a bet that the model will never get one of these wrong. You would not take that bet with a new hire on their first week, and the model has known your voice for less time than that.

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.