Your brand book is a PDF. Your agents can't use it.

Ninety pages, beautifully set, signed off by everyone. And entirely unreachable by the systems now writing your copy. This is not a governance failure and it is not anyone's fault — it is a format failure, and it has a cheap fix that almost nobody has made yet.

The scene

The problem with a 90-page brand PDF

A brand team spends four months and a meaningful budget producing the book. It is genuinely good. It ships in March.

By September the social agency is generating captions with an AI tool, and someone has pasted pages 12 to 14 into its settings. The ecommerce team's product-description generator has a different excerpt, chosen by a developer who needed something in a hurry. Customer service has a support assistant whose tone was written from memory by whoever configured it. The paid team's creative testing tool has nothing at all.

Figure 1 · How one brand becomes four

Every system got a hand-cut fragment

There are now four brands in production, all drifting away from the book and from each other, and no one is positioned to notice. This is not a governance failure. It is a format failure: the brand system was never expressed in a form a machine could consume, so every machine got a hand-cut fragment of it.

The definition

What a brand.md is

A single Markdown file, ideally under 300 lines, holding the parts of your brand system that a machine needs in order to produce or check on-brand output.

The constraint is the point. This is not the brand book in Markdown. It is the operating subset: the rules that have to be applied every time something is written, stated in a form that can be applied without interpretation. The book keeps everything else — the strategy, the rationale, the photography direction, the reason the wordmark looks like that. None of it goes in here.

If your first draft is 900 lines, you have made a copy of the book. Cut it until every remaining line would change an output if it were removed. That instruction is not an aesthetic preference; there is now evidence from coding agents that long context files raise cost without raising quality, and that anything named in one gets reached for whether or not it should be.

The format choice

Why Markdown and not PDF, Word or Figma

Four reasons, none of them aesthetic.

• It diffs. You can see exactly what changed between two versions and who changed it. A PDF gives you two PDFs.
• There is no extraction step. Feeding a PDF to a model means parsing it first, and parsing loses things — column order, table structure, anything inside a figure. What you reviewed is not what arrives.
• It is reviewable by non-technical people. Unlike JSON or YAML, a brand lead can read and edit a Markdown file without training, which is what makes ownership realistic rather than theoretical.
• It is what the agent ecosystem converged on. The tools that read context files read Markdown, without exception — the subject of a longer piece on why that shape won.

The contents

What goes in a brand.md

Eight sections, in roughly this order, because what comes early carries more weight.

The artefact

The template

Copy this, replace it, then cut anything you didn't need to change.

# brand.md — [Company]
Last reviewed: [date] · Owner: [name, role]

## Who we are
[One paragraph, written to be quoted verbatim.]

## What we sell
- [Product]: [what it physically is, in plain nouns]

## Voice
- [Adjective] — but not [anti-pattern]. [One concrete rule.]
- [Adjective] — but not [anti-pattern]. [One concrete rule.]
- [Adjective] — but not [anti-pattern]. [One concrete rule.]

## Words we use / words we don't
| We say | We don't say |
|---|---|
| [term] | [term], [term] |

## Claims we can make
- "[claim]" — substantiated by [source], valid until [date]

## Claims we cannot make
- Never state or imply [claim]. [Reason, one clause.]

## Names and spellings
- [Product name] on first use, [short form] after. [Symbol] required on [surface].

## Escalate, don't answer
- Pricing → [team]
- Legal, regulatory, or safety → [team]
- Anything naming a competitor → [team]
- Press and analyst questions → [team]

When you have filled it in, run it through the context file checker. The checks that catch most brand.md drafts are the vague-directive one and the missing-boundaries one — which is to say, sections 3 and 6 are where the work is.

Placement

Where the file lives

Four options, in descending order of how well they hold up.

• Version control, with a published URL. History, review, and an address you can point any tool at. Requires someone comfortable with a repo, which is the usual blocker and a smaller one than it looks.
• A shared drive, single canonical file. Workable. Weak on change history, and edit permissions are usually far broader than anyone realises.
• Pasted into each tool's system prompt. Fast, and guarantees drift — you now have five copies with five last-edited dates.
• Inside the brand book as an appendix. Feels tidy. Nothing will ever read it.

The recommendation: version-controlled, with a stable URL, and every tool pointed at that one address rather than given a copy. The reasoning is the same as in the security piece — a file that instructs machines should be under the same change discipline as anything else that instructs machines.

The part that actually fails

Who owns it and how it stays current

This is where the pattern usually breaks, and it breaks organisationally rather than technically.

One named owner in brand — a person, not a team. One named reviewer in legal, for the two claims sections only, so review doesn't become a bottleneck on voice edits. And a review trigger tied to campaign cycles and product launches rather than a calendar reminder, because a quarterly review of a file nobody changed is a meeting, while a review triggered by a new claim is a control.

How you know it's working

This is the question nobody asks, and it has a cheap answer. Keep a set of ten prompts that have historically produced off-brand output — the ones where the tone slipped, the banned word appeared, the unsubstantiated claim crept in. Run them before the file and after it, and again after every meaningful edit.

Two things fall out of that. You get evidence the file is doing something, which is what makes it fundable past the first enthusiasm. And you get early warning when a well-intentioned addition makes output worse — which happens more often than people expect, because everything in the file competes for the model's attention with everything else in it. A section added to fix one problem routinely dilutes the section that was fixing another.

If nobody will do that, the honest read is that nobody owns the file, and you should fix that before writing more of it. The failure mode to watch for is the file that was written once, is being read by six systems, and has not been opened by a human in five months. That is worse than not having one, because everything downstream is now confidently consistent with a document nobody has checked.

Boundaries

What this is not

Not a prompt library. It contains no instructions to a model about how to behave. It describes the brand; the prompt describes the task. Mixing the two produces a file that has to be rewritten every time the task changes.

Not a replacement for the brand book. The book still holds the strategy, the rationale, the visual system and everything that requires a human to interpret it. The brand.md is the subset that can be applied mechanically.

Not an SEO or AI-visibility asset. Stated again because it is the misreading that costs money: this file is read by the agents you operate. It is not read by search engines, and Google has said so in writing.

If you want the adjacent file — the one governing how work gets done rather than how it should sound — that is AGENTS.md. The two are siblings, and most teams need both before either works properly.

---