How to write brand voice guidelines AI tools can follow

Start with a rule a writer can use

“Friendly but professional” leaves an agent to choose the words, rhythm and amount of familiarity. A usable voice guide settles some of those choices. It tells the writer what to do in a particular situation and gives an example of the result you want.

You can inspect one in the downloadable TANNIN Brand Skill, a folder of brand guidance and assets for agents. TANNIN is a tea-room concept by Anna Kuziuk.

Its references/voice-and-messaging.md permits playful campaign statements while asking for literal wording in utility copy. It separately rules out invented provenance, ingredients and wellness promises. One instruction controls how the copy sounds; the other controls what it may claim.

Keep both kinds of instruction in view as you build your guide. For each voice rule, aim to complete a record like this:

Rule:
Applies to these messages:
Reason:
Approved example and source:
Near-miss and why it fails:
Task facts needed before writing:

The fields give you a way to discover what is missing. If you cannot fill the example or explain the reason, keep the rule as a proposal while you find evidence for it.

Gather the copy and edits that define the voice

Start from writing you would use again. Collect examples from the formats you publish regularly, alongside drafts that needed edits and the reasons for those edits. You need enough variety to see which choices recur across tasks. A single launch email tells you little about how to write a support reply.

Mark each sample's source, format and status. Distinguish copy that was actually approved from a new example you are proposing for the guide. Note which edits were about style and which corrected a fact. A shorter sentence might be a voice preference; replacing a claim about an unshipped feature is a factual correction.

An agent can identify patterns and show the evidence for each proposed rule:

Read these approved writing samples and their earlier drafts. Group the repeated edits into proposed voice rules. For each rule, cite the sample and edit that support it, explain when it applies, and identify any conflicting example. Keep factual corrections separate from style preferences. Label every new rule or example as proposed.

The examples below use fictional Acme and its product Atlas Pro, a design tool. They illustrate how to write the records.

Write rules that settle an edit

A trait name can help people remember the voice. The instruction beneath it should tell the writer what to change.

For each one, ask whether two editors could point to the same passage and explain the decision. “Confident” alone leaves room for inflated promises. A rule that asks for the supported result gives the writer something to say and a source to check.

Tone is how the voice changes with the situation. Mailchimp's guide distinguishes a relatively consistent voice from changing tone. Nielsen Norman Group describes four dimensions you can use to discuss that change: formality, humour, respectfulness and enthusiasm. Turn those choices into instructions for situations your agent can identify.

For Acme, a proposed table might be:

These are editorial choices for the fictional guide. Choose rows and rules that fit your work rather than adopting Acme's settings unchanged.

Vocabulary needs similar precision. Put product names and their spelling first, then words you regularly replace. Include exceptions so an accurate technical term does not get removed mechanically.

Keep sentence rules to choices you would enforce in an edit: spelling, contractions, case, punctuation and any useful limits by format. Avoid filling the guide with preferences nobody follows. A sentence-length target can prompt an edit, but it should not force a product name or essential condition out of a sentence.

Pair each rule with examples

Examples show how much to say and how the sentences should fit together. OpenAI's prompting guide recommends varied inputs and desired outputs. Anthropic's guidance likewise recommends examples close to the task, with enough variety to avoid teaching incidental patterns.

Use approved examples from different subjects and formats. Pair them with plausible near-misses and explain the edit. A deliberately absurd bad example teaches less about the decisions your writers struggle with.

Here is a fictional outage-email pair. Its exercise facts are that some exports failed from 09:10 to 10:25 UTC, incomplete files need exporting again, and a storage change caused the failure. The change has been reversed and exports are now working. Those facts belong to this exercise only.

Near-miss

We're so sorry for any inconvenience! Our team is working hard to resolve the issue and we really appreciate your patience.

The reader cannot tell what failed, whether it is still happening or what to do. The enthusiasm also conflicts with the proposed outage tone.

Preferred version for those exercise facts

Some exports failed between 09:10 and 10:25 UTC today. We're sorry. If you exported a file during that time, export it again to replace any incomplete version.

The cause was a storage change. We've reversed it, and exports are working again.

The revision supplies the impact, action and current status. It does not add a promise about future prevention, because the exercise facts provide none. Label it as a fictional example so a later task does not inherit the times or diagnosis.

For more ways to explain an editing decision, see the attributed brand voice examples.

Assemble the guide and the task request

Keep the guide readable from top to bottom, with headings that an agent can find again. This worksheet gathers the decisions above. Duplicate the rule and example records where needed.

# [Brand] voice guide

## Audience and purpose

- Who we write for:
- What they need from our writing:
- Formats this guide covers:
- Source links and revision date:

## Voice rules

### [Trait]

- Rule:
- Applies when:
- Reason:
- If rules conflict, prioritise:
- Approved example and source:
- Near-miss and the edit it needs:

## Tone by situation

| Situation   | What changes in the writing | Facts needed |
| ----------- | --------------------------- | ------------ |
| [Situation] | [Practical instruction]     | [Task input] |

## Vocabulary and mechanics

- Exact names and spelling:
- Preferred words, replacements and exceptions:
- Spelling convention and contractions:
- Headings, buttons and punctuation:
- Length or structure rules, where useful:

## Examples by format

### [Format and example]

- Status: [approved copy / proposed example / fictional exercise]
- Source and date:
- Task facts used in this example:
- Copy:
- Rules illustrated:
- Near-miss and why it fails:

## Related factual sources

- Product capabilities and availability:
- Prices and terms:
- Supported claims:

## Revision record

- Rule changed and why:
- Failed writing case to rerun:

Keep changing product facts in their own maintained sources, linked from the guide. An example's old price or availability should not become the source for a new message.

Each writing request still needs its own facts. A useful task says what to make, who will read it, what happened and which sources establish that. For example:

Write an Atlas Pro outage email for product designers, using Acme's
current voice guide and its outage tone rules.

Use the attached incident record for the affected period, impact,
current status and recovery steps. Do not reuse incident details from
the guide's examples. Identify any missing fact before drafting the
sentence that needs it.

This is a request template. It requires an actual incident record before it can produce a factual message.

Test the guide on the work it is meant for

Test the guide on a saved set of representative tasks from your own work. Include ordinary messages as well as difficult cases: a limitation, an apology, an uncertain cause or a change the reader may dislike.

1. Run the same tasks with and without the guide on the models you use. Keep the facts and requested formats the same so you can compare the writing decisions.
2. Check exact rules mechanically where useful: product spelling, prohibited phrases and punctuation. Treat length flags as prompts to inspect the sentence.
3. Check judgement rules against a written rubric. A separate model can identify the relevant passage, explain the finding and mark it pass, fail or not applicable. Compare some findings with edits from someone who knows the intended voice, especially when the rubric is new or the reviewers disagree.
4. Save each useful failure with the task, draft, rule and preferred revision. Decide whether it reveals missing task information, unclear guidance or a failure to follow a clear rule.
5. Change the relevant input and rerun the saved tasks. Keep the corrected deliverable as well; improving the guide does not repair existing drafts automatically.

Anthropic's evaluation guide supports task-specific evaluations with edge cases and different grading methods. The sequence here is a proposed way to apply those ideas to voice. Comparing the grader's findings with actual edits helps you tell whether the rubric captures your intended voice.

You can adapt this grader request:

Check this draft against the attached voice guide. For each applicable rule, quote the relevant passage, explain the finding, and mark pass, fail or not applicable. Keep voice findings separate from factual questions. Flag facts that need a source. Do not rewrite the draft. End with the specific edits needed.

Repeat the set when you change the guide or model. Record which model and guide revision produced each draft so the comparison remains useful.

Make the revised guidance available to agents

Once the guide works, agents need its current instructions when they write. Copies saved in separate tools need their own updates; they do not change when you revise the source guide. Sharing guidelines across AI assistants covers that maintenance problem.

Rainbrand maintains brand context for connected agents and products. Add the voice guide with the brand's sources, or prepare an edit to an existing brand. Inspect the proposal, refine it where needed and apply or discard the change. Request a fresh Brief after applying an update. A Brief selects guidance and assets for the task, so include its audience, channel and situation in the request.

Request a Brief for Acme for an Atlas Pro outage email to product designers. Use the attached incident record for the facts. Read the completed Brief, then draft the email using its voice guidance. Show the draft and identify any facts that remain unresolved.

Run the same voice checks on the resulting draft. Rainbrand Review can also check work against the brand. For a composed email, page or other visual deliverable, the documented request starts with an image or visual capture; its findings guide corrections made with the agent's own tools. Use the text grader above to inspect the prose against individual voice rules.

Keep the failed writing cases with the guide's revision record. The next time you change a rule, rerun the case that prompted it and check that the preferred behaviour survives.