How to Teach an AI Agent Your Company's Tone of Voice

To train an AI agent to write in your company's tone of voice, give it real examples of your best writing, a short set of style rules drawn from those examples, and a clear list of what it must never say. Then test its drafts against a small set of real tasks and revise the material whenever drafts drift. Tone is learned from evidence, not from adjectives like friendly or professional.

Key takeaways

• Real examples teach tone better than descriptions. Collect sent messages, approved documents and, above all, drafts that a person edited before sending.
• Short, testable style rules (each with an example) work better than a long brand manual.
• Keep voice separate from facts. The voice guide says how to write, and your source of truth says what is correct.
• Test with a fixed set of real tasks and a simple rubric, and review the material on a schedule so the voice does not go stale.
• Fine-tuning is rarely the first step. A compact guide plus retrieved examples usually gets a business most of the way there.

Why does 'be friendly and professional' not work?

Most companies start by pasting an adjective list into the agent's instructions: warm, clear, confident, approachable. The agent obeys, and the result sounds like every other company that wrote the same list. Adjectives describe an impression, but they do not say which sentence to write.

Tone of voice is a set of repeatable choices. How long are your sentences? Do you open with the customer's name or with the answer? Do you say we recommend or you should? Do you apologize once, plainly, or three times? Do you use the word issue, problem or situation? A new employee learns these choices by reading what colleagues wrote and by being corrected. An agent can learn them the same way, but only if you give it the material.

There is a second reason generic instructions fail: they carry no boundaries. A voice is as much about what you do not do as what you do. Perhaps you never promise delivery dates in writing, never use exclamation marks with clients, or never describe a colleague's work as simple. Those limits rarely appear in a brand manual, yet they are what a reader notices when they are broken.

What real examples should you collect?

Start with the writing your team is proud of and the writing your team actually sends. They are not always the same, and you need both. Gather a varied set across the situations where the agent will write. For each situation type, pick a handful of strong examples rather than a large pile.

Useful sources include:

• Sent emails that got a good response or that a senior person would sign without changes.
• Replies to difficult moments: a delay, a refusal, a correction, a complaint, a price objection handled without stating the price.
• Short messages, such as chat replies and meeting follow-ups, which are often where the real voice lives.
• Longer documents: proposals, reports, onboarding notes, newsletters.
• Before and after pairs: an agent or junior draft next to the version a person approved. These are the most valuable examples, because the difference between them is the lesson.
• Rejected drafts with a one-line reason, such as too formal, too eager, or promised too much.

Label each example with the situation, the audience, the channel and the language. A reply to a long-standing client is not a model for a first message to a stranger, and an English example is not a model for a Portuguese one. Unlabeled examples teach the agent an average, and the average is exactly what you are trying to avoid.

Before storing anything, remove client names, personal data, prices and anything confidential. Voice examples should teach style, not leak facts. If an example only works with a real name in it, replace the name with a placeholder and keep the structure. The same preparation habits apply as for any document you feed an agent, as described in how to prepare company documents for an AI agent.

How do you turn examples into short style rules?

Read your examples side by side and write down what repeats. Do not write what you wish were true; write what the best examples actually do. Then convert each observation into an instruction the agent can follow and a person can check.

A good rule has three parts: the instruction, the reason, and a short example. For instance:

Lead with the answer in the first sentence, then give context; the reader should never have to scroll for the point.

Rules work best when grouped by what they control. A compact guide usually covers:

• Structure: where the answer goes, how long a typical reply is, when to use a list.
• Address: first name or formal name, we or I, how to refer to the client's team.
• Vocabulary: words you prefer, words you avoid, and your own terms for products and processes.
• Stance: how direct you are about bad news, how you disagree, how you decline.
• Commitments: what the agent may promise in writing (nothing about dates, say, unless a human confirms).
• Openings and closings: how you start and end, and which pleasantries you skip.
• Formatting: punctuation habits, how you write numbers and dates, whether you use emoji.
• Language: separate notes for each language, because a literal translation of an English voice rarely sounds natural in Portuguese.

Keep the whole guide short enough that a colleague would actually read it. If the agent has to weigh dozens of competing rules, it will follow the loudest and ignore the rest. When two rules conflict, decide which wins and write that down. When you cannot explain a rule with a real example, remove it.

Add a short list of hard limits, separate from style. These are the things the agent must never write without a human decision: legal wording, refunds, guarantees, comments about competitors. Limits belong in the permissions and approval design of the agent, not only in the voice guide, so a style slip never becomes a business commitment.

A step-by-step plan from scattered emails to a working voice

This plan fits a single role, such as client follow-up emails or support replies. Choose one first, as suggested in choose your first AI workflow, and extend to other writing later.

• First, name the writing task and its reader. Example: follow-up emails after a client meeting, written to a client contact.
• Second, collect examples for that task: strong sent messages, a few awkward situations, and any before and after pairs. Label and clean them.
• Third, pick a small owner group: one person who writes well and one who approves. Voice without an owner drifts.
• Fourth, draft the rules from the examples and review them with the owners. Remove anything nobody can illustrate.
• Fifth, write the limits: what the agent may never promise, claim or send without approval.
• Sixth, build a test set of real tasks the agent has not seen, covering routine cases and awkward ones.
• Seventh, run the agent, compare its drafts with what a person would send, and mark each difference as a rule gap, a missing example, or a fact error.
• Eighth, fix the cause, not the symptom. If a draft is too eager, add a counter-example and a rule, rather than patching one sentence.
• Ninth, start in review mode: the agent drafts and a person approves. Record every edit, because edits are the next generation of examples.
• Tenth, set a review date and an owner for the voice material.

The loop in steps seven to nine is the heart of the method. The first version of the guide will be wrong in small ways. What matters is that the corrections feed back into the material instead of disappearing into a sent folder.

Where should the voice material live inside the agent?

There are two sensible places, and most agents use both.

The first is a compact voice guide that is always available when the agent writes: the rules, the limits and a few anchor examples. It should be short, because everything loaded into the agent's working context competes for attention with the task itself. Anthropic's engineering guidance on [effective context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) makes this point well: the goal is the smallest set of information that gets the behavior you want. We cover the business side of that idea in context engineering for business agents.

The second is a library of labeled examples that the agent retrieves by situation. When it drafts a delay notice, it should see your best delay notices, not your onboarding emails. This is retrieval, and it lets the library grow without making every request heavier.

Fine-tuning a model on your writing is a different route. It can shape style, but it is harder to inspect, harder to correct and slower to change when your voice or your rules change. For most companies a guide plus retrieved examples is easier to own, and a comparison such as [AWS guidance on retrieval and fine-tuning](https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/rag-vs-fine-tuning.html) helps frame the tradeoff. Our own view is in RAG vs fine-tuning for business knowledge.

Keep one separation firm: the voice material never carries facts such as policies, terms or product details. A beautifully phrased reply that states an outdated policy is worse than a plain one that is correct. Facts come from your documented source of truth, and the voice guide only shapes how they are said.

How do you test whether drafts sound like you?

A fixed test set turns a vague impression into something you can measure. Pick a modest number of real tasks, including a few awkward ones, and keep them stable so you can compare versions. Each time you change the guide or the examples, rerun the set. OpenAI's [evals guide](https://platform.openai.com/docs/guides/evals) describes the general practice of testing model output against defined criteria, and the same discipline applies to tone.

Use a rubric with a few yes or no checks rather than a general score:

• Does the first sentence deliver the answer?
• Does the draft avoid every word on the avoid list?
• Does it stay within the commitments the agent may make?
• Would the owner send it with, at most, a light edit?
• Would a long-standing reader recognize it as coming from your company?

A blind read is a strong final check. Mix agent drafts with human-written messages and ask colleagues to identify which is which, and which they prefer. If they can tell immediately, ask what gave it away, then turn that answer into a rule.

Illustrative scenario: a small advisory firm asks its agent to draft follow-up emails after client calls. The first drafts are polite but wordy, open with thanks for your valuable time, and end with three offers of further help. The reviewer deletes the same two sentences in almost every draft. The team adds a rule (start with the decision made in the call, end with one next step and one date owner), plus two before and after pairs showing the cut. On the next run of the test set, the edits drop to small wording changes, and the reviewer notes which cases still fail. That is the loop working: the edits were evidence, and the evidence changed the material.

Voice also ages. Products get renamed, the company changes how it speaks about a service, and a favorite phrase starts to sound tired. Assign an owner and a review rhythm, using the same approach as an AI knowledge base maintenance routine, and retire examples that no longer represent how you write.

How does Be Human handle this in managed operations?

In a Be Human engagement, voice is treated as part of the agent's operating context, not as a one-time prompt. During setup we define the role, collect and label real examples with the client's team, write the short rules and hard limits, and set the approval boundaries for what the agent may send on its own. The voice material is stored separately from factual knowledge, so each can be reviewed and changed on its own. In managed operations, we run recurring evaluations against the test set, review the edits people make to drafts, and propose controlled updates to the examples and rules, which the client approves before they go live.

Frequently asked questions

Can an AI agent copy one specific person's writing style? Yes, in practice it can approximate it from enough labeled examples, but think about whether you should. A founder's personal voice is different from a company voice, and an agent writing as a named person raises questions of consent and disclosure. Decide who the agent writes as, and get that person's agreement.

How many examples does the agent need? A small, varied set usually beats a large pile of similar messages. Start with a handful for each situation type, include awkward cases and before and after pairs, and add more from the edits people make in review.

Should the agent use different tones for different channels and audiences? Yes. Most companies write differently to a new prospect, a long-standing client and a colleague, and differently in email, chat and formal documents. Label examples by audience and channel, and keep one shared core of rules with short additions for each context.

What if our company's voice is inconsistent? That is common, and building the guide is a good moment to resolve it. Compare examples, agree on what the best ones share, and let the owner decide where people disagree. An agent will reproduce inconsistency faithfully, so settling the choices first saves a lot of editing later.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.