Which brand guideline formats can AI tools actually use?

What a format has to carry

A brand guide gives an agent four kinds of content, and formats differ in which of them they keep intact:

Rules

Judgement calls and the reasons for them: when a colour is allowed, which claims need a source, how formal a customer email should be. Rules are prose.

Exact values

Hex codes, font names, type sizes, the smallest size the logo can appear at. A value written as text is exact. A value read off a picture is an estimate.

Files

The logo SVG, the font files, approved photos and templates. An agent can place a file as it is. Given a description or a screenshot, it can only approximate it.

Visual references

Pictures of the brand in use, including work you approved and work you rejected, each with the reason. They show proportion, texture and density, which prose can only describe roughly.

Two more questions decide whether a format works in practice: how the agent gets it (attached to a chat, fetched from the web, read from a folder or called through a connection), and whether what it gets is the current version. How to keep AI-generated content on brand covers which content each kind of output needs. This article is about the containers.

The formats compared

Most teams start with the first row, so that’s where the detail starts too.

PDFs and slide decks

The brand book most teams already have is a PDF, and it works better with AI than its reputation suggests. In their APIs, Claude and OpenAI’s models read a PDF as the text of each page plus an image of it, and Gemini reads PDFs with vision. A model can quote the rules and look at the layouts.

Three things still go wrong:

• Size. Anthropic estimates 1,500 to 3,000 tokens of text per page, before the page images. By that estimate a 60-page brand book is at least 90,000 tokens, most of it irrelevant to any one task.
• Pictures instead of files. The logo on page 12 is a picture of the logo. The agent can see it but has no file to place, so it redraws or crops. A colour shown only as a swatch, with no value printed beside it, gets estimated from pixels.
• Copies. Each upload is the version you uploaded, and stays that way.

Slide decks lose more. OpenAI’s API extracts only the text from .pptx and .docx files, without embedded images or charts, and recommends converting to PDF to keep them. Gemini’s docs say documents other than PDFs are read as plain text, losing charts and formatting. A brand deck is mostly pictures, so export it to PDF before an agent reads it. Chat apps can handle uploads differently from their APIs, so check the one you use.

Keep the PDF for the people who read it. For agents, pull its rules out as text and its logos and fonts out as files. The Markdown brand guidelines template walks through it.

Brand portals and web pages

A guidelines portal, whether it’s built in a brand platform, Notion or your own site, can hold the current brand. Whether an agent can read it depends on its tools. Claude’s web fetch tool, for example, accepts text, HTML and PDF, fetches only URLs already present in the conversation, and doesn’t support pages rendered with JavaScript. It isn’t a way to download font files or a ZIP of logos. Test the actual guideline pages with your agent, especially pages behind a sign-in; those may need an authenticated browser or a direct integration.

There are two ways around it. One is to publish a Markdown version of each page and list them in an llms.txt file, a proposal first published in 2024 for pointing agents at clean text. The other is to connect agents to the portal directly. Frontify’s MCP server, for one, gives Claude, Cursor and other tools access to guidelines, assets and templates.

Vendors now grade portals on this. Frontify’s guidelines examples page marks each one “AI-queryable” or not and advises guidelines “held as structured, live content that AI tools can query directly”. Every portal it marks queryable is built on Frontify, so read the column as a description of one approach rather than an independent test.

Markdown and BRAND.md

Markdown is plain text with headings, tables and links, so any tool that accepts text can read it. Tables hold exact values, links point to the real files, and every change shows up line by line in version control. It’s the plainest way to give an agent rules and values.

It has two limits. It describes files rather than holding them, so the links have to open wherever the agent runs. And an uploaded copy is a snapshot; Standards says of its own Markdown export that “uploaded files are a snapshot and will not reflect changes published after the file was downloaded”.

BRAND.md is a draft spec (version 0.3.0, MIT-licensed, by Caio Pizzol) for a brand file kept in a project’s root. It has strategy, voice and visual layers, plus an optional governance layer for naming, claims and accessibility. Product brands get their own files, which inherit whatever they leave out from the master. Its boundary test is useful even if you never adopt the spec: “If it should survive a complete visual redesign, it belongs in BRAND.md.” Type scales, components and other interface details go to a DESIGN.md. The visual layer holds only what can be described in text, and logo files appear only as a note of where they’re kept.

For a file you can fill in section by section, use the Markdown brand guidelines template.

Agent Skills (SKILL.md)

An Agent Skill is a folder with a SKILL.md file at its root: YAML frontmatter with a name and a description, then instructions in Markdown. Optional references/, assets/ and scripts/ folders hold documentation, files and code. Anthropic developed the format and released it as an open standard, and OpenAI’s skills for ChatGPT and Codex build on it.

How agents load it is what makes it suit a brand. The specification describes three stages: about 100 tokens of name and description for every installed skill at startup, the full SKILL.md (under 5,000 tokens recommended) when a task matches, and other files only when they’re needed. A brand skill can hold voice, colour and logo references alongside the actual logo, font and image files, and a task that needs only the colour rules opens only that file. It’s the first format here that keeps rules, files and visual references together.

You can open a real one. TANNIN is a tea-room identity concept that the designer Anna Kuziuk published on Behance. We packaged it as an example skill to show the format. The download is laid out like this, shortened here:

SKILL.md
ATTRIBUTION.md
README.md
references/
├── color-and-type.md
├── logo-and-marks.md
├── voice-and-messaging.md
├── generation-guidance.md
└── … five more
assets/
├── manifest.json
├── fonts/
├── images/
└── svg/
preview/

In the frontmatter of SKILL.md, the description decides when the skill loads, so it names the work the skill covers:

---
name: tannin-brand
description: Apply the TANNIN example identity when creating or reviewing packaging, campaigns, social posts, print, environmental graphics, imagery, or brand copy. Use this skill whenever a task asks for TANNIN-branded work or asks to reproduce or extend this urban tea room identity. Includes visual references, editable SVG assets, fonts, composition rules, and guidance for generating new artwork.
---

Two details show what a folder adds over a single file. SKILL.md tells the agent to inspect the source board closest to the requested output, because “prose alone cannot establish” proportions, texture and density. And assets/manifest.json lists every image with its role, a one-line description and the reference files that cite it, so an agent reading the colour guidance can find the boards it means.

A skill needs an agent that can read files; Claude’s skills run in a code execution environment with filesystem access. Skills are also copies like any other file. Anthropic says custom skills “do not sync across surfaces”, so one uploaded to claude.ai isn’t available in Claude Code or the API.

DESIGN.md and design tokens

DESIGN.md, from Google Labs, is “a format specification for describing a visual identity to coding agents”. It puts design tokens (colours, typography, spacing, corner radii and components) in YAML, and explains in Markdown sections why they exist and how to apply them. Its command-line tool flags broken token references and component text and background colours below the WCAG AA contrast minimum, and exports the tokens for Tailwind or in the Design Tokens Community Group format described below. It’s in alpha, and it covers interfaces: there are no sections for voice, claims or imagery. A coding agent still needs the brand’s voice, claims and approved assets alongside those interface rules. In a code repository, that usually means keeping DESIGN.md and its tokens next to the code they style, since the build imports them, and fetching the rest of the brand when a task needs it.

The Design Tokens Format Module is a JSON format for passing those values between tools. Version 2025.10, published in October 2025 by a W3C community group, is marked stable, though it’s not a W3C Standard. Each token has a $value, a $type such as color, dimension, fontFamily or typography, and an optional $description. Its main readers are tools rather than models: design tools and build pipelines import the values, so nobody retypes a hex code. A $description can carry a one-line rule, but voice, logo rules and examples don’t fit.

Other JSON is similar. It holds exact values and named fields well, and it’s what most APIs return, but rules that need judgement read better as prose.

Is one format best?

We haven’t found a published test that compares brand guideline formats for AI output. The closest evidence is a 2024 study that gave OpenAI’s models the same content as plain text, Markdown, JSON and YAML. GPT-3.5-turbo’s score on one code translation task varied by up to 40% with the format, while GPT-4 was more robust. The study wasn’t about brands and those models have since been replaced, but it supports two practical points: format can change results, and how much depends on the model.

So test your own setup on real tasks rather than trusting anyone’s claim about the best format, this article’s included. What is documented is what each format can carry, and that points to using several, each for its own part of the brand.

Combining formats

Here’s how Acme, which makes the Atlas Pro design tool, might split its brand. Inside an Agent Skill, all of it can sit in one folder:

One fact can live in two files. Acme’s colour reference says why the burgundy exists:

## Atlas Pro Burgundy

#6D1A36. Use it on Atlas Pro materials only. It marks
the product line, so other Acme products never use it.

Its token file holds the same value for design tools and code:

{
  "color": {
    "$type": "color",
    "atlas-pro-burgundy": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0.427, 0.102, 0.212],
        "hex": "#6d1a36"
      },
      "$description": "Atlas Pro materials only."
    }
  }
}

Two files with one value means two places to change it. Keep them side by side and change them together, or generate the tokens from a single source, as DESIGN.md’s export does. How to version brand guidelines for AI workflows covers keeping the versions straight.

MCP is a connection, not a format

Every format so far shares one weakness once it leaves your hands: the copy stays as it was. The Model Context Protocol (MCP) addresses that, but it isn’t another file format. It decides how an agent reaches the brand and whether what it gets is current. A server can offer three things: prompts, which the user picks; resources, which the client application attaches as context; and tools, which the model calls itself. For brand guidance the difference matters. A brand guide offered as a resource reaches the model when the app includes it, and the protocol leaves each app to decide how. A tool is something the agent can call in the middle of a task, at the point where it needs the brand.

Either way, connected agents read the same source, and nobody uploads a file again after a change. MCP alone doesn’t guarantee that an agent has read the latest guidance, though. An app can hold on to what it fetched, so have agents fetch at the start of each task. The source behind the server still has to be kept current, the agent needs a client that supports MCP, and the finished work still needs checking against the brand.

Keep one source current

Rainbrand keeps a brand in this combined form and serves it to connected agents. You add a brand from the formats you already have: PDFs, decks, documents, Markdown, your website, logos, fonts and images. Rainbrand keeps it as a Brand Skill: a profile with the brand’s colours, logos and type, its guidance as Markdown files, and its assets. Exported, it’s a folder much like the TANNIN skill above. Agents connected through MCP, including Claude, ChatGPT, Codex and Cursor, request a Brief with a tool call and get the guidance and files for their task rather than the whole brand. Your own product can read the Brand Skill as structured data through the API, and tools that need local files can use an exported folder, which is a snapshot like any other copy.

When the brand changes, you describe the edit, check what Rainbrand prepares and apply it. Briefs requested after that use the updated brand. Files you uploaded to other tools don’t change, so replace them with the connection wherever a tool supports it. A Review checks the resulting work against the brand. MCP vs REST API for brand context compares the two ways to connect.

Test what your agent actually receives

Before converting anything, find out what your agent can use today. Give it the brand material the way it gets it in real work, whether that’s an upload, a folder or a connection, and ask:

Using only the brand material available to you, quote our rule for using the primary colour and give its exact value. Then name the logo file you would place on a dark background, with its file format, and the font file you would use for headlines. If you can only see a picture of the logo, or are estimating a colour from an image, say so.

Note anything it can’t find, can only see as a picture, or quotes from an older version. Those gaps show which part of the brand needs another format, which is more useful than converting every guide into the newest one. For recurring work across several agents, connect them to a maintained brand and request task context instead of uploading copies. If a tool can only use an exported folder, replace that copy when the brand changes.