AI email drafting that sounds like you: knowledge base, tone, review

Good AI email drafts need a knowledge base the model must prefer, a written tone, a draft-only rule and a reviewer who can ask for changes in plain words.

Published 20 October 2026 · 5 min read · By Kamil HrbáčekemailAI agentsknowledge base

AI email drafting works when the model writes from your company's verified knowledge and your written tone, and a person approves every draft before it leaves. Without those two inputs a model writes polite, plausible, generic email that nobody would mistake for yours, and sometimes promises something you do not offer. With them, most drafts need a few seconds of reading and a click. This is how we set it up for the sales replies of a KH Group company, and what we learned along the way.

A knowledge base the model must prefer

Our drafting agent loads a set of plain Markdown files from a shared drive before every draft. They are split by purpose:

• A dispatcher that tells the model which mode it is in, for example a sales reply or a pure translation.
• A sales module describing how we handle an enquiry: what to find out, what to propose, what never to promise.
• Verified knowledge files (prefixed KB_): products and options, service policies, and how the team communicates.
• Raw material (prefixed DUMP_), such as notes on competitors, which is useful context but not checked line by line.

The instructions state the order of trust in one line: KB files over DUMP files over the model's own knowledge. That single sentence prevents a whole class of errors. Without it, a model will happily fill a gap in your documentation with something that is true of a competitor's product.

One technical lesson: in our n8n workflow the files are loaded one after another, each appended to the context, rather than in parallel branches. Parallel branches looked faster, but only one branch's data reliably reached the next step, and drafts were quietly written from a partial knowledge base. Nothing failed. The drafts were just worse. Sequential loading is a little slower and correct every time.

Tone is a document, not an adjective

"Friendly but professional" means something different to every model and every reader. What works is a short communication file: how we greet and sign off, whether we use first names, sentence length, words we avoid, how we handle price questions, and two or three real replies we were happy with. Models imitate examples much more reliably than they follow descriptions.

Language is part of tone. Our reviewers work in their own language, while the customer gets a reply in theirs. The agent first identifies the customer's language and records it with the case. It writes its analysis for the reviewer in the reviewer's language. When the reply is approved, a separate step translates the final text into the customer's language. The reviewer never has to approve a draft they cannot read fluently.

The draft-only rule

The agent creates a draft in the same mail thread. It has no tool that sends email, and the button that sends works only from a logged-in human session. This is not distrust of the model. It is the cheapest insurance there is: a bad draft costs a reviewer ten seconds, while a bad email sent to a customer can cost a relationship. The full set of guards is in Human-in-the-loop automation.

Iterating with the reviewer

The review screen shows the customer's message, the agent's short analysis and the draft. The reviewer can edit the text directly, but more often writes a comment in plain words: "shorter", "don't mention delivery dates", "offer a call instead of a quote". The agent rewrites the draft in place, and the loop repeats until it is right.

Two details make this work. Each iteration replaces the draft in the mailbox rather than creating a new one, so there is never a question of which version is current. And the reviewer can tick a box to mark an exchange as useful for improving the knowledge base, so recurring corrections can end up in the files, not only in one email.

The hard part: not contradicting yourself

The worst drafts we have seen were not badly written. They were well written and inconsistent with something the customer had already been told. Three causes, and what we do about each:

• The customer wrote twice. Two cases, two drafts, two answers that did not know about each other. Now, if the same customer has another open case younger than 14 days, the messages are merged in order and the agent writes one reply to all of them.
• A reply already went out by another route. Someone answered from their own mailbox. A housekeeping job compares open drafts with what has actually been sent, and marks a draft as needs rewrite when it may conflict with mail the customer already received. It writes a note and does not change or delete anything.
• The knowledge base was out of date. The draft was faithful to a file that was wrong. The fix belongs in the file, which is why corrections from review are fed back.

Start with these three files

You do not need our whole setup to get good drafts. Start with three files: what you sell (facts only), how you talk (with real examples), and what you never promise. Load them into every draft, keep the draft-only rule from day one, and read a week of drafts before changing anything. The Academy lesson Working with an AI agent covers the describe, check and refine loop you will use to improve them. Where the drafts come from in the first place, labels, a schedule and a queue, is in AI inbox management.

Written from our own production systems. Drafted with AI assistance and reviewed by Kamil Hrbáček.